<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>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,</p>
<p>
<blockquote type="cite">The general compatibility policy for
exported APIs implemented in the JDK is:<br>
<br>
* Don't break binary compatibility (as defined in the Java
Language Specification) without sufficient cause.<br>
* Avoid introducing source incompatibilities.<br>
* Manage behavioral compatibility changes.</blockquote>
</p>
<p><a class="moz-txt-link-freetext" href="https://wiki.openjdk.org/display/csr/Main">https://wiki.openjdk.org/display/csr/Main</a><br>
</p>
<p>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.</p>
<p>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.</p>
<p>HTH,<br>
</p>
<p>-Joe<br>
CSR Group Lead<br>
</p>
<div class="moz-cite-prefix">On 5/4/2023 6:32 AM, Ethan McCue wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">stuart.marks@oracle.com</a>><br>
>> To: "Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">forax@univ-mlv.fr</a>><br>
>> Cc: "core-libs-dev" <<a href="mailto:core-libs-dev@openjdk.java.net" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
</body>
</html>