RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers()

[Andrew Dinn]

On 07/07/16 14:59, Volker Simonis wrote:
> - I was a little bit surprised that I could reflectively access and
> execute java.lang.VersionProps.parseVersionNumbers() where both the
> class and the method are package private. Maybe this is related to
> Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a
> Jigsaw expert, I'd be graceful to anybody explaining me why this is
> still so easily possible with Jigsaw?

Reflective access to non-public classes/members of exported packages is
unchanged with Jigsaw -- it is subject to the security checks in place
in previous JDKs but not to a module access check.  So, in this case
java.lang is an exported package which means you can obtain a handle on
java.lang.VersionProps.parseVersionNumbers(), call setEnabled(true) and
then invoke it.

It is only when you try to reflectively access non-public
classes/members of packages that are not exported by their owning module
that the check comes into play. So, if your (non-module) code obtains a
reflective Member for jdk.internal.misc.Unsafe.theUnsafe and calls
setEnabled(true) you will find that the latter call will not succeed in
rendering it an accessible handle and an access via that handle will
fail. That is because java.base does not export package
jdk.internal.misc so the module check under setEnabled detects that the
caller is in a different module and refuses to make it accessible.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander