Hi!
What the *$%& did I try then? I did that of course and thought I did not
see any messages in cases where the configuration was faulty. Under the
assumption that Xdiag's log level was too high, I went looking for a way
to set it to trace - without success.
But whatever I did that lead me to
On 2/02/2017 8:59 PM, Nicolai Parlog wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Alan.
The trace messages emitted by -Xdiag:resolver are printed as the
resolver runs.
I'm sorry for being such a noob but my Google Foo failed at telling me
how to turn trace on for -Xdiag. :(
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Alan.
> The trace messages emitted by -Xdiag:resolver are printed as the
> resolver runs.
I'm sorry for being such a noob but my Google Foo failed at telling me
how to turn trace on for -Xdiag. :( Can you help me out?
so long ... Nicolai
On 2/02/2017 7:49 AM, Nicolai Parlog wrote:
Hi Alan,
`-Xdiag:resolver` is awesome! :) I think these messages are great
candidates for info-level messages with the "modules" tag via unified
logging.
You are dealing with two completely separate pieces of the platform.
-Xdiag is a launcher
FWIW, I think javac also deserves some amount of similar work.
-- Jon
On 02/01/2017 01:49 PM, Nicolai Parlog wrote:
Hi Alan,
`-Xdiag:resolver` is awesome! :) I think these messages are great
candidates for info-level messages with the "modules" tag via unified
logging.
Something else I
Hi Alan,
`-Xdiag:resolver` is awesome! :) I think these messages are great
candidates for info-level messages with the "modules" tag via unified
logging.
Something else I noticed, neither Xlog nor Xdiag help with problematic
configurations - both only start logging after everything checked out,
On 01/02/2017 14:27, Nicolai Parlog wrote:
Hi!
When playing with `-Xlog:modules*` (down to trace) I hoped for a
little more output that I could use to analyze a configuration.
-Xlog:modules is VM oriented and mostly traces the primitives used to
construct the module graph in the VM.
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
