For those who are tracking but didn't click through to find it, here was the writeup of the compatibility analysis for sequenced collections as of 9/20/22.
https://bugs.openjdk.org/secure/attachment/100811/compatibility-20220920.html Bug page: https://bugs.openjdk.org/browse/JDK-8266572 On Fri, May 5, 2023 at 12:08 AM Joseph D. Darcy <joe.da...@oracle.com> wrote: > PS And as a general policy, over the releases we've done more to > preserve source compatibility when possible for language changes. > > For example, there were many source compatibility breakages when > "assert" was added as a keyword back in JDK 1.4; the current keyword > management policies (https://openjdk.org/jeps/8223002), including > contextual keywords (JLS §3.9) and hyphenated-keywords, mitigate the > impact of analogous changes today. > > -Joe > > On 5/4/2023 7:47 PM, - wrote: > > In addition, in the CSR of sequenced collection, it already > > anticipated some other form of source incompatibility: > > If a class implements List and Deque at the same time, the return type > > of reversed() must extend both interfaces as well. > > > > This alone would be a greater source incompatibility than this type > > interference already; however, both are binarily compatible: > > Java doesn't care about generics at runtime, and for default > > reversed() overrides, reversed ()Ljava/util/List; and reversed > > ()Ljava/util/Deque; are distinct methods; code calling reversed via > > List or Deque interfaces will get the reversed version of respective > > interfaces, which are functionally correct as well. > > > > I personally would consider this type inference usage moot. It is same > > as adding another method addAll(List<String>) when there is already > > addAll(String[]): existing addAll(null) calls will break, but this is > > not a valid argument against adding a List<String> variant of addAll. > > > > On Thu, May 4, 2023 at 9:38 PM Joseph D. Darcy <joe.da...@oracle.com> > wrote: > >> 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.giulie...@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, fo...@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.ma...@oracle.com> > >>>>> To: "Remi Forax" <fo...@univ-mlv.fr> > >>>>> Cc: "core-libs-dev" <core-libs-...@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 >
