Alan, but that is extra configuration in the module, as I have pointed out.
The whole idea I have to opt someone into fuller reflection is taking
control too far. I'm also advocating this is not the responsibility of the
module to control reflection. What I have proposed using the Security
Manager
On 09/07/2016 21:28, Paul Benedict wrote:
The argument I'm making is not just someone really wants to do this,
but that many people won't settle without it. Reflection has always
been the tool to dynamically achieve what the Java language can't
always express statically. IoC is built on 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
The argument I'm making is not just someone really wants to do this, but
that many people won't settle without it. Reflection has always been the
tool to dynamically achieve what the Java language can't always express
statically. IoC is built on the notion that language boundaries can and
should
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
Changeset: c73e8464b2e1
Author:shade
Date: 2016-06-06 22:34 +0300
URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c73e8464b2e1
8075030: JvmtiEnv::GetObjectSize reports incorrect java.lang.Class instance size
Reviewed-by: coleenp, sspitsyn, sla
!
Changeset: 44327147adc2
Author:sherman
Date: 2016-06-27 13:57 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/44327147adc2
8160312: ArrayIndexOutOfBoundsException when comparing strings case insensitive
Reviewed-by: rriggs
!
Changeset: 06d706c70634
Author:amurillo
Date: 2016-07-07 18:21 +
URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/06d706c70634
Added tag jdk-9+126 for changeset 264a44128cd6
! .hgtags
Changeset: 5419b0c050e0
Author:alanb
Date: 2016-07-09 10:11 +0100
URL:
Changeset: 31261e7238af
Author:erikj
Date: 2016-06-28 14:20 +0200
URL: http://hg.openjdk.java.net/jigsaw/jake/rev/31261e7238af
8160285: Bootcycle builds are broken on jdk9/hs for windows i586
Reviewed-by: dholmes
! common/autoconf/boot-jdk.m4
!
Changeset: bf76248bbe51
Author:hannesw
Date: 2016-06-28 15:17 +0200
URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bf76248bbe51
8160435: Source.baseURL is slow for URLs with unregistered protocol
Reviewed-by: sundar
!
Changeset: 8fab452b6f47
Author:amurillo
Date: 2016-07-07 18:21 +
URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/8fab452b6f47
Added tag jdk-9+126 for changeset c7f5ba08fcd4
! .hgtags
Changeset: 80cd54e85502
Author:alanb
Date: 2016-07-09 10:11 +0100
URL:
Changeset: 15722f71281f
Author:amlu
Date: 2016-07-05 09:15 +0800
URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/15722f71281f
8156598: Use more informative format for problem list
Reviewed-by: lancea
! test/ProblemList.txt
Changeset: 4f80ad5cc0f3
Author:amurillo
Date:
On 09.07.2016 09:50, Alan Bateman wrote:
[...]
As regards "enjoy special power" then the only module that is known to
the VM and module system is "java.base". The java.base module, as you
probably know, is the core of the system. The java.base modules has the
VM, java.lang.**, the implementation
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 didn't suggest that. 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
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 9 would prevent this.
On 08/07/2016 22:42, Paul Benedict wrote:
:
2) Allow layers to control if non-exported types can be reflected. Perhaps
the JDK sets its own layers to "false", but Containers and what they deploy
can be separately configured, each.
A container or anything else doing dynamic configuration
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
The practical matter is simply that all of this name visibility business is
just entirely the wrong thing to be managing “modules” around. Instead,
modules should be things that are more easily managed with tools that
facilitate things that container systems will want to do. Modularity as a
19 matches
Mail list logo
