Java 7 vs. Java 8

["Tresch, Anatole " <an...@credit-suisse.com>]

Hi all

I have a couple of questions regarding the current state:


1)    In Java 7 we have introduced a ConfigurationProvider, which is necessary, since static methods on interfaces are not supported by Java 7. In Java 8 we introduced the according Configuration.current(). I would in that case deprecate ConfigurationProvider, since its only there for backward compatibility and basically not needed anymore. Agreed?

2)    As discussed shortly on our last hangout, I have added ConfigOperator and ConfigQuery which are normal interfaces in Java 7, but usable as functional interfaces in Java 8. This is needed since java.util.function is not available on Java 7.

3)    Currently PropertyConverter is currently a functional interface, which basically is nice, but there are a couple of reasons I think, it requires additional methods:

a.    there is already a comment to add a method on the provider that returns examples of the formats supported, so error messages and exceptions can easily be filled with more explicit information on the formats effectively supported by the converters registered.

b.    Currently different converters can be priorized by adding a @Priority annotation. Nevertheless the ConfigurationContext has not information about the target type a converter is supported, due to runtime type erasure. Since I think, trying every converter available for each type is very ineffective and error prone, I would suggest an additional method as follows:
Class<T> getTargetType();
This would easily allow to manage the different converters by the regarding target type. PropertyConverter instances then would be registered for the target type and all its super-types, except Object. So a converter for MySpecialBigDecimal would similarly also be usable for BigDecimal (which MySpecialBigDecimal extends).
WDYT?

Anatole



Anatole Tresch
Platform Strategy & Strategic Projects, KGVX 42
+41 44 334 03 89 (*414 0389)

Re: Java 7 vs. Java 8

[Romain Manni-Bucau <rm...@gmail.com>]

Hello

2015-01-13 10:27 GMT+01:00 Tresch, Anatole <an...@credit-suisse.com>:
> Hi all
>
> I have a couple of questions regarding the current state:
>
>
> 1)    In Java 7 we have introduced a ConfigurationProvider, which is necessary, since static methods on interfaces are not supported by Java 7. In Java 8 we introduced the according Configuration.current(). I would in that case deprecate ConfigurationProvider, since its only there for backward compatibility and basically not needed anymore. Agreed?
>

-0, for me provider != current() - even if it is the default. It is
really a factory impl IMO and makes sense even in j8 otherwise you mix
concerns between context and provider IMO.

> 2)    As discussed shortly on our last hangout, I have added ConfigOperator and ConfigQuery which are normal interfaces in Java 7, but usable as functional interfaces in Java 8. This is needed since java.util.function is not available on Java 7.
>
> 3)    Currently PropertyConverter is currently a functional interface, which basically is nice, but there are a couple of reasons I think, it requires additional methods:
>
> a.    there is already a comment to add a method on the provider that returns examples of the formats supported, so error messages and exceptions can easily be filled with more explicit information on the formats effectively supported by the converters registered.
>
> b.    Currently different converters can be priorized by adding a @Priority annotation. Nevertheless the ConfigurationContext has not information about the target type a converter is supported, due to runtime type erasure. Since I think, trying every converter available for each type is very ineffective and error prone, I would suggest an additional method as follows:
> Class<T> getTargetType();
> This would easily allow to manage the different converters by the regarding target type. PropertyConverter instances then would be registered for the target type and all its super-types, except Object. So a converter for MySpecialBigDecimal would similarly also be usable for BigDecimal (which MySpecialBigDecimal extends).
> WDYT?
>

Take care handling the hierarchy, it can create conflicts where
actually there is no conflicts at all + that's not cause you know how
to handle a car that you can hanle a vehicle properly. In between
solution would be to use a weight between converter type and current
type and use the smaller but I find it very complicated for cases I
think rare.

That said linking a converter to a type is quite mandatory (using
getTargetType() or rather register(Type type, Converter converter))

> Anatole
>
>
>
> Anatole Tresch
> Platform Strategy & Strategic Projects, KGVX 42
> +41 44 334 03 89 (*414 0389)
>