Use static factory method or constructor as fallback for implicit argument conversion

[juergenzimmermann]

Overview

Original Title: Introduce implicit argument conversion for UUID and URL

Original Description: In #1218 implicit arg conversion was introduced for Locale, URI, and Currency. I'd appreciate if also java.util.UUID and java.net.URL can be supported, by e.g. UUID.fromString(String name) and new URL(String) as @hisener did in #1221.

Related Issues

• Introduce implicit argument conversion for Locale, URI, and Currency #1218
• Introduce implicit argument conversion for UUID, URL, BigDecimal, BigInteger, File​, Path, Charset #1232

Current Proposal

See #1231 (comment) and #1231 (comment).

Deliverables

• Use static factory method or constructor as fallback for implicit argument conversion.
• Document in User Guide.
• Document in Release Notes.

[sormuras]

Good idea.

Which other "Java Foundation" classes should be supported?

[juergenzimmermann]

Maybe java.math.BigDecimal, java.math.BigInteger, and java.io.File​

[sormuras]

Mh... thinking about some "general magic" like:

1. For class T look for a public constructor with a single String parameter - if available, use it.
2. Look for a static factory method T of(String) - if available, use it.

This default fall-back would kick in before failing with "no conversion available".

[hisener]

@sormuras Are you working on this? I tried to implement something you said.

1. Checks a constructor with a String parameter as you said.
2. Checks static T methodName(String). methodName is also generic instead of of.

The code is available on hisener@8a425d8

[sormuras]

Ja, I'm on it. Cleanup the current implementation as well.

[sbrannen]

FYI: Spring has had generic conversion support for years. We considered doing something similar for parameterized tests but opted not to (yet). Though I was and still am in favor of a generic fallback mechanism.

For inspiration from Spring, check out ObjectToObjectConverter.

[sbrannen]

2. Checks static T methodName(String). methodName is also generic instead of of.

I'm afraid that technique is too risky: picking the first such possible candidate (via findFirst()) is unpredictable due to the fact that the JVM does not guarantee the order in which methods are returned via reflection.

Beyond that, it would be a bit too much of a surprise for my taste.

I think the best we can do is to support:

• constructors that accept a single string
• static factory methods that accept a single string, where the method is named either of or from

[sormuras]

Why the restriction on the factory name?

[sbrannen]

Ja, I'm on it. Cleanup the current implementation as well.

Let's be a bit cautious there: I don't want us to oversimplify things and use reflection all of the time for common use cases.

In other words, let's let ourselves be inspired by Spring in this regard, too: have hard-coded converters for common types and only use reflection as a fallback mechanism for common types we have yet to support and for user code that the framework cannot knowingly support.