Re: Better tools for adjusting to strong encapsulation

On 24/03/2017 13:02, Alan Bateman wrote: On 24/03/2017 12:01, Peter Levart wrote: : Just a reminder that System.err field is "writable" and therefore System.setErr(PrintStream) can be used to redirect output to execute arbitrary code... That's right, it needs to captured at startup or

Re: Better tools for adjusting to strong encapsulation

On 24/03/2017 12:01, Peter Levart wrote: : Just a reminder that System.err field is "writable" and therefore System.setErr(PrintStream) can be used to redirect output to execute arbitrary code... That's right, it needs to captured at startup or sent directly to stderr. -Alan

Re: Better tools for adjusting to strong encapsulation

On 03/23/2017 08:04 PM, Alan Bateman wrote: On 23/03/2017 18:44, Alan Snyder wrote: If I understand JEP 264 correctly, it should be possible to direct platform generated error messages to locations other than the standard error stream (System.err). Is that correct? If so, would it not

Re: Better tools for adjusting to strong encapsulation

On 23/03/2017 19:04, Alan Bateman wrote: On 23/03/2017 18:44, Alan Snyder wrote: If I understand JEP 264 correctly, it should be possible to direct platform generated error messages to locations other than the standard error stream (System.err). Is that correct? If so, would it not make

Re: Better tools for adjusting to strong encapsulation

OK, so the configuration idea does not work. How about the idea of using the console log instead of System.err for these messages, on systems that have such a thing? > On Mar 23, 2017, at 12:04 PM, Alan Bateman wrote: > > On 23/03/2017 18:44, Alan Snyder wrote: > >>

Re: Better tools for adjusting to strong encapsulation

On 23/03/2017 18:44, Alan Snyder wrote: If I understand JEP 264 correctly, it should be possible to direct platform generated error messages to locations other than the standard error stream (System.err). Is that correct? If so, would it not make sense for the default to be the (platform

Re: Better tools for adjusting to strong encapsulation

...@openjdk.java.net wrote: -- Message: 4 Date: Wed, 22 Mar 2017 20:30:00 -0700 From: mark.reinh...@oracle.com To: jigsaw-dev@openjdk.java.net Subject: Re: Better tools for adjusting to strong encapsulation Message-ID: <20170322203000.424722...@eggemoggin.niobe.net> Conten

Re: Better tools for adjusting to strong encapsulation

On 23 March 2017 at 03:30, wrote: > It appears that issuing warning messages for illegal-access operations > enabled by the precise `--add-opens` and `--add-exports` options is a > bit too aggressive, at least for JDK 9. Perhaps we can enable that in > JDK 10 after

Re: Better tools for adjusting to strong encapsulation

I think the distinction between the precise options and the big kill switch is important and I welcome this change. It will solve the immediate problem for my application. I still have reservations about the hard-wired use of System.err for warning messages for the reasons given by Roel

Re: Better tools for adjusting to strong encapsulation

I will interpret your answer as that there is no additional per method invocation cost due to this. bye Jochen On 23.03.2017 09:12, Alan Bateman wrote: On 22/03/2017 21:07, Jochen Theodorou wrote: the warnings you are seeing are from the groovy runtime trying to determine - in a pre JDK9

Re: Better tools for adjusting to strong encapsulation

On 23.03.2017 01:16, Claes Redestad wrote: [...] the warnings you are seeing are from the groovy runtime trying to determine - in a pre JDK9 compatible way - if it is allowed to call the methods on Objecz. This happens in a first step by setAccessible on all methods using the array version,

Re: Better tools for adjusting to strong encapsulation

On 22/03/2017 21:07, Jochen Theodorou wrote: the warnings you are seeing are from the groovy runtime trying to determine - in a pre JDK9 compatible way - if it is allowed to call the methods on Objecz. This happens in a first step by setAccessible on all methods using the array version, and

Re: Better tools for adjusting to strong encapsulation

Thanks to everyone for all the feedback on this topic. It appears that issuing warning messages for illegal-access operations enabled by the precise `--add-opens` and `--add-exports` options is a bit too aggressive, at least for JDK 9. Perhaps we can enable that in JDK 10 after there's been more

Re: Better tools for adjusting to strong encapsulation

On 2017-03-22 22:07, Jochen Theodorou wrote: On 22.03.2017 12:23, Alan Bateman wrote: [...] I assume your interest is Groovy where there are indeed some warnings that look like Groovy is to blame. For example, I get the following with a trivial script containing`println "Hello world!"` : $

Re: Better tools for adjusting to strong encapsulation

On 22.03.2017 12:23, Alan Bateman wrote: [...] I assume your interest is Groovy where there are indeed some warnings that look like Groovy is to blame. For example, I get the following with a trivial script containing`println "Hello world!"` : $ groovy hello.groovy NOTE: Picked up the following

Re: Better tools for adjusting to strong encapsulation

Mark, How do we (Oracle JDeveloper) turn these illegal reflective-access operation warnings off. We don't want or need these warnings when running JDeveloper except during specific developer sessions. BTW, the big kill switch doesn't seem useful, it just hides everything that needs work.

Re: Better tools for adjusting to strong encapsulation

uot;mark reinhold" <mark.reinh...@oracle.com> > À: jigsaw-dev@openjdk.java.net > Envoyé: Mardi 21 Mars 2017 15:48:13 > Objet: Better tools for adjusting to strong encapsulation > By now we've heard quite a bit of feedback, both publicly and privately, > from developers who've mig

Re: Better tools for adjusting to strong encapsulation

n" <alan.bate...@oracle.com> > Cc: jigsaw-dev@openjdk.java.net > Envoyé: Mercredi 22 Mars 2017 12:57:56 > Objet: Re: Better tools for adjusting to strong encapsulation > On 22/03/17 11:42, Alan Bateman wrote: >> On your comment about neglect then you might want to look at

Re: Better tools for adjusting to strong encapsulation

On 22 March 2017 at 12:28, Roel Spilker wrote: > This is especially a problem because the users of my program cannot do > anything themselves to get rid of it. In my opinion, they should not be > bothered by messages intended for the developer. > > Since this is a tool to

Re: Better tools for adjusting to strong encapsulation

On 21.03.2017 15:48, mark.reinh...@oracle.com wrote: [...] When an illegal reflective access operation succeeds due to the use of the `--permit-illegal-access` option, or the use of an `--add-opens` or `--add-exports` option, then a warning message of the following form is written to the error

Re: Better tools for adjusting to strong encapsulation

Better yet, why aren’t the java.util.logging apis used for stuff like this? It seems strange that there is not a nice compact formatter, yet, standard in the JDK. The logging APIs seem highly neglected given that even the varargs access has not been fixed so that you can use varargs without

Re: Better tools for adjusting to strong encapsulation

Lest folks think they can now sit back and relax until JDK 10, I'd like to point out that there are some cases where what has happened in 9 is that a very small number of old deprecated and non-standard APIs have actually been removed, and some small number of APIs adjusted in behaviour. Whilst

Better tools for adjusting to strong encapsulation

By now we've heard quite a bit of feedback, both publicly and privately, from developers who've migrated existing applications to JDK 9. This can be a non-trivial task, involving the iterative construction of a set of command-line workarounds, since some popular libraries and frameworks use the