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 all-modules/all-packages=ALL-UNNAMED. It could mean a
slightly different thing - just enough to keep the compatibility with
JDK 8. There's no point in making jdk.internal.* packages open for
example - they are mostly new APIs and not relevant to backwards
compatibility.
More precisely, let "--illegal-access=permit" allow
.setAccessible(true) be called by unnamed module(s) on otherwise
inaccessible (private, package-private, protected) members/classes of
exported packages only.
The reasoning is as follows:
- selected JDK modules can explicitly open selected packages if they
feel they should keep runtime compatibility with applications but
prevent compilation with such APIs (like jdk.unsupported module does for
example). In JDK 10 they can close those packages again.
- I don't know what percentage of JDK-internal APIs used by applications
through reflection is in exported packages and what percent in
concealed. It would be interesting to know such statistics first.
- User modules can explicitly open selected packages or entire modules
if they feel so
- User automatic modules already export all packages, but to allow
access to their private members via reflection, they should perhaps be
equivalent to open modules with all packages exported in addition.
What do you think?
Regards, Peter
On 05/19/2017 04:27 PM, Peter Levart wrote:
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
Method/Field object. Imagine a JDK developer that thought that by
putting a public type into a concealed package was equivalent to
making the type module-private. This is a big surprise from the
security perspective and jdk.internal.misc.Unsafe.getUnsafe() might
not be a lone example.
True although it's no different to JDK 8 and older behavior where all
public members of all public types in all packages were accessible to
code on the class path.
Except that in the meanwhile a lot of internal code was written for
JDK 9 that assumed the level of privacy provided by concealed
packages. This level is about to be changed by the proposal in the
last minute...
Furthermore, setAccessible could be use to hack everywhere. The
proposal is really just giving libraries and tools more time to sort
out their issues.
-Alan
Regards, Peter
