Libor, Pavel,
Thanks for the report!
I've filled:
https://bugs.openjdk.java.net/browse/JDK-8177311
And sent a request for review:
http://mail.openjdk.java.net/pipermail/compiler-dev/2017-March/010873.html
Thanks!
Jan
On 20.3.2017 23:44, Pavel Bucek wrote:
Hi Jon,
thanks. The credit goes to
Hi Jon,
thanks. The credit goes to Libor, but he's not subscribed on these
mailing lists and I helped with the evaluation, so I know the issue we
faced.
What should we do now? Is reporting the issue here enough or should we
file an issue somewhere?
Regards,
Pavel
On 20/03/2017 23:31, Jon
Pavel,
It looks like you have tripped over an issue in javac's handling of an
automatic module, and its ability to read classes from the unnamed
module (i.e. classpath).
-- Jon
On 03/20/2017 03:19 PM, Pavel Bucek wrote:
Hi Alex,
The usecase is about compiling tests in maven projects.
I m
Hi Alex,
The usecase is about compiling tests in maven projects.
I mirrored the content of the zip to github:
https://github.com/pavelbucek/reproducer (project contains useful README)
The TestCase.java [1] contains simple testcase, compilable when
everything is on the classpath.
When modul
Pavel,
I did not mean to suggest the error message was the only problem. I
merely wanted to note a subtle detail in the message that might
otherwise have been easy to overlook, and which might be a clue to the
underlying problem.
-- Jon
On 03/20/2017 02:44 PM, Pavel Bucek wrote:
// moving
I can't figure out which classes are on which path, and why you think
ALL-UNNAMED should export FROM the classpath when its purpose is to
export TO the classpath.
Please clarify your configuration in a few short sentences, rather than
asking us to open a zip file on an unknown host.
Alex
On
// moving from jdk9-dev, as suggested.
Hi Jon,
Thanks for clarification of the error message.
The main point here is that adding "import ... " fixes the issue, which
doesn't feel correct.
When dependencies are put on the classpath, the import statement is not
required.
Regards,
Pavel
On
