Jon points out that javac should also be updated. javac currently opens the
JMOD file with JarFileSystem. Jon and I discussed this and we agree to keep
the current workaround for now and add the validation to detect if the JMOD
file is valid.
Updated webrev:
http://cr.openjdk.java.net/~mch
Changeset: 584b91a4b43d
Author:mchung
Date: 2016-09-30 13:20 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/584b91a4b43d
Minor clean up to the implementation of stack trace output
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/
On Fri, Sep 30, 2016 at 8:16 AM, Rafael Winterhalter
wrote:
> This would be a way to go but I am afraid that currently, the most likely
> outcome would be to make all modules weak and keep them weak forever.
> Personally, I believe that weak modules might become the default choice for
> most deve
On 30/09/2016 16:59, Rafael Winterhalter wrote:
Maybe it depends on the language setup? Mine is German, i.e. all help
is printed in German. Its definitely the right java command.
That's it, there hasn't been a translation update since this transition
so the non-English messages haven't be
Maybe it depends on the language setup? Mine is German, i.e. all help is
printed in German. Its definitely the right java command.
Am 30.09.2016 5:55 nachm. schrieb "Alan Bateman" :
> On 30/09/2016 16:16, Rafael Winterhalter wrote:
>
>
>
>> :
>>>
>>> PS: I noticed that when running java (without
On 30/09/2016 16:16, Rafael Winterhalter wrote:
:
PS: I noticed that when running java (without commands), it
still lists the
non-GNU-style options that are no longer supported.
Can you paste in `java -version` and give an example?
rafael@raftop:~$ ~/jdk
> With the newest EA build, out of 7000 unit tests, only
>> 42 tests still fail and those are all because of using non-exported API of
>> the JCL.
>>
> Just curious, what is "JCL" here?
>
I mean "Java class library", the classes that are part of the JVM.
This is of course not great as plain jars
On 30/09/16 15:11, Sanne Grinovero wrote:
> Hi all,
> I think what Peter raises is a very interesting quandary.
>
> Without going in the syntax details of this proposal, the point is
> that implementations of "javax.persistence" (and similar APIs) need to
> advertise themselves as eligible to gett
Sanne, weak modules already allow this, but the weak module mechanism is
not adequate, as has been discussed internally.
The question of whether restricting reflection is useful or not is a
separate discussion. Our position is that it is a solution for a
problem that can be solved in other wa
On 30/09/16 14:42, Alan Bateman wrote:
>> I currently experiment with a Java agent to force Java 9 to adopt this
>> desired behavior by manipulating the boot layer's module graph or by
>> stubbing AccessibleObject::checkCanSetAccessible.
> That sounds like a gross hack, something that could break a
By my analysis, the only possible and useful solution for
#ConcealedPackageConflicts, other than rewriting how class loaders work,
is to map non-automatic application (i.e. non-JDK) modules in the
default layer each to their own class loader. This also potentially
solves (or provides to means
Hi all,
I think what Peter raises is a very interesting quandary.
Without going in the syntax details of this proposal, the point is
that implementations of "javax.persistence" (and similar APIs) need to
advertise themselves as eligible to getting certain additional
privileges - such as reflective
Thanks for the write-up, a few questions/comments inlined.
On 30/09/2016 13:35, Rafael Winterhalter wrote:
With the newest EA build, out of 7000 unit tests, only
42 tests still fail and those are all because of using non-exported API of
the JCL.
Just curious, what is "JCL" here?
This is of
I have tested the latest EA builds, both on my open-source projects and in
several production applications, one of them quite large with thousands of
development hours invested. I wanted to share my experiences.
After making files with the .class extension visible, my agent/code
generation library
14 matches
Mail list logo
