ReversibleCollection proposal

[Remi Forax]

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> À: "Peter Levart" <peter.levart at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Stephen Colebourne" <scolebourne at joda.org>
> Envoyé: Mercredi 28 Avril 2021 02:04:22
> Objet: Re: ReversibleCollection proposal

> On 4/27/21 2:25 AM, Peter Levart wrote:
>> Right, I'm persuaded. Now if only the problems of transition to the usage of new
>> type that Remi is worried about were mild enough. Source (in)compatibility is
>> not
>> that important if workarounds exist that are also backwards source compatible so
>> that the same codebase can be compiled with different JDKs. Binary compatibility
>> is
>> important. And I guess there is a variant of the proposal that includes
>> ReversibleCollection and ReversibleSet and is binary compatible.
> 
> Yes, the source incompatibilities with the types seem to involve type inference
> (e.g., use of var choosing differently based on new types in the library) so it
> should be possible to make minor source code changes to adjust or override the
> type
> that's inferred.
> 
> On binary compatibility, that comes mostly from the newly introduced methods
> (reversed, addFirst etc.) and from adding covariant overrides to LinkedHashSet.
> I
> guess the "variant" you mention is adding new methods with the new return types
> (e.g., reversibleEntrySet) instead of covariant overrides. Or was it something
> else?

Yes, you need type inference (compute lub), var is not necessary,
after all
  var a = f();
  g(a)
is equivalent to
  g(f())

So you have an issue with varargs like T..., any method that takes two T like m(T, T), or with the ternary operator ?:

At best you have a source compatibility issue, at worst, you have a runtime error or a runtime slowdown.
This is something that have not been study well but the worst scenario is when a VarHandle or a MethodHandle is involved IMO,
because a call like methodHandle.invokeExact() or VarHandle.compareAndSet will still compile if the inferred type changed but at runtime at best you will have a WrongMethodTypeException, at worst it will still work but performance will fall of the cliff.

But maybe nobody has ever written a code like
  methodHandle.invoke(flag? list: linkedHashMap)

Also the source compatibility issues are not only restricted to Java
- source compatiblity can also be a bigger issue than it was before for people that are using jshell/java as a shell script. 
- and what about the other JVM languages that are using the collection API, mostly Groovy and Kotlin because they are leveraging inference far more than in Java.
  Scala tends to use Scala collection, and Clojure or JRuby are dynamically typed so it should not be less an issue.

> 
> s'marks

Rémi