Type inference bug with method references in OpenJDK 16+ discovered

[Guoxiong Li]

Hi Michael,

> the bug depends on the order in which the java files are compiled.
> It doesn't matter whether adopt-jdk16.0.1, oracle-opendjdk 16.0.1 or
openjdk 17 ea+27 is used.
> If StringLiteral.java and then Variable.java is compiled, the bug occurs.
> Otherwise it doesn't. Right?

Given you reproduce my idea locally, I believe the order I mentioned causes
this bug.

> I mean forcing the order in which the source code files are compiled
would be a workaround, of course.
> However, I have not found any way in maven yet how you can force one
specific order in which the java files are compiled.

Before solving this bug, it is good to use
`interpreter.<StringVariable>query(MyFact::new);` to replace
`interpreter.query(MyFact::new);` as a workaround. No matter whether
directly using the compiler or using maven,
depending on the order of the input source files is not a good way to
eliminate the error.
As you mentioned, we can't force the maven to compile the source files by
using our specific order.
It depends on the maven implementation and the implementation may be
different from the maven version.
So we got different results when using maven which is mentioned in the
previous email.

> How big/small is the chance for me to find the bug and submit a fix for
you? What do you think?
> I mean I must run the javac tool in debug mode over my example project
and find out
> where and what goes wrong when the compile order is changed. Or am I
completely wrong?
> The javac code is here, isn't it?
>
https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/classes/com/sun/tools/javac
<https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/classes/com/sun/tools/javac/parser>
> I would give it a try at the next weekend if you think I could fix it.

The code of the compiler is mainly in the module `jdk.compiler`
https://github.com/openjdk/jdk/tree/master/src/jdk.compiler.
And it requires the modules `java.compiler` and `java.base` which are
mentioned in its `module.info`.
The main code is in the packages  `com.sun.tools.javac` and its
sub-packages. So your link is right.
Here are some documents for you to understand the compiler:
http://openjdk.java.net/groups/compiler/

I remembered my first patch to the compiler:
https://github.com/openjdk/jdk16/pull/34/files
It actually only has one line code change:
```
-            names.ANNOTATION_TYPE, names.LOCAL_VARIABLE, names.PARAMETER};
+            names.ANNOTATION_TYPE, names.LOCAL_VARIABLE, names.PARAMETER,
names.MODULE };
```
I revisited the compiler knowledge at a long time and spent several days on
the bug.
I wanted to give it up during that time but finally, I found the cause and
fixed it.
So I can imagine that it may be hard for you to start. Just do it if *you
are interested on it* no matter how hard it is.
Maybe you can't solve the bug at last, but you can learn more(compiler
knowledge, code skill, debug skill or others) from it.
In my opinion, the most important point is the interest instead of the
difficulty of the problem when *we have enough time*.

> I discovered the exception comes from
src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
in line 295.

The exception is thrown at runtime which you can see at the exception stack.
But actually, the class file generated by the compiler may be wrong so that
the runtime exception is thrown.
So it seems that the cause is in the compiler instead of runtime.


PS:
I notice that your email was not sent to compiler-dev at openjdk.java.net.
Other folks can't read your email.
Please remember to sent or cc to the compiler-dev at openjdk.java.net in the
future.

Best Regards,
-- Guoxiong

On Thu, Jun 24, 2021 at 9:19 AM Michael Mirwaldt <michael.mirwaldt at gmx.de>
wrote:

> Hi Guoxiong,
> I can confirm your observation:
> the bug depends on the order in which the java files are compiled.
> It doesn't matter whether adopt-jdk16.0.1, oracle-opendjdk 16.0.1 or
> openjdk 17 ea+27 is used.
> If StringLiteral.java and then Variable.java is compiled, the bug occurs.
> Otherwise it doesn't. Right?
>
> I mean forcing the order in which the source code files are compiled would
> be a workaround, of course.
> However, I have not found any way in maven yet how you can force one
> specific order in which the java files are compiled.
>
> How big/small is the chance for me to find the bug and submit a fix for
> you? What do you think?
> I mean I must run the javac tool in debug mode over my example project and
> find out
> where and what goes wrong when the compile order is changed. Or am I
> completely wrong?
> The javac code is here, isn't it?
>
> https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/classes/com/sun/tools/javac
> <https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/classes/com/sun/tools/javac/parser>
> I would give it a try at the next weekend if you think I could fix it.
>
> I discovered the exception comes from
> src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> in line 295.
>
> All the best,
> Michael Mirwaldt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210624/157f19ef/attachment-0001.htm>