Re: -Xlog and the module system

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

hg: jigsaw/jake/langtools: Correct values for ACC_TRANSITIVE/ACC_STATIC_PHASE

Changeset: 9982dbd88459 Author:alanb Date: 2017-02-02 16:26 + URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9982dbd88459 Correct values for ACC_TRANSITIVE/ACC_STATIC_PHASE ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java !

hg: jigsaw/jake/jdk: 4 new changesets

Changeset: 85331a665469 Author:alanb Date: 2017-02-02 16:28 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/85331a665469 Correct values for ACC_TRANSITIVE/ACC_STATIC_PHASE ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java Changeset: e26e4e89d174

Re: -Xlog and the module system

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. :(

Re: Automatic module names

Hi everyone, after thinking about this a little longer, I came to the conclusion that compile-time/launch-time aliasing might be the only way out of this (at least the only I could come up with) that keeps automatic modules alive and does not introduce a conceptual dependency on Maven. The

Re: -Xlog and the module system

-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

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources. Thanks Vladimir > On Feb 1, 2017, at 12:03 PM, Doug Simon wrote: > > >> On 1 Feb 2017, at 20:54, Sean Mullan

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On 1 Feb 2017, at 22:19, Vladimir Kozlov wrote: > > AOT tool jaotc does not run with SecurityManager. We assume it runs in secure > environment and it does not access any external resources. Great. Can I now consider this change reviewed and integrate it? -Doug

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On 1 Feb 2017, at 20:54, Sean Mullan wrote: > > Couple of comments: > > - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted > AllPermission and does not need an entry in default.policy. Thanks - I removed it. > - all internal APIs in the

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: http://cr.openjdk.java.net/~dnsimon/8145337/ -Doug > On 30 Jan 2017, at 22:53, Mandy Chung wrote: > >> >> On Jan 30,

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On 30 Jan 2017, at 21:55, Mandy Chung wrote: > > >> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >> >> I’ve extended the webrev with that change - please re-review: >> >> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >> > > +1

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

On 02/02/2017 02:12, Mandy Chung wrote: On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: