JDK-8163588 : Confusing error while compiling via JSR199 API using the same file manager
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2016-08-10
  • Updated: 2022-07-28
  • Resolved: 2016-09-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8143270 - Path options for langtools tools should not side-effect the filemanager
Relates :  
JDK-8150040 - Confusing error while compiling with not existing module source path
Description
Following compiler error is produced under following circumstances:

./test/p3/C3.java:1: error: unnamed package is not allowed in named modules
package p3;
^

The circumstances are:
1. Compilation is performed via JSR199 API.
2. StandardJavaFileManager instance is retrieved and used in compiling in module mode, that is when -modulepath and -modulesourcepath options are specified.
3. The same StandardJavaFileManager instance which was used in step 2 is used for compiling in NON module mode, that is when -classpath option is specified and -modulepath and -modulesourcepath options are not.

The minimized test case is attached in order to reproduce the bug please:
1. Unzip attached archive to some dir, say A, on Unix/Linux machine.
2. Modify A/Test31/test.sh by setting JDK_HOME variable to your JDK installation dir.
3. Run A/Test31/test.sh.

These steps produce following output on JDK 9 build 130:

With the same file manager:
Compilation in module mode succeeded
./test/p3/C3.java:1: error: unnamed package is not allowed in named modules
package p3;
^
Compilation in NON-module mode failed

With fresh file manager:
Compilation in NON-module mode succeeded
Comments
1. We should impl something better for setLocationFromPaths for MODULE_SOURCE_PATH -- that's a related issue but not this issue. ==> I have raised JDK-8166329 for this purpose. 2. We should consider working on transient option settings for a file manager, so that path set in options do not have long term side effects on the file manager. Jan is working on something related (transient file manager for --release), and in a review for that work, I suggested we look at the general problem of all path options. ==> I think this is subsumed by the referred work by Jan + possibly JDK-8143270 3. These confusing error message issues should be closed as dups of issue JDK-8143270 ==> Will do. Thanks.
20-09-2016
I think there are some actionable items here, by someone: 1. We should impl something better for setLocationFromPaths for MODULE_SOURCE_PATH -- that's a related issue but not this issue. 2. We should consider working on transient option settings for a file manager, so that path set in options do not have long term side effects on the file manager. Jan is working on something related (transient file manager for --release), and in a review for that work, I suggested we look at the general problem of all path options. 3. These confusing error message issues should be closed as dups of issue JDK-8143270
20-09-2016
Gentlemen, I am unsure there is something I can act on here. I think perhaps we should wait for JDK-8150040 to be closed first.
20-09-2016
[~sadayapalam], it's a design issue and minor bug regarding setLocationFromPaths for MODULE_SOURCE_PATH The design issue is that setting it via the option is more powerful/expressive than setting it through the setLocationFromPaths API. That being said, we could resolve that issue as follows: -- support "null" as a "reset" value -- define a reasonable spec for setLocationFromPaths in terms of the equivalent handleOption API. Sure, it'll be a subset of what you can do with handleOption, but at least we can document what it does support, and point people at handleOption for the full featured version.
19-09-2016
[~larbouzo], yes, that should all be OK.
19-09-2016
The JCK doesn't rely on thread safety of standard file manager. The JCK tests run sequentially in OS processes i.e. two JCK tests can nor run in parallel using threads in the same OS process. Mutliple OS processes are used to start separate VM instances for parallel execution but this should be ok - right?
19-09-2016
The default standard file manager is not thread safe and should not be used by multiple independent executing threads. It might be a challenge to figure out where we could specify that, but the upcoming new docs for the jdk.compiler would be a reasonable place. I would *strongly* suggest that you use one file manager per thread-to-execute-tests, not one file manager for use by all test threads.
19-09-2016
> Do you think there is a third bug apart from JDK-8150040 and JDK-8143270 that this ticket represents ? > I don't think so and at the moment don't have anything to proceed upon. Let me know if I have misunderstood something. Please note that according to JDK-8150040 the confusing error message is produced when module source path doesn't exist. While here the module source path passed to compiler exists when the confusing error message is produced (please see minimized testcase). From this one can conclude that a third bug does exist. However this issue and JDK-8150040 might be caused by the same root cause, but I'm not familiar with javac internals to be sure that this is right.
15-09-2016
@Leonid & @Georgiy, Put another way: Do you think there is a third bug apart from JDK-8150040 and JDK-8143270 that this ticket represents ? I don't think so and at the moment don't have anything to proceed upon. Let me know if I have misunderstood something.
12-09-2016
@Leonid, I am still having trouble seeing what the issue is outside of the filemanager options being sticky that Jon has called out. Is there any non-determinism or intermittent behavior that is not explained by the file manager options being sticky (JDK-8143270) ?
12-09-2016
@Jon, You wrote: "before closing this issue as a dup of the Enhancement to wrap the file manager for the duration of the javac compilation. " I presume you mean https://bugs.openjdk.java.net/browse/JDK-8143270
12-09-2016
It looks doubtful that lang/LMBD/lmbd001/lmbd00101m0/lmbd00101m0.html is anyway connected to this issue.
12-09-2016
@Jon, your suggestion for resetting the file manager state using setLocations(location, null) results in Exception in thread "main" java.lang.UnsupportedOperationException at com.sun.tools.javac.file.Locations$ModuleSourcePathLocationHandler.setPaths(jdk.compiler@9-internal/Locations.java:1303) at com.sun.tools.javac.file.Locations.setLocation(jdk.compiler@9-internal/Locations.java:1575) at com.sun.tools.javac.file.JavacFileManager.setLocation(jdk.compiler@9-internal/JavacFileManager.java:923) At the source code the change looks like: fileManager.setLocation(StandardLocation.MODULE_SOURCE_PATH, null); fileManager.setLocation(StandardLocation.MODULE_PATH, null); Let me know if this is not what you intended. Is this supposed to be supported ?
12-09-2016
> It would be worth understanding why the failures are intermittent The failures are intermittent from the point of view JCK execution. I.e. depending on the order in which tests are run (compiled) the failure occurs or not. Assumption is that test are run in singleJVM or groupJVM mode when shared file manager is used. MultiJVM mode should be ok then.
07-09-2016
I don't think there is any intermittent failure here. As a matter of fact Georgiy's report does not mention the words "intermittent" or "deterministic" or "non-deterministic" at all. The difference in behavior observed and reported between using a fresh file manager instance and reusing a file manager instance that was used in an earlier invocation of the compiler is fully explained by Jon's comment about file manager options given to javac are sticky in the file manager. So second Jon's comment that " the behavior you are seeing is expected, even if it is unwelcome. " I think this should be closed as not an issue - Georgiy, do you agree ?
07-09-2016
The current behavior is that file manager options given to javac are "sticky" in the file manager, meaning that the behavior you are seeing is expected, even if it is unwelcome. There are ideas to change the behavior, so that a transient wrapper file manager is created for the duration of the compilation, to hold the javac-specified options, but that is a big enhancement that is too big to do for now. The current workaround for tests that need to reset the file manager is to reset file manager state using setLocation(location, null). -- The only item I find suspect in the Comment above above two test failures is that the failures are intermittent. I would have expected javac and file manager behavior to be deterministic. It would be worth understanding why the failures are intermittent, before closing this issue as a dup of the Enhancement to wrap the file manager for the duration of the javac compilation.
31-08-2016
The compilation error is similar to the error presented in JDK-8150040
10-08-2016