The introduction of Sequenced collections is not a source compatible change

[Joseph D. Darcy]

A few comments on the general compatibility policy for the JDK. 
Compatibility is looked after by the Compatibility and Specification 
Review (CSR) process ( Compatibility & Specification Review). 
Summarizing the approach,

> The general compatibility policy for exported APIs implemented in the 
> JDK is:
>
>     * Don't break binary compatibility (as defined in the Java 
> Language Specification) without sufficient cause.
>     * Avoid introducing source incompatibilities.
>     * Manage behavioral compatibility changes.

https://wiki.openjdk.org/display/csr/Main

None of binary, source, and behavioral compatibly are absolutes and 
judgement is used to assess the cost/benefits of changes. For example, 
strict source compatibility would preclude, say, introducing new public 
types in the java.lang package since the implicit import of types in 
java.lang could conflict with a same-named type *-imported from another  
package.

When a proposed change is estimated to be sufficiently disruptive, we 
conduct a corpus experiment to evaluate the impact on the change on many 
public Java libraries. Back in Project Coin in JDK 7, that basic 
approach was used to help quantify various language design choices and 
the infrastructure to run such experiments has been built-out in the 
subsequent releases.

HTH,

-Joe
CSR Group Lead

On 5/4/2023 6:32 AM, Ethan McCue wrote:
> I guess this a good time to ask, ignoring the benefit part of a cost 
> benefit analysis, what mechanisms do we have to measure the number of 
> codebases relying on type inference this will break?
>
> Iirc Adoptium built/ran the unit tests of a bunch of public repos, but 
> it's also a bit shocking if the jtreg suite had nothing for this.
>
> On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti 
> <raffaello.giulietti at oracle.com> wrote:
>
>     Without changing the semantics at all, you could also write
>
>             final List<Collection<String>> list =
>     Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
>
>     to "help" type inference.
>
>
>
>
>     On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
>     > Another example sent to me by a fellow French guy,
>     >
>     >      final Deque<String> nestedDequeue = new ArrayDeque<>();
>     >      nestedDequeue.addFirst("C");
>     >      nestedDequeue.addFirst("B");
>     >      nestedDequeue.addFirst("A");
>     >
>     >      final List<String> nestedList = new ArrayList<>();
>     >      nestedList.add("D");
>     >      nestedList.add("E");
>     >      nestedList.add("F");
>     >
>     >      final List<Collection<String>> list =
>     Stream.of(nestedDequeue, nestedList).toList();
>     >
>     > This one is cool because no 'var' is involved and using
>     collect(Collectors.toList()) instead of toList() solves the
>     inference problem.
>     >
>     > Rémi
>     >
>     > ----- 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.java.net>
>     >> Sent: Tuesday, May 2, 2023 2:44:28 AM
>     >> Subject: Re: The introduction of Sequenced collections is not a
>     source compatible change
>     >
>     >> Hi Rémi,
>     >>
>     >> Thanks for trying out the latest build!
>     >>
>     >> I'll make sure this gets mentioned in the release note for
>     Sequenced
>     >> Collections.
>     >> We'll also raise this issue when we talk about this feature in
>     the Quality
>     >> Outreach
>     >> program.
>     >>
>     >> s'marks
>     >>
>     >> On 4/29/23 3:46 AM, Remi Forax wrote:
>     >>> I've several repositories that now fails to compile with the
>     latest jdk21, which
>     >>> introduces sequence collections.
>     >>>
>     >>> The introduction of a common supertype to existing collections
>     is *not* a source
>     >>> compatible change because of type inference.
>     >>>
>     >>> Here is a simplified example:
>     >>>
>     >>>     public static void m(List<Supplier<? extends Map<String,
>     String>>> factories) {
>     >>>     }
>     >>>
>     >>>     public static void main(String[] args) {
>     >>>  Supplier<LinkedHashMap<String,String>> supplier1 =
>     LinkedHashMap::new;
>     >>>  Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>     >>>       var factories = List.of(supplier1, supplier2);
>     >>>       m(factories);
>     >>>     }
>     >>>
>     >>>
>     >>> This example compiles fine with Java 20 but report an error
>     with Java 21:
>     >>>     SequencedCollectionBug.java:28: error: method m in class
>     SequencedCollectionBug
>     >>>     cannot be applied to given types;
>     >>>       m(factories);
>     >>>       ^
>     >>>     required: List<Supplier<? extends Map<String,String>>>
>     >>>     found:    List<Supplier<? extends
>     SequencedMap<String,String>>>
>     >>>     reason: argument mismatch; List<Supplier<? extends
>     SequencedMap<String,String>>>
>     >>>     cannot be converted to List<Supplier<? extends
>     Map<String,String>>>
>     >>>
>     >>>
>     >>>
>     >>> Apart from the example above, most of the failures I see are
>     in the unit tests
>     >>> provided to the students, because we are using a lot of 'var'
>     in them so they
>     >>> work whatever the name of the types chosen by the students.
>     >>>
>     >>> Discussing with a colleague, we also believe that this bug is
>     not limited to
>     >>> Java, existing Kotlin codes will also fail to compile due to
>     this bug.
>     >>>
>     >>> Regards,
>     >>> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230504/4ff82806/attachment.htm>