Possible regression involving inferred generic types

Jeremy Manson jeremymanson at google.com
Thu Oct 17 11:52:59 PDT 2013


Thanks, Alex.  Similar non-JLS changes that break backwards compatibility
have been documented before, so I'd probably argue that it is worth
documenting this.  I'll follow the thread on lambda-dev (another email
group I have to join... sigh...).

Jeremy


On Thu, Oct 17, 2013 at 11:14 AM, Alex Buckley <alex.buckley at oracle.com>wrote:

> Hi Jeremy,
>
> The JDK8 release notes will include a page on compatibility akin to that
> for JDK7: http://www.oracle.com/**technetwork/java/javase/**
> compatibility-417013.html<http://www.oracle.com/technetwork/java/javase/compatibility-417013.html>.
> The page will list incompatible changes in the Java language (epsilon) and
> incompatible changes in javac (epsilon * 2).
>
> The Java Documentation Team generates these lists by looking for JBS
> issues with the label "release-note=yes". Individual engineers are required
> to be mindful about changes which affect compatibility, and add the label
> where necessary. On lambda-dev you should be able to find out which JBS
> issue owned the javac change which tightened return type erasure. Note
> there is no language change (i.e. JLS change) here, nor is there any
> inference occurring in Liam's examples (there are generic types, but no
> generic methods).
>
> Alex
>
>
> On 10/17/2013 9:00 AM, Jeremy Manson wrote:
>
>> Hi Alex,
>>
>> Liam is trying to get javac8 up and running with our source base.  He
>> seems to be encountering this particular issue a fair bit, which makes
>> me think that this should be listed in the Official Big List of Java 8
>> Incompatibilities.  Who is the right contact for that?  Joe Darcy?
>>
>> Jeremy
>>
>>
>> On Wed, Oct 16, 2013 at 5:52 PM, cushon <cushon at google.com
>> <mailto:cushon at google.com>> wrote:
>>
>>     Thanks for the explanation. I posted on lambda-dev here:
>>     http://mail.openjdk.java.net/**pipermail/lambda-dev/2013-**
>> October/011299.html<http://mail.openjdk.java.net/pipermail/lambda-dev/2013-October/011299.html>
>>
>>
>>     On Wed, Oct 16, 2013 at 4:52 PM, Alex Buckley
>>     <alex.buckley at oracle.com <mailto:alex.buckley at oracle.**com<alex.buckley at oracle.com>>>
>> wrote:
>>
>>         The common theme is that you're passing values of raw types, so
>>         an unchecked conversion is necessary for a method to be
>>         applicable, so the return type of the chosen method is erased,
>>         so Object appears in places where a more specific type is
>>         necessary. The relevant JLS rules have not changed substantively
>>         in SE 8, so to a first approximation javac is behaving
>>         correctly. I would encourage you to post on lambda-dev as
>>         generics in javac are dominated by Lambda at this time.
>>
>>         Alex
>>
>>
>>         On 10/16/2013 4:08 PM, Liam Miller-Cushon wrote:
>>
>>             Hi all,
>>
>>             The following programs do not compile with the jdk8 javac.
>>             (I tried b111 and
>>             954dd199d6ff). All of the programs compile with the jdk7
>> javac.
>>
>>             ------------------------------**
>> __----------------------------**--__-------------------
>>
>>             import java.util.List;
>>
>>             class ReproOne {
>>
>>                 static class Baz<T> {
>>                   public static List<Baz<Object>>
>>             getElements(Baz<Object> transcoder) {
>>                     return null;
>>                   }
>>                 }
>>
>>                 private static void bar(Baz arg) {
>>                   for (Baz element : Baz.getElements(arg)) {}
>>                 }
>>             }
>>             ------------------------------**
>> __----------------------------**--__-------------------
>>
>>             abstract class ReproTwo<T> {
>>
>>                 class Bar<E> {}
>>
>>                 T get(Bar<? extends T> arg1, Bar arg2) {
>>                   return circularGet(arg2, arg2);
>>                 }
>>
>>                 abstract T circularGet(final Bar<? extends T> arg1,
>>             final Bar<?> arg2);
>>             }
>>             ------------------------------**
>> __----------------------------**--__-------------------
>>
>>             abstract class ReproThree<T, V> {
>>
>>                 class Binding<E> {}
>>                 class ProviderBinding<E> extends Binding<E> {}
>>
>>                 abstract V visitOther(Binding<? extends T> binding);
>>
>>                 public V visitTwo(ProviderBinding<? extends T>
>>             providerBinding) {
>>                   return visitOther((Binding) providerBinding);
>>                 }
>>             }
>>             ------------------------------**
>> __----------------------------**--__-------------------
>>
>>
>>             javac output:
>>
>>             ReproOne.java:12: error: incompatible types: Object cannot
>>             be converted
>>             to Baz
>>                   for (Baz element : Baz.getElements(arg)) {}
>>                                                     ^
>>
>>             ReproTwo.java:6: error: incompatible types: Object cannot be
>>             converted to T
>>                   return circularGet(arg2, arg2);
>>                                     ^
>>                 where T is a type-variable:
>>                   T extends Object declared in class ReproTwo
>>
>>             ReproThree.java:10: error: incompatible types: Object cannot
>> be
>>             converted to V
>>                   return visitOther((Binding) providerBinding);
>>                                    ^
>>                 where V is a type-variable:
>>                   V extends Object declared in class ReproThree
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20131017/14e076e5/attachment-0001.html 


More information about the compiler-dev mailing list