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

On 05/19/2017 11:48 AM, Volker Simonis wrote: > 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

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

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,

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

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

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

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

that is May 30 ( https://bugs.eclipse.org/516911 ). Regards, Markus "jigsaw-dev" <jigsaw-dev-boun...@openjdk.java.net> wrote on 2017-05-18 16:48:40: > From: mark.reinh...@oracle.com > To: jigsaw-dev@openjdk.java.net > Date: 2017-05-18 16:49 > Subject: Proposal: All

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

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

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

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

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,

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