Thought on multiplicity of properties in Java

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Martin Desruisseaux" <martin.desruisseaux at geomatys.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Lundi 17 Septembre 2018 10:21:50
> Objet: Re: Thought on multiplicity of properties in Java

> Hello Rémi

Hi Martin,

> 
> Thanks for your reply.
> 
> Le 17/09/2018 à 00:54, Remi Forax a écrit :
> 
>> The Java spec limit covariance to subtyping relationship only (there
>> is no covariance between primitive types, or between a primitive type
>> and it's corresponding wrapper), so you can not use Java to implement
>> overriding of UML properties with different multiplicity. But if you
>> generate the bytecode instead of generating Java code to generate the
>> interfaces, you are not limited by the Java spec, so you can generate
>> the bridge methods you want.
>>
> Yes I know. My question was if "multiplicity covariance" was something
> that may be worth considering at the Java language level for some future
> version of the specification. This is not a request to do so, only an idea.

I don't think it's a good idea. i see three flaws:
- theoretically, the covariance is defined in term of sub-typing, trying to widen it's definition may have unintended consequences that need studying.
- technically, we can implement whatever conversions we want because the "convariance conversion" is implemented using brige, but we may not implement that the "covariance conversion" using bridges in the future if by example we do some kind of reification of the type arguments, so this may hamper the possible futures of Java.
- the conversion from Optional to a List is not a conversion already defined by the JLS, this need also to be specified because there is no reason to limit this conversion to only the covariance case, by example if you have an Optional<String> named opt, this statement List<String> list = opt; should compile. This means that you have to formally defines the conversion and perhaps the reverse conversion too, Optional<String> opt2 = (Optional<String>)list; at that point you are not backward compatible with the current JLS because this code currently always throws a CCE.


> 
>    Regards,
> 
>         Martin

regards,
Rémi