On 03/04/2017 22:07, Mandy Chung wrote:
On Apr 3, 2017, at 1:35 PM, Simon Nash <si...@cjnash.com> wrote:
On 03/04/2017 21:15, mark.reinh...@oracle.com wrote:
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and c
On 03/04/2017 21:15, mark.reinh...@oracle.com wrote:
2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
...
This shows the old and new value of OS_NAME/OS_ARCH properties
in the `release` file:
JDK 8
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
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
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
Alan Bateman wrote:
On 29/10/2016 23:09, Simon Nash wrote:
My application uses sun.misc.SignalHandler which is now in the
jdk.unsupported
module. This class is available when running with the full JRE but
not when
running with the compact3 JRE.
The sun.misc.* classes are available
My application uses sun.misc.SignalHandler which is now in the jdk.unsupported
module. This class is available when running with the full JRE but not when
running with the compact3 JRE.
The sun.misc.* classes are available in the compact1/2/3 profiles in JDK 8 and
I don't see any reason why the
Paul Benedict wrote:
For those who are still supporters of preventing non-exported types from
being reflected, I think a compromise can still be found, but it's not in
this proposal. Here are two other alternatives I hope the EG will consider:
1) Introduce a new permission type to allow
Alan Bateman wrote:
On 09/07/2016 09:57, Simon Nash wrote:
Is it really a good idea to encourage packages that currently use
reflection
to access non-exported private fields (an official part of the Java
API) to
change to using internal APIs? This seems like a step backwards to me.
I
Alan Bateman wrote:
On 09/07/2016 08:46, Simon Nash wrote:
I think this a very important point. If someone wanted to reimplement
Java serialization (java.io.ObjectOutputStream, etc.) as an external
library
(com.foo.ObjectOutputStream, etc.), the new restrictions on reflective
access in JDK
Jason Greene wrote:
There is also a disparity here that the JDK itself doesn’t require you to
export packages (e.g. I don’t need it for Java serialization). Now I realize
that there is an effort underway to de-privilege modules, but I suspect that a
portion of the JDK will continue to enjoy
mark.reinh...@oracle.com wrote:
2015/8/4 11:34 -0700, si...@cjnash.com:
Thanks for this. In the list of broad categories, one is missing:
x Those which are required to enable application code to work around
bugs in the JDK such as leaked objects.
That could be an awfully broad
Mark,
Thanks for this. In the list of broad categories, one is missing:
x Those which are required to enable application code to work around
bugs in the JDK such as leaked objects.
When do you expect to be able to publish a detailed proposal for how the
last resort mechanism will work?
mark.reinh...@oracle.com wrote:
2015/7/28 4:21 -0700, Simon Nash si...@cjnash.com:
...
With JDK 9 and Project Jigsaw, I understand that it will no longer be
possible for my application to directly reference internal sun.* classes.
Will it still be possible to use ClassLoader.loadClass to load
mark.reinh...@oracle.com wrote:
2015/7/28 8:12 -0700, Simon Nash si...@cjnash.com:
mark.reinh...@oracle.com wrote:
2015/7/28 4:21 -0700, Simon Nash si...@cjnash.com:
...
With JDK 9 and Project Jigsaw, I understand that it will no longer be
possible for my application to directly reference
be
possible for my application to directly reference internal sun.* classes.
Will it still be possible to use ClassLoader.loadClass to load these sun.*
classes and use reflection to invoke their methods?
Simon Nash
16 matches
Mail list logo
