javac 8/9 inconsistency
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Feb 17 14:39:28 UTC 2015
On 17/02/15 12:59, Anna Kozlova wrote:
>
> Hi Maurizio,
>
> Test::factory is not exact, correct? Then when return type constraint
> is added, T has only one lower bound, so
> https://bugs.openjdk.java.net/browse/JDK-8055963 doesn’t apply as is.
> What can it be then?
>
This is an issue in javac - while javac does not consider Test::factory
pertinent to applicability in the applicability inference step, it goes
ahead and type-checks it ahead of the return type during invocation
method inference. This means that javac sees two bounds, Test<P> and
Test<String> and that's why 8055963
<https://bugs.openjdk.java.net/browse/JDK-8055963> applies again here.
In other words, while performing 18.5.2, javac is adding constraints
from an argument that is not pertinent to applicability in the very
first section of 18.5.2 which says:
"Let B_2 be the bound set produced by reduction in order to demonstrate
that |m| is applicable in §18.5.1
<https://docs.oracle.com/javase/specs/jls/se8/html/jls-18.html#jls-18.5.1>.
(While it was necessary in §18.5.1
<https://docs.oracle.com/javase/specs/jls/se8/html/jls-18.html#jls-18.5.1>
to demonstrate that the inference variables in B_2 could be resolved, in
order to establish applicability, the instantiations produced by this
resolution step are /not/ considered part of B_2 .) "
This is a bug - if the argument has been considered not pertinent to
applicability - it should simply be left alone here (and then considered
back after target-type is thrown into the mix). I will file a bug.
Please keep such issues coming - it's probably useful for both parties
to look at them.
Maurizio
>
> BTW I found more inconsistencies between 8/9 in our testdata, should I
> file them?
>
> Thanks,
>
> Anna
>
> *From:*Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
> *Sent:* Tuesday, February 17, 2015 12:05 PM
> *To:* Anna Kozlova; compiler-dev at openjdk.java.net
> *Subject:* Re: javac 8/9 inconsistency
>
> Hi Anna,
> I remember now - this is indeed:
>
> https://bugs.openjdk.java.net/browse/JDK-8055963
>
> That problem was ultimately caused by an ambiguity in the spec - which
> is why the fix was targeted for 9 and hasn't been backported. I would
> say it's normal for these kind of spec-related fixes to target the
> next release and not being backported.
>
> Maurizio
>
> On 16/02/15 19:27, Maurizio Cimadamore wrote:
>
> Hi Anna,
> it looks like the test should compile - I'm not sure as to which
> bugs are involved, I'll take a closer look and let you know.
>
> Thanks
> Maurizio
>
> On 16/02/15 17:45, Anna Kozlova wrote:
>
> Hi,
>
> The following code compiles with java 9 (b. 49) but doesn’t
> with 8 (1.8u40 b.23)
>
> class Test<K> {
>
> public static void foo(Test<String> test) {
>
> Test<String> e = create(Test::factory, test);
>
> }
>
> private static <T> T create(Supplier<T> callback, T defaultVal) {
>
> return null;
>
> }
>
> static <P> Test<P> factory() {
>
> return null;
>
> }
>
> }
>
> What is correct?
>
> BTW I’ve found
> https://bugs.openjdk.java.net/browse/JDK-8055963 which
> explains to me the situation withTest<String> e = create(() ->
> factory(), test); but the fix version is 9. Would it be
> backported to java 8?
>
> Thank you,
>
> Anna
>
>
> !DSPAM:35,54e3207822491380419189!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150217/92849bb5/attachment-0001.html>
More information about the compiler-dev
mailing list