Since we have the notion of the implicit converter, it takes all classes with the following criteria:
If no explicit Converter and no built-in Converter could be found for a certain type,
With this, all built in converters are not required to be listed as they either have valueOf or a constructor taking a String parameter.
However, to improve the performance (as valueOf has a cache facility while the constructor does not have) and take into the new JVM class method naming scheme, I suggest we update the search sequence for the implicit converter.
With this change, we can remove the big list of the default converters and all of them falls under implicit converters. This will reduce the burden to keep on adding built in converters in the future. Any comments?
Emily
--
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/d2fbaa26-d91a-4878-824d-9a54a2934692%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Ondro
+1--Ondro
--
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/AOt7fVSqxcc/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/4f4b1dc6-7017-4b67-89c6-c7518a794f9d%40googlegroups.com.