<div dir="auto">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?<div dir="auto"><br></div><div dir="auto">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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti <<a href="mailto:raffaello.giulietti@oracle.com">raffaello.giulietti@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Without changing the semantics at all, you could also write<br>
<br>
        final List<Collection<String>> list = <br>
Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();<br>
<br>
to "help" type inference.<br>
<br>
<br>
<br>
<br>
On 2023-05-03 15:12, <a href="mailto:forax@univ-mlv.fr" target="_blank" rel="noreferrer">forax@univ-mlv.fr</a> wrote:<br>
> Another example sent to me by a fellow French guy,<br>
> <br>
>      final Deque<String> nestedDequeue = new ArrayDeque<>();<br>
>      nestedDequeue.addFirst("C");<br>
>      nestedDequeue.addFirst("B");<br>
>      nestedDequeue.addFirst("A");<br>
> <br>
>      final List<String> nestedList = new ArrayList<>();<br>
>      nestedList.add("D");<br>
>      nestedList.add("E");<br>
>      nestedList.add("F");<br>
> <br>
>      final List<Collection<String>> list = Stream.of(nestedDequeue, nestedList).toList();<br>
> <br>
> This one is cool because no 'var' is involved and using collect(Collectors.toList()) instead of toList() solves the inference problem.<br>
> <br>
> Rémi<br>
> <br>
> ----- Original Message -----<br>
>> From: "Stuart Marks" <<a href="mailto:stuart.marks@oracle.com" target="_blank" rel="noreferrer">stuart.marks@oracle.com</a>><br>
>> To: "Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank" rel="noreferrer">forax@univ-mlv.fr</a>><br>
>> Cc: "core-libs-dev" <<a href="mailto:core-libs-dev@openjdk.java.net" target="_blank" rel="noreferrer">core-libs-dev@openjdk.java.net</a>><br>
>> Sent: Tuesday, May 2, 2023 2:44:28 AM<br>
>> Subject: Re: The introduction of Sequenced collections is not a source compatible change<br>
> <br>
>> Hi Rémi,<br>
>><br>
>> Thanks for trying out the latest build!<br>
>><br>
>> I'll make sure this gets mentioned in the release note for Sequenced<br>
>> Collections.<br>
>> We'll also raise this issue when we talk about this feature in the Quality<br>
>> Outreach<br>
>> program.<br>
>><br>
>> s'marks<br>
>><br>
>> On 4/29/23 3:46 AM, Remi Forax wrote:<br>
>>> I've several repositories that now fails to compile with the latest jdk21, which<br>
>>> introduces sequence collections.<br>
>>><br>
>>> The introduction of a common supertype to existing collections is *not* a source<br>
>>> compatible change because of type inference.<br>
>>><br>
>>> Here is a simplified example:<br>
>>><br>
>>>     public static void m(List<Supplier<? extends Map<String, String>>> factories) {<br>
>>>     }<br>
>>><br>
>>>     public static void main(String[] args) {<br>
>>>       Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;<br>
>>>       Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;<br>
>>>       var factories = List.of(supplier1, supplier2);<br>
>>>       m(factories);<br>
>>>     }<br>
>>><br>
>>><br>
>>> This example compiles fine with Java 20 but report an error with Java 21:<br>
>>>     SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug<br>
>>>     cannot be applied to given types;<br>
>>>       m(factories);<br>
>>>       ^<br>
>>>     required: List<Supplier<? extends Map<String,String>>><br>
>>>     found:    List<Supplier<? extends SequencedMap<String,String>>><br>
>>>     reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>><br>
>>>     cannot be converted to List<Supplier<? extends Map<String,String>>><br>
>>><br>
>>><br>
>>><br>
>>> Apart from the example above, most of the failures I see are in the unit tests<br>
>>> provided to the students, because we are using a lot of 'var' in them so they<br>
>>> work whatever the name of the types chosen by the students.<br>
>>><br>
>>> Discussing with a colleague, we also believe that this bug is not limited to<br>
>>> Java, existing Kotlin codes will also fail to compile due to this bug.<br>
>>><br>
>>> Regards,<br>
>>> Rémi<br>
</blockquote></div>