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

[Volker Simonis]

Hi Andrew,

thanks a lot for the detailed explanation!

Regards,
Volker


On Thu, Jul 7, 2016 at 4:54 PM, Andrew Dinn <adinn at redhat.com> wrote:
> 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