Re: An alternative to "restricted keywords" + helping automatic modules

- Mail original - > De: "Stephan Herrmann" > À: "Remi Forax" , jigsaw-dev@openjdk.java.net > Envoyé: Jeudi 18 Mai 2017 10:59:09 > Objet: Re: An alternative to "restricted keywords" + helping automatic modules > Remi, Stephan, > > I see your proposal as a minimal compromise, avoiding the

Re: Proposal: Allow illegal reflective access by default in JDK 9

There was a bug report which is closed, but that was, obviously, before the changed proposal. I think it would be subject to reconsider: https://bugs.openjdk.java.net/browse/JDK-8177916 Chris > On 19. May 2017, at 07:18, Tagir Valeev wrote:

Re: Proposal: Allow illegal reflective access by default in JDK 9

Regarding proposed "quiet" option: there's existing non-standard -XX:-PrintWarnings JVM option. I wonder whether it will work to suppress the illegal access warning as well. If yes, then no additional "quite" mode is necessary. With best regards, Tagir Valeev. On Fri, May 19, 2017 at 11:42 AM, Ch

Re: Proposal: Allow illegal reflective access by default in JDK 9

I don't like this default value, but I also know some people wanting it. Is it possible to provide the default value in a file inside the conf directory and also make it overwrite-able on the command line? Maybe RedHat Linux can make it "permit" out-of-box and other vendors can choose differen

Re: Proposal: Allow illegal reflective access by default in JDK 9

Hey, I also think the new styled parameter is great and I would appreciate a fully “quiet” mode for our customers. I don’t mandate it to be the default but I think to make it the default for (and only for) Java 9 sounds meaningful. The reason is simple: It is not just us (a few people, a few vend

Re: An alternative to "restricted keywords" + helping automatic modules

On May 18, 2017, at 1:59 AM, Stephan Herrmann wrote: > > In all posts I could not find a real reason against escaping, > aside from aesthetics. I don't see this as sufficient motivation > for a less-then-perfect solution. So, by disregarding esthetics... > > Clarity: > I'm still not completely

Re: Proposal: Allow illegal reflective access by default in JDK 9

Hi! I like the flag per se and think a "quiet" argument would be helpful. I also understand that there is pressure to improve the spec and that many observers will see this change as progress[1]. But I think making the lenient option the default is a bad decision, needlessly prolonging a proper

hg: jigsaw/jake/jaxws: 2 new changesets

Changeset: 139e7c786ee4 Author:lana Date: 2017-05-18 14:54 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/139e7c786ee4 Added tag jdk-9+170 for changeset e75d3abe579a ! .hgtags Changeset: eb19676ed32f Author:mchung Date: 2017-05-18 14:18 -0700 URL: http:

hg: jigsaw/jake/langtools: 7 new changesets

Changeset: ee84b7d44339 Author:jjg Date: 2017-05-09 17:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ee84b7d44339 8179479: Add new styles to enable HTML 5 tables Reviewed-by: bpatel ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources

hg: jigsaw/jake/jdk: 28 new changesets

Changeset: 3e92641a337d Author:psandoz Date: 2017-05-09 15:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3e92641a337d 8177153: LambdaMetafactory has default constructor Reviewed-by: psandoz Contributed-by: ron.press...@oracle.com ! src/java.base/share/classes/java/la

hg: jigsaw/jake/nashorn: 3 new changesets

Changeset: 550bfc15779f Author:sdama Date: 2017-05-12 12:12 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/550bfc15779f 8179891: JavaDoc for for..in is incorrect Summary: Fixed javadoc typo error Reviewed-by: sundar, hannesw, jlaskey Contributed-by: srinivas.d...@orac

hg: jigsaw/jake/jaxp: 5 new changesets

Changeset: e79b44a9d2bd Author:joehw Date: 2017-05-09 18:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e79b44a9d2bd 8179868: Java API Docs of javax.xml.transform.stax contains TODOs Reviewed-by: lancea, bpb ! src/java.xml/share/classes/javax/xml/transform/stax/packa

hg: jigsaw/jake/hotspot: 8 new changesets

Changeset: 830c73c1bd96 Author:ihse Date: 2017-05-11 09:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/830c73c1bd96 8174848: Remove gpl templates from hotspot/make Reviewed-by: erikj - make/templates/gpl-cp-header - make/templates/gpl-header Changeset: cab132bfda

hg: jigsaw/jake/corba: 4 new changesets

Changeset: a3e210a93f90 Author:jjg Date: 2017-05-10 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a3e210a93f90 8180041: Fix HTML 5 issues in java.corba Reviewed-by: alanb, lancea ! src/java.corba/share/classes/com/sun/corba/se/spi/monitoring/package.html ! src/j

hg: jigsaw/jake: 16 new changesets

Changeset: 7583288d0802 Author:ihse Date: 2017-05-10 09:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7583288d0802 8178278: Move Standard Algorithm Names document to specs directory Reviewed-by: erikj ! make/Javadoc.gmk Changeset: 4635fa3adac6 Author:erikj Date:

Re: Proposal: Allow illegal reflective access by default in JDK 9

The command-line argument and the default mode sound good. `--illegal-access=quiet` could be added for use by clients that cannot cope with additional warning messages. The second ingredient for broad compatibility with Java 8 would be an automatic --add-modules=ALL-SYSTEM. This could be implem

Re: -Xdiag:resolver

On 18/05/2017 18:35, Paul Deitel wrote: In earlier JDK 9-ea releases, there was the -Xdiag:resolver option to the java command so you could view the module resolution process at app startup. Has this been removed and replaced with --show-module-resolition option? The outputs don’t seem to be

-Xdiag:resolver

In earlier JDK 9-ea releases, there was the -Xdiag:resolver option to the java command so you could view the module resolution process at app startup. Has this been removed and replaced with --show-module-resolition option? The outputs don’t seem to be the same with this new option, so I am jus

Re: Proposal: Allow illegal reflective access by default in JDK 9

Sounds like a well thought compromise, Mark. Real world applications need this and it's a very welcome move. Regards, Michael On Thu, May 18, 2017 at 11:48 AM, wrote: > Over time, as we've gotten closer and closer to the JDK 9 GA date, more > and more developers have begun paying attention the

Re: Proposal: Allow illegal reflective access by default in JDK 9

2017-05-18 18:08 GMT+02:00 Uwe Schindler : > Hi Mark, > > To me this proposal is a Desaster. I'd not do this. Buggy software may use > the big kill switch. > > Sorry Red Hat guys: that's what you triggered with your "no". Bravo! I am > impressed! > > Sorry Gradle, the worst design in software abo

Re: Add-Reads and Add-Modules manifest attributes?

On 18/05/2017 16:47, Andrew Guibert wrote: : A concrete use case for an `Add-Reads` manifest attr is beside the point. Since we have the command line option, why can't we have the equivalent functionality as a manifest attribute (especially since it seems trivial to implement)? As long as u

Re: Proposal: Allow illegal reflective access by default in JDK 9

Hi Mark, To me this proposal is a Desaster. I'd not do this. Buggy software may use the big kill switch. Sorry Red Hat guys: that's what you triggered with your "no". Bravo! I am impressed! Sorry Gradle, the worst design in software about environment variables made the whole world again as un

Re: Evidence of incompatibility (was Some suggested patches and improvements)

No, the cleanup of the java 9 classes is bound to the compile step. Therefore, you don’t need to do a clean first. That would have been very aggravating. > On May 18, 2017, at 11:38 AM, Ralph Goers wrote: > > Yes, I had to do something similar. But this is fragile if you don’t always > do a cl

Re: Add-Reads and Add-Modules manifest attributes?

> From: Alan Bateman > To: Andrew Guibert > Cc: jigsaw-dev > Date: 05/18/2017 09:27 AM > Subject: Re: Add-Reads and Add-Modules manifest attributes? > > On 18/05/2017 15:14, Andrew Guibert wrote: > > Regarding Add-Reads: > You're reading it backwards I'm afraid =) This example is saying > "java

Re: Evidence of incompatibility (was Some suggested patches and improvements)

Yes, I had to do something similar. But this is fragile if you don’t always do a clean or explicitly include a clean step that runs to clean up those items even if you didn’t specify it. Ralph > On May 18, 2017, at 7:20 AM, Russell Gold wrote: > > Maven support and tool support in general for

Re: Proposal: Allow illegal reflective access by default in JDK 9

This looks like a very reasonable proposal, +1 2017-05-18 16:48 GMT+02:00 : > Over time, as we've gotten closer and closer to the JDK 9 GA date, more > and more developers have begun paying attention the actual changes in > this release. The strong encapsulation of JDK-internal APIs has, in > pa

Re: Attaching to a JVM image that does not include java.instrument

On 18/05/2017 15:20, Rafael Winterhalter wrote: Hei, I found that it is impossible to dynamically attach to a JVM that does not include the java.instrument module when built with jlink. This is a result of the instrumentation API and its infrastructure missing from the image. rafael@rafc:~/jdk

Re: Proposal: Allow illegal reflective access by default in JDK 9

On 18/05/17 15:48, mark.reinh...@oracle.com wrote: > - The proposed default mode enables the run-time system to issue a > warning message, possibly at some time long after startup, without > having been explicitly requested to do so. This may be a surprise > in production environments, sinc

Proposal: Allow illegal reflective access by default in JDK 9

Over time, as we've gotten closer and closer to the JDK 9 GA date, more and more developers have begun paying attention the actual changes in this release. The strong encapsulation of JDK-internal APIs has, in particular, triggered many worried expressions of concern that code that works on JDK 8

Re: Add-Reads and Add-Modules manifest attributes?

On 18/05/2017 15:14, Andrew Guibert wrote: : Regarding Add-Reads: You're reading it backwards I'm afraid =) This example is saying "java.base needs to read ALL-UNNAMED modules" But regardless of what example was given, it is a valid use case right? I assumed you had transposed them in your

Re: Evidence of incompatibility (was Some suggested patches and improvements)

Maven support and tool support in general for MR Jars is very poor at the moment - including the bundle plugin. I do have a working example you could look at that includes OSGi support. The key here is that I delete the java9 c

Attaching to a JVM image that does not include java.instrument

Hei, I found that it is impossible to dynamically attach to a JVM that does not include the java.instrument module when built with jlink. This is a result of the instrumentation API and its infrastructure missing from the image. rafael@rafc:~/jdk9-test/greetingsapp$ ./bin/java -javaagent:/home/ra

Re: Add-Reads and Add-Modules manifest attributes?

> From: Alan Bateman > To: Andrew Guibert , jigsaw-dev d...@openjdk.java.net> > Date: 05/18/2017 08:44 AM > Subject: Re: Add-Reads and Add-Modules manifest attributes? > > On 18/05/2017 14:40, Andrew Guibert wrote: > > > > > I was happy to see that a resolution was reached for #AddExportsInManif

Re: Add-Reads and Add-Modules manifest attributes?

Yes that would be great and I have also asked for that, see this thread: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012138.html Regards Reto > -Ursprüngliche Nachricht- > Von: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] Im Auftrag > von Andrew Guibert > Gese

Re: Add-Reads and Add-Modules manifest attributes?

On 18/05/2017 14:40, Andrew Guibert wrote: I was happy to see that a resolution was reached for #AddExportsInManifest, but why did this stop at Add-Exports and Add-Opens? In order to cover all use cases (for unnamed modules), we would need two more manifest attributes: # Equivalent to: --add-

Add-Reads and Add-Modules manifest attributes?

I was happy to see that a resolution was reached for #AddExportsInManifest, but why did this stop at Add-Exports and Add-Opens? In order to cover all use cases (for unnamed modules), we would need two more manifest attributes: # Equivalent to: --add-reads=java.base=ALL-UNNAMED --add-reads=java.

Re: Some suggested patches and improvements

On 18.05.2017 02:29, Gregg Wonderly wrote: I understand that you might feel this is an excessive rant. [snip] I will be looking at Swift and/or Go and just moving on. All the best on your future technological adventures, in any case, whether they are with Java, or something else! Please do

Re: An alternative to "restricted keywords" + helping automatic modules

Remi, I see your proposal as a minimal compromise, avoiding the worst of difficulties, but I think we can do better. Trade-off: In all posts I could not find a real reason against escaping, aside from aesthetics. I don't see this as sufficient motivation for a less-then-perfect solution. Clari

Re: How to load resources from base module

Hi Wolfgang, You are using instance method Class#getResource(String) which states in javadoc: /If this class is in a named Module then this method will attempt to find the resource *in the module*./ "this class" is the class represented by the Class object which is the receiver of the

Re: How to load resources from base module

On 18/05/2017 08:16, wzberger wrote: : public class ClassA{ public ClassA() { //success System.out.println(getClass().getResource("/com/b/resources/test.txt")); The test creates an instance of ClassB (extends ClassA) and so getClass() returns ClassB here, not ClassA. So when constructing

Re: How to load resources from base module

Here is a simple example which demonstrates the issue - still something missing? // MODULE A module com.a { exports com.a; } package com.a; public class ClassA{ public ClassA() { //success System.out.println(getClass().getResource("/com/b/resources/test.txt")); //fail

Re: Some suggested patches and improvements

On 18/05/2017 01:29, Gregg Wonderly wrote: I understand that you might feel this is an excessive rant. But, practically I know of Java applications around the world which all use things like Spring. Spring seems to be making great progress, here's a recent write-up from Juergen Hoeller: