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 >