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 t
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
! src/jdk.jdeps/share
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
A
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. :( Can
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 idea:
-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
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 wrote:
>>
>> Couple of comments:
>>
>> - jdk
> 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
>> On Feb 1, 2017, at 12:03
> 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 jdk.vm.compiler module will
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, 2017, at 1:36 PM, Doug Sim
> 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
Thanks. Is that a “Reviewed”?
I think I should
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:
http://cr.openjdk.java.net/~dnsimon/8145337/
Looks good
On 01/02/2017 21:49, 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.
I agree it should be transparent to developers using the JDK as to
whether the implementation i
13 matches
Mail list logo
