[External] Re: BUG: local type inference -> symbol not found
Sietse Au
sietse.au at booking.com
Tue Jun 9 14:17:11 UTC 2020
That's indeed strange.
javac Test.java
An exception has occurred in the compiler (11.0.6). Please file a bug
against the Java compiler via the Java bug reporting page (
http://bugreport.java.com) after checking the Bug Database (
http://bugs.java.com) for duplicates. Include your program and the
following diagnostic in your report. Thank you.
I'm on archlinux, I can see that on 11.0.7 the problem is gone:
https://www.archlinux.org/packages/extra/x86_64/jdk11-openjdk/
However
https://git.archlinux.org/svntogit/packages.git/diff/trunk?h=packages/java11-openjdk&id=2465fb7c7852484ea8c6649e30e0f2ff82130a73
Seems like the source was:
https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/jdk-11.0.6+10.tar.gz
Building this from scratch yields the same results:
x86_64-normal-server-release/jdk/bin % ./javac ~/Test.java
An exception has occurred in the compiler (11.0.6). Please file a bug
against the Java compiler via the Java bug reporting page (
http://bugreport.java.com) after checking the Bug Database (
http://bugs.java.com) for duplicates. Include your program and the
following diagnostic in your report. Thank you.
On Tue, Jun 9, 2020 at 3:13 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:
> Hi - I've managed to reproduce; it seems a duplicate of this bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8210483
> <https://urldefense.com/v3/__https://bugs.openjdk.java.net/browse/JDK-8210483__;!!FzMMvhmfRQ!-F2ybplrudy-nt-7XvSsJ43cpoWa3QDhWf7EmwW-9vWLUzMy4N6yFDyNHvbb39bk$>
>
> That said, JIRA says this bug has been fixed in 11.04, so I'm not sure why
> you are seeing it.
>
> On my ubuntu, which comes with 11.06 the bug cannot be reproduced, and I
> have to use an older JDK 11 build to do that.
>
> To reproduce I've created this single file:
>
> import java.util.function.*;
>
> class Handle {
> public <T> T attach(Class<T> extensionType) { return null; }
> }
>
>
> class BugReproduction {
>
>
> public void doesNotCompile() {
> final Anything anything = null;
>
> anything.executeOuter(() -> {
> anything.executeInner((handle) -> {
> final var inferredAnything = handle.attach(Anything.class);
> consume(inferredAnything::create);
> return null;
> });
> return null;
> });
> }
>
> public void consume(Consumer<Long> noop) {
> noop.accept(1L);
> }
>
> }
>
> interface Anything {
>
> Long create(Long object);
>
> default <T> T executeOuter(final Supplier<T> callback) {
> return callback.get();
> }
>
> default Long executeInner(Function<Handle, Long> onSuccess) {
> return onSuccess.apply(null);
> }
> }
>
>
> Maurizio
> On 09/06/2020 13:49, Sietse Au wrote:
>
> I've created a small project where the problem can be reproduced
> consistently:
> https://github.com/stau-booking/jdk11-reproduce-type-infer-bug
> <https://urldefense.com/v3/__https://github.com/stau-booking/jdk11-reproduce-type-infer-bug__;!!FzMMvhmfRQ!-F2ybplrudy-nt-7XvSsJ43cpoWa3QDhWf7EmwW-9vWLUzMy4N6yFDyNHs3cewaF$>
>
> In this case the inferred type in the project is still `Anything`.
>
> On Mon, Jun 8, 2020 at 10:55 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> It would be interesting to know what is the inferred type for `someDao` -
>> here's a dirty trick that you can use to let the compiler cough that up:
>>
>> final var someDao = ...
>> String s = (String)someDao;
>>
>> This should hopefully cause a type mismatch and the compiler should tell
>> you which type it tried to convert to String.
>>
>> I'm suspecting that this type might be a non-denotable type (e.g.
>> anonymous class type, or intersection type) - which might be something that
>> might trip javac up when used as a method reference receivers?
>>
>> Maurizio
>> On 08/06/2020 20:34, Sietse Au wrote:
>>
>>
>> Hi,
>>
>> I've run into a compilation error on OpenJDK 11.06 (see attachment) where
>> there is some interaction between local type inference and method
>> reference.
>>
>> Haven't been able to create a clean project to reproduce the problem.
>>
>> Inside a larger code-base it is reproducible:
>>
>> final var someDao = ...
>> someRequest.map(item -> SomeBuilder.builder()
>> ...
>> .build()
>> ).forEach(someDao::create);
>>
>> the combination of the local type inference `final var` and the
>> `someDao::create` method reference lead to the stacktrace in the attachment.
>>
>> When we rewrite the above to not use type inference and declare the type
>> explicitly:
>> final SomeDao someDao = ...
>>
>> OR
>>
>> rewrite the forEach not using the method reference:
>> forEach(x -> someDao.create(x))
>>
>> the code compiles.
>>
>> As the stack trace itself was kind of unhelpful, hooking up to a debugger
>> found that when the code hits `someDao::create` a SymbolNotFound error is
>> thrown.
>>
>>
>> Best regards,
>> --
>> Sietse Au
>>
>>
>
> --
> Sietse Au
>
>
--
Sietse Au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200609/b14eb396/attachment-0001.htm>
More information about the compiler-dev
mailing list