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

Meanwhile we seem to have (at least) 4 proposals on the table. Here's my biased summary: (A) JLS up until 2017-05-18 PRO: + we have a specification + spec can be interpreted as allowing all module words to be mentionable in all relevant directives. CON: - the specification is interpreted

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

On 19.05.2017 15:38, Stephen Felts wrote: [...] Here are a few public ones. org.python.core.PyJavaClass - Jython com.sun.xml.bind.v2.runtime.reflect.opt.Injector – standalone jaxb com.sun.xml.ws.model.Injector – standalone jaxws net.sf.cglib.core.ReflectUtils$ - cglib Summarizing the use

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

Hi, without judging any of the proposals in this thread, I just want to clarify some things: - jlink is no standard tool (i.e. it is neither specified nor mandated by the new Java SE 9 specification). This equally applies to the new jimage/jmod file formats. - in contrast, the minimal, compact

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

Right. I'm asking for a new API so code can be written to avoid the warning. -Original Message- From: Alan Bateman Sent: Friday, May 19, 2017 10:11 AM To: Stephen Felts; jigsaw-dev@openjdk.java.net Subject: Re: Proposal: Allow illegal reflective access by default in JDK 9 On 19/05/2017

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

- Mail original - > De: "Stephan Herrmann" > À: fo...@univ-mlv.fr, jigsaw-dev@openjdk.java.net > Envoyé: Vendredi 19 Mai 2017 17:26:02 > Objet: Re: An alternative to "restricted keywords" + helping automatic modules > Inline > > On 19.05.2017 15:53,

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

Hi, Just a thought... What about keeping the "opens pkg" and "open module m" as is - there is a legitimate argument in keeping all accesses (static and reflective) in sync. But it does not mean that "--illegal-access=permit" must be equivalent to --add-opens

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

On Fri, May 19, 2017 at 1:05 PM, Alan Bateman wrote: > On 19/05/2017 10:48, Volker Simonis wrote: > >> : >> >> From my understanding, at run-time, "open" implicates "exports" (i.e. >> if a module M1 opens a package P for some other module M2 it also, >> implicitly

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

Hey, Just a clarification question, does that mean no agent like dynatrace, appdynamics or others would work anymore with a normal jlinked image, when `java.instrument` is specifically added as a dependency? In this case I would agree with Rafael and Michael. It will come as a surprise to a

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

I haven't seen any reaction to this sub-topic: - If an automatic module would have a name containing a Java keyword, is it OK to simply refuse handling this artifact as an automatic module? Stephan On 18.05.2017 10:59, Stephan Herrmann wrote: Remi, I see your proposal as a minimal

Re: AW: Java 9 EA 169 Webstart NoClassDefFoundError: javax/xml/ws/Service

Hi all, According to JEP 261 the java.se.ee specific modules are being excluded for the sake of app servers since we already typically override them. As a developer of a Java EE app server, while this gesture is appreciated, I think it does more harm than good to the wider Java community because

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

Inline On 19.05.2017 15:53, fo...@univ-mlv.fr wrote: *De: *"Stephan Herrmann" *À: *"John Rose" ,

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

On 19 May 2017 at 11:22, Alan Bateman wrote: > One thing that jlink > could do is emit a warning that the resulting run-time image doesn't have > the management and instrumentation features, might that be the right > balance. As a users of those kind of agents, and as an

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

On 05/19/2017 04:05 PM, Alan Bateman wrote: On 19/05/2017 14:54, Peter Levart wrote: : Opening the whole JDK (--illegal-access=permit by default) means that all internal "public" APIs are made accessible if by chance someone can grab an instance of target object and/or an instance of

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

On 19/05/2017 14:48, Stephen Felts wrote: By the way, there is no available API so that one can write If an object is not accessible and setAccessible on the object will succeed call setAccessible That means that the code needs to call setAccessible and handle the exception,

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

There are two separate issues, here: 1) Access to internal APIs. Yes, we have been warned of these for two decades; it shouldn’t actually be a shock that they have been banned. It shouldn’t, but in some cases, people didn’t really believe that they would go away. Still, it seems reasonable to

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

On 19/05/2017 14:54, Peter Levart wrote: : Opening the whole JDK (--illegal-access=permit by default) means that all internal "public" APIs are made accessible if by chance someone can grab an instance of target object and/or an instance of Method/Field object. Imagine a JDK developer that

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

Hi Alan, On 05/19/2017 02:28 PM, Alan Bateman wrote: On 19/05/2017 13:02, Peter Levart wrote: Ok, I can understand that such interpretation of "opens" is necessary for JDK 8 compatibility story. If something is "open" then it behaves exactly like in JDK 8 or before (apart from compilation)

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

> De: "Stephan Herrmann" > À: "John Rose" , jigsaw-dev@openjdk.java.net > Cc: "Rémi Forax" > Envoyé: Vendredi 19 Mai 2017 12:37:07 > Objet: Re: Re: An alternative to "restricted keywords" + helping automatic > modules > A

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

By the way, there is no available API so that one can write   If an object is not accessible and setAccessible on the object will succeed   call setAccessible   That means that the code needs to call setAccessible and handle the exception, which triggers a warning.      

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

Hi, I don't want to pick on Andrew in particular but his paragraph is a great summary of the sad state of this discussion: > I don't think that's practical Interesting, waiting for a real, practical, technical reason not to do that. > many worried expressions Err, what? So something is

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

Here's something to think about with respect to noise by whatever choice is made for the default for --illegal-access.   I've run a lot of code using the current --permit-illegal-access.   One of the problems with this option is that there can be errors detected for code that is working

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

Most project teams I come accross as a consultant broadly ignore warnings. I would not expect that most people pay attention to a warning that an image is not including JVMTI, especially if the implications are unclear to the person in charge of running the build. Excluding JVMTI by default - ie

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

On 19/05/2017 12:28, Andrew Dinn wrote: : I don't think history is the most important guide here (whatever the history might be). If agent support was not optional in the past that is no reason to not make it optional now. My reason for bringing up the history is to make it clear that the

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

On 19/05/17 11:11, Peter Levart wrote: > On 05/19/2017 01:17 AM, Nicolai Parlog wrote: >> With illegal access being permitted by default much fewer developers >> will be aware of the problem and much less pressure will be put on >> library and framework maintainers as well as on project management

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

On 19/05/2017 13:02, Peter Levart wrote: Ok, I can understand that such interpretation of "opens" is necessary for JDK 8 compatibility story. If something is "open" then it behaves exactly like in JDK 8 or before (apart from compilation) regardless of packages being exported or not. But

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

Hi Rafael, On 19/05/17 13:08, Rafael Winterhalter wrote: > do not forget that we are talking about 130 kilobyte here which come at > the costs of removing a feature that often serves as a last resort and > where its need is rarely anticipated. Given the little overhead of > including this module,

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

On 05/19/2017 05:58 AM, Peter Levart wrote: Hi Nikolai, On 05/19/2017 12:41 PM, Nicolai Parlog wrote: Hi! I'm too lazy to try right now It's easy. Take this example: public class Test { public static void main(String[] args) throws Exception { Object theUnsafe =

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

Hi Andrew, do not forget that we are talking about 130 kilobyte here which come at the costs of removing a feature that often serves as a last resort and where its need is rarely anticipated. Given the little overhead of including this module, I do not find it reasonable to disable a feature that

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

Hi Alan, On 05/19/2017 01:05 PM, Alan Bateman wrote: On 19/05/2017 10:48, Volker Simonis wrote: : From my understanding, at run-time, "open" implicates "exports" (i.e. if a module M1 opens a package P for some other module M2 it also, implicitly exports P to M2). The "big kill switch" in

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

On 05/19/2017 01:14 PM, Alan Bateman wrote: On 19/05/2017 11:58, Peter Levart wrote: : ...the example works (does not throw exception), but when run with: --add-opens java.base/jdk.internal.misc=ALL-UNNAMED ...the example still works OOOPS - this is a bug!!! This is definitely a

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

On 19/05/17 11:24, Alan Bateman wrote: > On 19/05/2017 10:20, Rafael Winterhalter wrote: > >> : >> >> It is the exact purpose of a Java agent to allow the enhancement of a >> Java application that is independent of a particular Java process. >> Therefore, it should not be a decission bound to the

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

On 19/05/17 09:22, Alan Bateman wrote: > As I said, the goal has always been to allow someone create a run-time > image that only contains java.base. I'm not sure that subsuming > java.instrument into java.base is right. Introducing options to ask > jlink to exclude modules creates the potential

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

On 05/19/2017 12:58 PM, Peter Levart wrote: It's easy. Take this example: public class Test { public static void main(String[] args) throws Exception { Object theUnsafe = Class.forName("jdk.internal.misc.Unsafe") .getMethod("getUnsafe")

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

On 19/05/2017 11:58, Peter Levart wrote: : ...the example works (does not throw exception), but when run with: --add-opens java.base/jdk.internal.misc=ALL-UNNAMED ...the example still works OOOPS - this is a bug!!! This is definitely a bug. No, the behavior is correct as

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

On 19/05/2017 10:48, Volker Simonis wrote: : From my understanding, at run-time, "open" implicates "exports" (i.e. if a module M1 opens a package P for some other module M2 it also, implicitly exports P to M2). The "big kill switch" in both, its old and in the newly proposed form, usually

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

Hi Nikolai, On 05/19/2017 12:41 PM, Nicolai Parlog wrote: Hi! I'm too lazy to try right now It's easy. Take this example: public class Test { public static void main(String[] args) throws Exception { Object theUnsafe = Class.forName("jdk.internal.misc.Unsafe")

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

Hi Alan, I understand your current time constraint, I still want to point out that this is a heavily used functionality and it not being available would cause problems in basically all production environments I am aware of where the lack of this API is not uncovered before running the application

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

Hi! I'm too lazy to try right now but I'm pretty sure I repeatedly observed the behavior Volker describes: A module depends on an internal type and is compiled successfully thanks to --add-exports. At run time it would fail without flags and would work with --add-exports but it also works with

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

A quick question to keep the ball rolling: Do we agree on the following assessment of the status quo? The definition of "restricted keywords" implies (without explicitly saying so), that classification of a word as keyword vs. identifier can only be made *after* parsing has accepted the

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

On 19/05/2017 10:20, Rafael Winterhalter wrote: : It is the exact purpose of a Java agent to allow the enhancement of a Java application that is independent of a particular Java process. Therefore, it should not be a decission bound to the creation or bundeling of the Java application if

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

Hi Volker, On 05/19/2017 11:48 AM, Volker Simonis wrote: From my understanding, at run-time, "open" implicates "exports" (i.e. if a module M1 opens a package P for some other module M2 it also, implicitly exports P to M2). The "big kill switch" in both, its old and in the newly proposed form,

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

On 05/19/2017 01:17 AM, Nicolai Parlog wrote: With illegal access being permitted by default much fewer developers will be aware of the problem and much less pressure will be put on library and framework maintainers as well as on project management to invest into paying back this particular form

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

Hi Mark, thanks for this proposal. I think it is pragmatic and well balanced. While I personally agree with the advocates of a clean solution I also understand the the needs of big (and slow) companies (including the one I'm working for:) After all, the new default isn't that bad in my opinion

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

While the jlink feature might only be used by power users, there is no guarantee that the users of these images are power users at the same degree or is even understand the implications. For example, some team might use a JVM-based server from a third-party vendor which is distributed as a jlink

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

I don't support the ^ element or escaping like that either. However, would adding a "module" keyword help? module com.foo.lib { requires module com.foo.bar; } thus: module com.foo.lib { requires static module blah; requires transitive module transitive; } ie. the module name is always

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

- Mail original - > De: "Alan Bateman" > À: "Rafael Winterhalter" > Cc: "jigsaw-dev" > Envoyé: Vendredi 19 Mai 2017 10:22:04 > Objet: Re: Attaching to a JVM image that does not include java.instrument > On

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

On 19/05/2017 08:08, Rafael Winterhalter wrote: Hi Alan, I just retested with the most recent Java 9 snapshot and this is what I get: rafael@rafc:~/jdk9-test/greetingsapp$ ./bin/java -javaagent:/home/rafael/.m2/repository/sample-agent/sample-agent/1.0-SNAPSHOT/sample-agent-1.0-SNAPSHOT.jar

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

Hi Alan, I just retested with the most recent Java 9 snapshot and this is what I get: rafael@rafc:~/jdk9-test/greetingsapp$ ./bin/java -javaagent:/home/rafael/.m2/repository/sample-agent/sample-agent/1.0-SNAPSHOT/sample-agent-1.0-SNAPSHOT.jar -m com.greetings/com.greetings.Main Error occurred

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