Previously, in JDK 8 and before, javac would use the runtime
bootclasspath if there was explicit setting for the compilation
bootclasspath.
Now, in 9, there is no sense of a bootclasspath, since it has been
superseded by modules and the module graph. But even so, it is
reasonable to ask the question, should javac (be able to) start
initializing its compilation module graph from the runtime module
graph? --inherit-runtime-environment was an attempt to explore that
possibility. In particular, if you use options like --add-reads,
--add-exports, etc when initializing the JVM used to run javac, should
jave pick up those options, as well as honoring explicit settings for
those options on the javac command line.
The alternative is that javac should have its own well-defined rules for
defining the compilation module graph (fully independent of the module
graph for the javac runtime). If you want the compilation module graph
to have some similarities to the underlying runtime module graph, that
you would need to explicitly provide a similar set of options to javac.
I think the growing consensus is that the latter case is the better
practice.
-- Jon
On 01/20/2017 05:29 PM, Nicolai Parlog wrote:
Hi!
Pretty much what the subject line says... I don't quite get what exactly
--inherit-runtime-environment does and what it is good for. Is this
something that non-JDK developers are likely to use?
so long ... Nicolai
