RFR: 8368178: Add specialization of SequencedCollection methods to emptyList, singletonList and nCopies [v2]

[Per Minborg]

On Mon, 22 Sep 2025 07:22:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> @minborg `EmptyList` already implements it, as any other `List`:
>> 
>> public interface List<E> extends SequencedCollection<E> { ... }
>> 
>> 
>> For `EmptyMap` (and even `SingletonMap` and `SingletonSet`), it's possible, but it will require changing the public interface (`Collections::emptyMap` will have to return `SequencedMap`), which may produce binary compatibility issues. Probably we can invent a binary-compatible signature like this:
>> 
>> 
>> public static final <K,V,M extends Map<K, V> & SequencedMap<K, V>> M emptyMap() { ... }
>> 
>> But it looks ugly.
>
> @amaembo `SequencedMap` already implements `Map`.  :-) So, we could say:
> 
> 
> public static final <K,V> SequencedMap<K, V> emptyMap() { ... }
> 
> 
> An empty map could also "incidentally" implement `SequencedMap`.

> > @minborg as JLS 13.4.15 says,
> > > Changing the result type of a method, or replacing a result type with void, or replacing void with a result type, has the combined effect of deleting the old method and adding a new method with the new result type or newly void result
> > 
> > 
> > Changing the result type from `Map` to `SequencedMap` will modify the binary signature, so compiled classes that used this method previously will fail with `NoSuchMethodError`. That's why simply changing `Map` to `SequencedMap` is not quite possible. My trick with `M extends Map<K, V> & SequencedMap<K, V>` employs the fact that the type parameter gets erased to its first bound, which is `Map`, so such kind of return type replacement is safe (but ugly).
> 
> Thanks for that JLS reference, Tagir.
> 
> @minborg, one would think they can make a method accept wider arguments or return narrower results. After all, it matches basic subtype intuitions. Yet, one cannot do that; they will get java.lang.NoSuchMethodError from code that uses the old method. FWIW, I tripped on it myself a few times.

Yeah, I get that. Another alternative would be not to expose the type in the API, but instead let the map instance returned from the method implement `SequencedMap`. A dynamic instanceof would then potentially benefit from this. Maybe there are situations that are less good as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27406#issuecomment-3318996371