Discussion: Config implicit converter

[Emily Jiang]

I am sorting the next MP config release and have a question on one of the changes under the issue #248

Since Config 1.1, we have added the following support under the issue #248

=== Automatic Converters

If no built-in nor custom Converter for a requested Type T, an implicit Converter is automatically provided if the following conditions are met:

• The target type T has a Constructor with a String parameter, or
• the target type T has a Constructor with a CharSequence parameter, or
• the target type T has a static T valueOf(String) method, or
• the target type T has a static T valueOf(CharSequence) method, or
• the target type T has a static T parse(String) method, or
• the target type T has a static T parse(CharSequence) method, or
• the target type T is an Enum, in which case the Enum#valueOf(Class, String) is being used.

In the original discussion of #248, I only suggested to add he following common support:

The target type T has a Constructor with a String parameter
the target type T has a static T valueOf(String) method,

The above will cover most scenarios and it is straightforward.

The current codebase introduces too many variety and in the spec we need to specify the search order, e.g. Constructor(String)-> Constructor(CharSequence)->valueOf(String).... I feel this complicates the spec without much gain. What do people think on removing the CharSequence support, parse and Enum, while just keep the above two support. Besides, we are providing a convenient method. If anyone wants to use CharSquence, they can provide their own converter. Thoughts?

I raised the above in the config repo (https://github.com/eclipse/microprofile-config/issues/269). You can either comment here or directly on the issue.

Thanks

Emily

[Ladislav Thon]

I can understand the desire, but why remove the support for enums? They are pretty common and there's no ambiguity there.

LT

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/429d6a05-ab0f-40e4-b5f9-2f60dc40e1d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emily Jiang]

good point. Enum can stay.

Basically,
As is

• The target type T has a Constructor with a String parameter, or
• the target type T has a Constructor with a CharSequence parameter, or
• the target type T has a static T valueOf(String) method, or
• the target type T has a static T valueOf(CharSequence) method, or
• the target type T has a static T parse(String) method, or
• the target type T has a static T parse(CharSequence) method, or
• the target type T is an Enum, in which case the Enum#valueOf(Class, String) is being used.

to be:

• The target type T has a Constructor with a String parameter, or

• the target type T has a static T valueOf(String) method, or

• the target type T is an Enum, in which case the Enum#valueOf(Class, String) is being used.

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[John D. Ament]

The intent of issue #248 was to convert the Pizza class from having a single argument constructor to having a 2 argument constructor. This would remove the issue that implementations that already supported common sense conversion failed the TCK in the case the PizzaConverter was not registered.  Unfortunately I haven't had as much availability to answer these questions, but I was surprised when it became that these features were now expected.

A couple more comments inline.

On Thursday, December 7, 2017 at 4:29:14 PM UTC-5, Emily Jiang wrote:

I am sorting the next MP config release and have a question on one of the changes under the issue #248

Since Config 1.1, we have added the following support under the issue #248

=== Automatic Converters

If no built-in nor custom Converter for a requested Type T, an implicit Converter is automatically provided if the following conditions are met:

• The target type T has a Constructor with a String parameter, or
• the target type T has a Constructor with a CharSequence parameter, or
• the target type T has a static T valueOf(String) method, or
• the target type T has a static T valueOf(CharSequence) method, or
• the target type T has a static T parse(String) method, or
• the target type T has a static T parse(CharSequence) method, or
• the target type T is an Enum, in which case the Enum#valueOf(Class, String) is being used.

Technically, this last case isn't needed.  When an Enum type is created, it automatically gets a T.valueOf method.

 

In the original discussion of #248, I only suggested to add he following common support:

The target type T has a Constructor with a String parameter
the target type T has a static T valueOf(String) method,

The above will cover most scenarios and it is straightforward.

The current codebase introduces too many variety and in the spec we need to specify the search order, e.g. Constructor(String)-> Constructor(CharSequence)->valueOf(String).... I feel this complicates the spec without much gain. What do people think on removing the CharSequence support, parse and Enum, while just keep the above two support. Besides, we are providing a convenient method. If anyone wants to use CharSquence, they can provide their own converter. Thoughts?

I'll add my thoughts to the github issue.

[Ladislav Thon]

2017-12-08 1:22 GMT+01:00 John D. Ament <john.d...@gmail.com>:

Technically, this last case isn't needed.  When an Enum type is created, it automatically gets a T.valueOf method.

Ah, right, I didn't remember that. My comment above is void, then.

LT

[Emily Jiang]

Thank you John! You were right about enum, which are implementation details. The implementation will use reflection to invoke the method valueOf.

Since both LT and you support my suggestion, if I don't hear any objections by COB today. I'll go ahead to remove the charSequence bits.

Emily

[Ladislav Thon]

Dne 8. 12. 2017 11:06 napsal uživatel "'Emily Jiang' via Eclipse MicroProfile" <microp...@googlegroups.com>:

Since both LT and you support my suggestion

I specifically and intentionally abstained from expressing agreement or disagreement, I just said that I understand the desire :-) In fact, my personal opinion on API design is that breaking compatibility is universally bad and should be avoided unless very good arguments are presented. Whether this is the case or not, I don't feel qualified to decide, as I'm mostly a lurker here and don't really know the MP community.

LT

, if I don't hear any objections by COB today. I'll go ahead to remove the charSequence bits.

Emily

On Friday, December 8, 2017 at 7:34:48 AM UTC, Ladislav Thon wrote:

2017-12-08 1:22 GMT+01:00 John D. Ament <john.d...@gmail.com>:

Technically, this last case isn't needed.  When an Enum type is created, it automatically gets a T.valueOf method.

Ah, right, I didn't remember that. My comment above is void, then.

LT

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f0d09c83-e171-4be7-a20e-f82a93848fac%40googlegroups.com.

[Emily Jiang]

LT,

The changes in question has not been released as yet. I'm in the middle of doing the release. I would like to put it right in the first release. My view is to add just the most important and minimal in the first release and then add more if needed. Hence the discussion.

Emily

On Saturday, December 9, 2017 at 6:12:07 AM UTC, Ladislav Thon wrote:

Dne 8. 12. 2017 11:06 napsal uživatel "'Emily Jiang' via Eclipse MicroProfile" <microp...@googlegroups.com>:

Since both LT and you support my suggestion

I specifically and intentionally abstained from expressing agreement or disagreement, I just said that I understand the desire :-) In fact, my personal opinion on API design is that breaking compatibility is universally bad and should be avoided unless very good arguments are presented. Whether this is the case or not, I don't feel qualified to decide, as I'm mostly a lurker here and don't really know the MP community.

LT

, if I don't hear any objections by COB today. I'll go ahead to remove the charSequence bits.

Emily

On Friday, December 8, 2017 at 7:34:48 AM UTC, Ladislav Thon wrote:

2017-12-08 1:22 GMT+01:00 John D. Ament <john.d...@gmail.com>:

Technically, this last case isn't needed.  When an Enum type is created, it automatically gets a T.valueOf method.

Ah, right, I didn't remember that. My comment above is void, then.

LT

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Mark Struberg]

The reason for having the CharSequence variants is that most JVM classes - and also many other frameworks API classes - do not have a String ct but CharSequnce. 

Simply because String extends CharSequence.

That's the reason why I added this variant. Simply because otherwise we would miss 75% use cases.

LieGrue,

strub

[Emily Jiang]

We are converting String to a type for config value, not to cover every single JVM class. I don't think the aim here is to cover all type of classes but the often used classes or the custom type(which has valueOf or string based constructor). I have not found a need to create a class containing a valueOf(CharSequence) as yet. Remember this is just a convenient converter we are supplying. For the cases not covered, a converter can be created.

I would like to start small and add more in the future, not do a fully loaded but less used model. Stay simple and easy!

Emily

[Craig McClanahan]

Peanut gallery comment, but still relevant.

I like Emily's preference for simple, but it seems like the simplest solution is to have a converter for CharSequence and dispense with the one for String since it is redundant (already covered by the CharSequence version).  No need to worry about extending the model later.  And yes, I've run into more than a few APIs that deal with CharSequence and therefore by subclassing deal with String as well.

Craig McClanahan

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6f15242e-6bad-4df5-ac3f-bfe1aa53aba3%40googlegroups.com.

[Alasdair Nottingham]

From the perspective of the person writing the class  you are right that if they create a valueOf(CharSequence) method then you could pass a String into it, but it doesn’t get the use cases Emily has in mind. I think Java enumerations are a key one as I’ll illustrate

@Inject

@ConfigProperty(name=“aProp”, defaultValue=“A”);

public MyEnum aProp;

In this case my Enum looks like this:

  public enum MyEnum {

    A, B, C

  }

The way Emily has it defined the implicit converter can essentially do this:

MyEnum.class.getMethod(“valueOf”, String.class).invoke(null, configSource.getValue("aProp”));

if you define it as CharSequence then that would result in a NoSuchMethodException. The consequence of this is enums don’t get converted.  

I think it is a no brainer that we have to do valueOf(String) for the enum case. Java SE 8 Javadoc shows 103 valueOf(String) methods, while most are enums there is also: Boolean, Long, Integer, Float, Double, Byte, Short, QName, java.sql.Timestamp, java.sql.Date. On the other hand valueOf(CharSequence) hits zero.

While I was looking at the Java class libraries I also looked at parse methods. There are 4 static parse(String) methods (1 of those is deprecated), and 12 instances of static parse(CharSquence). 

I then did a search on javadoc.io for use of static valueOf(String and saw the following libraries use this method name: Jackson, Gson, Mockito, Json-P (woo, MicroProfile) Couchbase, Apache Sling, Guava. There were more, but I stopped looking. I couldn’t find any instances of valueOf(CharSequence).

I did start to google for parse(String) and parse(CharSequence), but it was looking similar to valueOf(CharSequence) so I got bored and stopped looking.

I don’t think this is scientific by any means, and I’m sure I missed a lot of stuff, but based on what I saw I think Emily’s proposal is reasonable. I might suggest adding in support for public static T parse(CharSequence) because it would get the types in java.time, but that is it. 

Alasdair

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CANgkmLCkGdZnDz3XS7%2BsnnC_XbpLNThuiH%3Dtrfz9RP57CfytPw%40mail.gmail.com.

[Mark Struberg]

Hi Craig!

Well, it's not really redundant because:

* While String implements CharSequence those are two different signatures from a java.lang.reflect pov. By just saying ct(String) we would all those with ct(CharSequence). And there are plenty of those!

* You could even have both, a ct(String) and a ct(CharSequence) (same for valueOf and parse methods ofc). In which case we define an order which one is taken.

It also only adds 3 more lines to our list to also support all those types which use CharSequence in their signatures instead of String. And as you already said yourself: there are PLENTY!

LieGrue,

strub

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Mark Struberg]

> if you define it as CharSequence then that would result in a NoSuchMethodException. The consequence of this is enums don’t get converted.  

+1. That's exactly what I meant. Thus I suggest to explicitly support both (in a well defined order).

LieGrue,

strub

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6f15242e-6bad-4df5-ac3f-bfe1aa53aba3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Emily Jiang]

Mark,

Did you read the whole email from Alasdair? You only took one sentence out of context. Basically, the overall conclusion is that it is not useful to include CharSequence. We should leave it out. We can always increase the scope if someone really need it in a business scenario.

By the way, for the exception you mentioned, the impl should deal with it with a noop and the value will not be converted. How many people define a valueOf with a CharSquence parameter? Pretend someone might do, the only thing is that they need to define a converter for the odd enum if they want to converter a string to enum.

Alasdair,

I prefer to stay simple in the first support and only add the essential bit. We can add parse later if there is a real business need for it. It is much easier to grow but not shrike.

Emily

[Alasdair Nottingham]

I think I outlined the business need for it. The java.time package in Java 8 all uses parse(CharSequence) so if it is supported you can convert from String to the java.time types. I would think having support for dates and times would be useful.

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a0850bfe-b50e-48b3-a26b-f270dc229711%40googlegroups.com.

[Emily Jiang]

ah, sorry. You were quite right, Alasdair. yes, parse(CharSequence) will be added to support java.time packages.

Emily

Alasdair

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a0850bfe-b50e-48b3-a26b-f270dc229711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/TkqdvNqwLkA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/13F18887-C429-4C9C-81C8-D1F3DAD623B6%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks
Emily
=================
Emily Jiang
eji...@apache.org

[Mark Struberg]

if we have a mixture of some method names with String and others with CharSequence then users will aks us if we went nuts.

This is quite a nightmare from a user pov. Either we support ct, valueOf and parse with ONLY String, of we support ALL of them with String AND CharSequence.

In my opinion any wild mixture would just confuse users.

LieGrue,

strub

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a0850bfe-b50e-48b3-a26b-f270dc229711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/TkqdvNqwLkA/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/13F18887-C429-4C9C-81C8-D1F3DAD623B6%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Emily Jiang]

I am against the idea to have both String and CharSequence for all of the methods. With the mix, it means we did some research and only blindly put stuff in. I don't see any confusion. To be honest, most scenario will be covered by constructor with a string parameter or valueOf(String). The parse(CharSequence) is only for java.time package. I don't see the usage much from developer point of view.

Emily

[Mark Struberg]

From a vendor perspective it is not more work to support all variants with both String and CharSequence, right? I mean I've done that - it's even way more straight ahead than to mix.

Ok, and from a a user perspective it's also much more consistent, right?

What you forgot is that there are not even lots of ct(CharSequence) but also tons of parse(String). And you would not support those neither.

So a user has to know that 

* A valueOf ONLY works with String (not with CharSequence)

* A parse ONLY works with CharSequence as param (not with String)

Now have fun explaining this to a casual developer ;)

LieGrue,

strub

[Emily Jiang]

It is not about how easy to implement. I don't think user needs to worry about parse at all. It was added purely for java.time. I am interested to see how others think.

Emily

[Arjan Tijms]

Btw slightly related to this, but arguably the biggest part of the MP-JWT spec concerns an implicit converter as well.

The base JSON data has to be implicitly converted to a plethora of other types (I think about 30+ permutations all together). Would it make sense to move all of this to a separate Converter spec that both Config and JWT could use?

[Alasdair Nottingham]

Seems to me it is more work since it involves more lines of code. I didn’t find tons of static parse(String) methods when I went looking. 

Alasdair Nottingham

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d0b320da-9e1c-47c0-8fbe-31b990e850ae%40googlegroups.com.

[Mark Struberg]

Rest assured that it is *not* more work. It is essentially the same. Just invoke a method a second time with another param. It's really peanuts. 

And you also should look at all the various other big framework projects, like Guava, Apache commons, Vaadin, OSGi, etc

THE main point is consistence though.

@Arjan: yes, thought about it as well. But for a real converter spec you would need both directions String -> T and T -> String

In Config we only need String -> T.

There are quite a few other areas which could benefit, e.g. JSF. But not sure if we get a chance to start yet another JSR ;)

LieGrue,

strub

[Arjan Tijms]

On Thursday, December 21, 2017 at 9:51:30 PM UTC+1, Mark Struberg wrote:

@Arjan: yes, thought about it as well. But for a real converter spec you would need both directions String -> T and T -> String

In Config we only need String -> T.

There are quite a few other areas which could benefit, e.g. JSF. But not sure if we get a chance to start yet another JSR ;)

Indeed, JSF and various other specs. For a list of specs that could benefit (currently would be even more), see this older article:

http://arjan-tijms.omnifaces.org/2014/08/high-time-to-standardize-java-ee.html

[Emily Jiang]

I don't think it is a valid argument here. Why should the parameter needs to be same type? I do not see a problem here. There is no point to achieve symmetric just for the sake of being symmetric.

Emily

[Mark Struberg]

> I don't think it is a valid argument here. 

> I do not see a problem here. 

That's a non-argument, Emily ;)

> Why should the parameter needs to be same type? 

> There is no point to achieve symmetric just for the sake of being symmetric.

It's not about symmetricity. It is about having simple, concise and *consistent* rules which are easy to grasp. 

We do not want to have our users need to know which combination of name + parameter is valid.

It should be kind of self-explaining.

LieGrue,

strub

[Emily Jiang]

>That's a non-argument, Emily ;)

cool. A discussion.

> Why should the parameter needs to be same type? 

> There is no point to achieve symmetric just for the sake of being symmetric.

It's not about symmetricity. It is about having simple, concise and *consistent* rules which are easy to grasp. 
We do not want to have our users need to know which combination of name + parameter is valid.
It should be kind of self-explaining.

This thread is to reduce the complexility of the rules while just having 3 things instead of 6 things to remember while the left out 3 things are hardly used.

Emily

[Mark Struberg]

But this 'reduction' leads from 'all works out of the box' to 'only a short list of selected combinations of criteria works'.

What about that:

* Tell me the pros for reducing the functionality

* Tell me the downsides of reducing the functionality

* Tell me what would be the problem with implementing the full functionality

LieGrue,

strub

[Emily Jiang]

Downsides: please read my first note in this thread. It lists why I brought this up.

Please list your use case here: which class you want to convert under which usage? Please provide a proof. Also, may I suggest you to open a poll to see how many support you get. Otherwise, we just talk on theories.

I'll be off soon and may not check my emails frequently.

Have a good Christmas to you all!

Emily

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/TkqdvNqwLkA/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6161aaca-00a9-4c7a-966d-58945b3f6923%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark Struberg]

So here is your original post

> In the original discussion of #248, I only suggested to add he following common support:

> The target type T has a Constructor with a String parameter

> the target type T has a static T valueOf(String) method,

Many of the follow up posts from different people CLEARLY stated that this is not enough. 

Obviously all the java.time types use a CharSequence parameter. You already accepted this it seems.

But there are really tons of constructors and valueOf out there which use CharSequence as parameter as well. 

E.g. 

org.apache.activemq.protobuf.compiler.TextFormat.Tokenizer, org.fusesource.jansi.AnsiString, and many many more.

A random search by google reveals thousands of usages.

Just adding a few from github to give you an impression:

https://github.com/okkam-it/flink-examples/blob/master/src/main/java/org/okkam/flink/parquet/avro/PhoneNumberStr.java#L29

https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-api/src/main/java/org/apache/logging/log4j/message/SimpleMessage.java#L53

https://github.com/lordrex34/l2emu/blob/master/L2EmuProject-Commons/src/main/java/net/l2emuproject/lang/Replaceable.java#L200

https://github.com/stoerr/JScience4-Fixed/blob/master/src/javax/measure/DecimalMeasure.java#L79

https://github.com/stoerr/JScience4-Fixed/blob/master/src/org/jscience/mathematics/number/Integer64.java#L111

So what is the downside of also supporting all these out of the box? So far you didn't bring any argument but have just referred to your initial post - which already got proven wrong.

LieGrue,

strub

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6161aaca-00a9-4c7a-966d-58945b3f6923%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Emily Jiang]

The current codebase introduces too many variety and in the spec we need to specify the search order, e.g. Constructor(String)-> Constructor(CharSequence)->valueOf(String).... I feel this complicates the spec without much gain. What do people think on removing the CharSequence support, parse and Enum, while just keep the above two support. Besides, we are providing a convenient method. If anyone wants to use CharSquence, they can provide their own converter.

Is the above clear?

I raised the above in the config repo (https://github.com/eclipse/microprofile-config/issues/269). You can either comment here or directly on the issue.

Besides, only Alsadair suggested to add one more parse for CharSequence support. I did not see anyone else challenged me.

You listed some random classes. As they are 3rd library, if you want to use them as config value, which I have not thought of a use case for this. One of the solution is to provide a converter. By the way, can you list when and how it is used for config types? How many config library support what the 6 combination of converters?

Emily

[Alasdair Nottingham]

Hi,

I’m not sure I understand what you are proposing. Are you saying only a String constructor will be supported?

Alasdair Nottingham

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4e14e712-64b7-4c70-ba27-cae3c1e247c8%40googlegroups.com.

[Emily Jiang]

Hi Alasdair,
Just came back from vacation. Not sure whose propose you have questions. Anyway,
the current support (my proposed solution) is to support:

String constructor, valueOf(String) and parse(CharSequence)

Mark asks for
String constructor, CharSequence constructor, valueOf(String), valueOf(CharSequence), parse(String), parse(CharSquence).

Hope this is clearer.

Emily