JDK-8144623 : javac module options need to match runtime options
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-12-03
  • Updated: 2024-10-10
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8140767 - Add -XaddReads to javac
Relates :  
JDK-8144624 - need test framework for verifying consistent behavior for javac and runtime
Relates :  
JDK-8167975 - align javac --add-* modules options with launcher
Relates :  
JDK-8181878 - javadoc should support/ignore --add-opens
Description
The model of the module graph, and the effect of module-related command line options needs to be consistent between javac and the runtime.

Currently, the major known discrepancy is the set of modules visible to the unnamed module (and the related need for -addmods).

We need to allow for some inherent differences between the two worlds, such as -modulesourcepath. (javac only)

General checklist
-XaddExports -XaddReads -addmods -limitmods  -listmods etc
Comments
Deferral Request Although I still think it is a good idea to (eventually) have a reasonably comprehensive set of tests to verify behavior between javac and the runtime for options related to the module graph, it does not rise to the level of a P2 must-have for 9.
14-04-2017
@Jon, did you mean this may a dup of JDK-8144624 ? Your present comment just above refers to the self same bug (this ticket).
15-03-2017
This was filed as a checklist item to verify equivalent behavior for the options to configure the module graph for java and javac. This is essentially the set of options --add-exports, --add-reads, --add-opens, --add-modules, --limit-modules. There is one specific difference that was current when the bug was filed, regarding the modules visible to the unnamed module. Ideally, we would have a set of tests that exercise different combinations of modules and module options to verify that the module graph seen by javac is equivalent to the module graph seen by java. In some sense, that could be described as a Minefield-style test for modules and module options, as compared to JDK-8144624, which is more like a Minefield-style test for module path options (testing good/bad representations of items on --module-path, --upgrade-module-path, etc) Also for consideration: testing the behavior of the options when multiple instances given: e.g. last-one-wins, merge, one-per-module, etc. Also, testing the behavior of invalid forms, especially invalid module names. If we have no outstanding reason to believe there is any significant reason to doubt the current behavior of javac, I suggest this should be downgraded to a P3 testbed Enhancement, and m4 removed.
15-02-2017
This may be a dup of JDK-8144623, although strictly speaking, that uses simple "test against the spec" tests, and not comparative testing.
15-02-2017
javac already accepts (and ignore) `--add-opens`. When used then it emits a warning: warning: [options] --add-opens has no effect at compile time
02-02-2017
@Jon, can you please let us have your take on this ? TIA
02-02-2017
Note from Jan Lahoda: I am not sure if we need to do anything. I was checking runtime options, and notable ones we don't support are: --list-modules: (lists observable modules) does not seem important for javac to me? --dry-run: seems like runtime only/meaningless for javac --add-opens: not really useful for javac as such (as opens are generally just by javac from source to class and otherwise basically ignored). We could consider adding this option mainly for consistency with runtime, so the very same set of options can be used for runtime and javac. Should be trivial to do (just do the same as is done for --add-exports). Beyond this, we are talking/working on -Xmodule conversion to --patch-module, but I'd rather keep that separate. If for nothing else then for process reasons. Also, in connection with this report, we were talking about a big test testing various combination, whether they work the same for runtime and javac. But I don't think we have had time so far to work on that (also related to JDK-8144624). Not sure if we are in a position to work on that? So, I'd almost be incline to either close this bug, or just adding --add-opens. +double check the runtime options if there's something more we should consider. And possibly filling a new bug to create more tests?
02-02-2017
Is there any more to do on this for M3? It seems like javac and java are aligned now although we will probably need a big test to probe corner cases to be truely confident.
13-03-2016
Added -addmods/-limitmods: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bfa233e22145
08-02-2016