Hi!
When playing with `-Xlog:modules*` (down to trace) I hoped for a
little more output that I could use to analyze a configuration.
Things that are missing and would be helpful:
* Which JARs end up in the unnamed module? (Although I'm not sure
whether that is even known at the time.)
* Which JARs become automatic modules?
* For each module that is created, why does that happen? Is it
required by another module? Is module creation triggered by a
qualified export? (The latter was the only explanation I had for
modules like jdk.scripting.nashorn being initialized at all).
* When a module is missing, following what path from one of the root
modules was it required?
* What happens with services? (They do not seem to be mentioned at all.)
* What exception lead to the aborted launch? (Or is it policy not to
log error messages?)
* When --limit-modules is used, the log is just magically smaller as
if deriving the universe of observable modules did not happen at all.
In principle, it would be great to have enough information to
trouble-shoot problematic configurations from looking at the log. As
it stands a lot of external information (launch command, directories,
error messages, even JAR content) has to be included for remote
debugging to be possible.
That being said, I generally find the error messages themselves pretty
informative. Good job! :)
so long ... Nicolai
--
PGP Key:
http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
Web:
http://codefx.org
a blog about software development
https://www.sitepoint.com/java
high-quality Java/JVM content
http://do-foss.de
Free and Open Source Software for the City of Dortmund
Twitter:
https://twitter.com/nipafx
