[External] : Re: New candidate JEP: 431: Sequenced Collections

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Stuart Marks" <stuart.marks at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Sunday, October 16, 2022 12:25:18 AM
> Subject: Re: [External] : Re: New candidate JEP: 431: Sequenced Collections

> Hi Rémi,
> 
> On 10/14/22 1:20 AM, Remi Forax wrote:
>> People will again think that i'm the grumpy guy but i prefer to voice my
>> concerns.
>> 
>> - nobody cares, i'm back from Devoxx and nobody cares about Sequenced
>> Collections, i've tried to ask several friends what they think about it and the
>> answer was "meh".
>>    The bar to introduce new interfaces in the collection API is really really high
>>    given how the Java ecosystem works.
>>    Once a library starts to use those interfaces as method parameter, it pressures
>>    the other library authors to write methods that provides object typed as those
>>    interfaces.
>>    Not enough people care and the cost for the community (not only Oracle) is high,
>>    it looks like a recipe for failure.
> 
> Fortunately, we don't make decisions in OpenJDK via opinion polls. :-)

We still have users tho.

> 
> I'm obviously not in a position to address the concerns of your interlocutors.
> However, the history in the bug database and the recurring discussions on
> core-libs-dev (some of which are linked in the JEP) show the need for this.

There are several feature requests that can be bundled into this JEP, but that not the only ways to implement those requests.

> 
> Introduction of new types always poses a dilemma for library maintainers. They
> can
> move forward aggressively and embrace new features, or they can remain on older
> releases in order to reach a broader audience. That's not a reason to avoid
> introducing new types.

I agree in absolute, but in this specific case you want to introduce interfaces deep into the existing hierarchy of interfaces, not on the top.
The introduction of CharSequence has been painful and very slow, that interface was added in 1.4 but we had to wait 9 more than 10 years later to have parseInt() that takes a CharSequence.
As an application developer, a decade is the kind of time i will have to wait before i can use a sequenced collection.

Adding default methods is far faster in term of adoption, computeIfAbsent or removeIf were available at the time of the release of 1.8.
Default methods have issues too, it only works if a good default implementation exists.

> 
>> - LinkedHashMap can be tweaked in two ways, by passing an access order as 3rd
>> parameter of the constructor or by overriding removeEldesEntry(), in both cases
>> the resulting LinkedHashMap is at odds with the contract of SequencedMap but
>> the compiler will happily allow to see those LinkedHashMap as SequencedMap.
> 
> SequencedMap specifies that entries have an encounter order but it doesn't make
> any
> requirements on how that order is established. LinkedHashMap's access-order mode
> is
> unusual in that it specifies that specific methods additionally have the side
> effect
> of reordering the relevant entry. The removeEldestEntry() method modifies the
> behavior of mapping-insertion methods to optionally remove the first ("eldest")
> entry. Neither of these behaviors conflicts with anything in SequencedMap.

It conflicts with the idea of the first element (or last element)
  SequencedSet set = ...
  var first = set.getFirst();
  assertNotNull(first);
  set.add("foo");
  var first2 = set.getFirst();
  assertEquals(first, first2);   // should always be true, right ?


> 
>> - LinkedHashMap/LinkedHashSet are dinosaurs, there are more efficient
>> implementations of the concepts of ordered set / ordered map both in term of
>> memory footprint and runtime execution, so adding new interfaces without
>> exploring new implementations using Valhalla value class and in relation with
>> the Collection Literal JEP seems premature to me.
> 
> LinkedHashMap and LinkedHashSet are in fact used fairly frequently. They're not
> used
> as much as HashMap, but they're used more than ArrayDeque or TreeMap. Presumably
> this is because people find LinkedHashMap/Set useful and that the overhead
> compared
> to their non-linked counterparts is acceptable for the additional services they
> provide.
> 
> The performance and footprint of LinkedHashMap/Set are not impacted either way
> by
> the JEP, nor are any potential future performance improvements (including those
> that
> might arise because of Valhalla) precluded by the JEP.

I don't disagree with all you say above, i'm saying that with Valhalla, we need to explore implementations of HashMap based on open addressing to get better cache performance.
So adding addFirst() to LinkedHashMap now, is a risk.

Also, addFirst on a sequenced collection is a dangerous method, exactly like List.get() is, depending on the implementation the worst case complexity can be either O(1) or O(n).
I believe we will all live in a better place if we do not add new methods with such "complexity range".

> 
> s'marks

regards,
Rémi