Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[nakamura]

Dear Mr. Peter Levart:


http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.04/

+1.  Ship it!  Thanks for compressing it!

Thanks for reviewing. Pushed.


Thank you very much. 6378384 was submitted by me.
Is your fix is included? By using JDK 9-ea+140-jigsaw, the subclass can 
access its superclass's protected static fields and methods by reflection.



Hope it's not too bad that I managed to enter non-ascii characters into
commit message. I was copy-pasting from Jira issue title and didn't
notice the difference between ' and ’ . Probably an artifact of
migrating issues from SUN's old bug-tracking system. This issue really
had a long beard...


Sorry. I maybe copied the text from MS-Word.

Yours sincerely,
Manabu Nakamura

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Peter Levart]

Hi Mandy,


On 10/18/2016 07:36 PM, Mandy Chung wrote:

On Oct 18, 2016, at 3:55 AM, Peter Levart  wrote:

They do. What do you say about this variant (compressionLevel=9):

 
http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.04/

+1.  Ship it!  Thanks for compressing it!

Mandy



Thanks for reviewing. Pushed.

Hope it's not too bad that I managed to enter non-ascii characters into 
commit message. I was copy-pasting from Jira issue title and didn't 
notice the difference between ' and ’ . Probably an artifact of 
migrating issues from SUN's old bug-tracking system. This issue really 
had a long beard...


Regards, Peter

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Mandy Chung]

> On Oct 18, 2016, at 3:55 AM, Peter Levart  wrote:
> 
> They do. What do you say about this variant (compressionLevel=9):
> 
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.04/

+1.  Ship it!  Thanks for compressing it!  

Mandy

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Peter Levart]

Hi Mandy,


On 10/18/2016 01:51 AM, Mandy Chung wrote:

>Besides, constant names would not be any prettier than class name string 
literals. At least now it is obvious to anyone what package a particular class 
belongs to:
>
> "a.Package" vs. A_PACKAGE ?
>

PACKAGE_CLASS_IN_PKG_A
PUBLIC_SUPERCLASS_IN_PKG_A
PUBLIC_SUBCLASS_IN_PKG_A

Do the suggested variable names help?


They do. What do you say about this variant (compressionLevel=9):

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.04/

Regards, Peter

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Mandy Chung]

> On Oct 17, 2016, at 4:30 PM, Peter Levart  wrote:
> 
> ...you would review the members that are allowed and then you should ask 
> yourself: "Which are the ones that are denied? All the rest. What are they?", 
> or: "Could there be any other that should be allowed? Which one?”

I’m happy with your revised patch that group field/method together and adding 
allowAll/denyAll that makes it easier to understand while it does not lose any 
information.

> It's much easier if they are explicitly listed:
> 
>  ok &= new Test()
>  
> .current("b.PublicSub").member("a.PublicSuper").target("b.PublicSub")
>  .allowed(PROTECTED_INSTANCE_F_M, PUBLIC_INSTANCE_F_M, 
> PROTECTED_STATIC_F_M,
>   PUBLIC_STATIC_F_M, PUBLIC_C)
>  .denied (PRIVATE_INSTANCE_F_M, PACKAGE_INSTANCE_F_M, 
> PRIVATE_STATIC_F_M,
>   PACKAGE_STATIC_F_M, PRIVATE_C, PACKAGE_C,
>   PROTECTED_C)
>  .perform();
> 
> 
> And besides, you don't really have to review them all.

I do review them as this test is one important part of this patch :) 

> The fact that running the test on unpatched JDK 9 finds just two differences:
> 
> - access to protected static method from subclass in another package
> - access to protected static field from subclass in another package
> 
> ...is a reassurance that the patch does exactly what it should. No less, 
> no more.
> 

Indeed.

> 
> Then I would have to have a mapping from class name -> constant name for the 
> generator.

This is one time thing.

> Besides, constant names would not be any prettier than class name string 
> literals. At least now it is obvious to anyone what package a particular 
> class belongs to:
> 
> "a.Package" vs. A_PACKAGE ?
> 

PACKAGE_CLASS_IN_PKG_A
PUBLIC_SUPERCLASS_IN_PKG_A
PUBLIC_SUBCLASS_IN_PKG_A


> Note that I can't use a.Package.class literal(s) here (thought I would like 
> to) as they don't compile if they refer to a package-private class from 
> another package.
> 
> I would like to keep those things unchanged, If you don't mind.

Do the suggested variable names help?

Mandy

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Peter Levart]

Hi Mandy,


On 10/17/2016 10:52 PM, Mandy Chung wrote:

On Oct 16, 2016, at 11:18 AM, Peter Levart  wrote:


I think specifying both is more verbose on one hand, but OTOH it allows one to 
visually inspect all the cases and think of each and every one in isolation to 
see if it is valid in a particular caller/member/target arrangement. The test 
infrastructure verifies that the test case covers all the MemberFactory(s) so 
one must only verify each individual allowed / denied MemberFactory.

I understand the intention there.  But when each test case enumerates 20 
constants, it’s getting harder to review what’s going on and catch any issue.


It now enumerates only 12 constants and I think it's quite the opposite. 
Take the following for example. If only the allowed members were listed:


 ok &= new Test()
.current("b.PublicSub").member("a.PublicSuper").target("b.PublicSub")
 .allowed(PROTECTED_INSTANCE_F_M, PUBLIC_INSTANCE_F_M, 
PROTECTED_STATIC_F_M,

  PUBLIC_STATIC_F_M, PUBLIC_C)
 .perform();

...you would review the members that are allowed and then you should ask 
yourself: "Which are the ones that are denied? All the rest. What are 
they?", or: "Could there be any other that should be allowed? Which one?"


It's much easier if they are explicitly listed:

 ok &= new Test()
.current("b.PublicSub").member("a.PublicSuper").target("b.PublicSub")
 .allowed(PROTECTED_INSTANCE_F_M, PUBLIC_INSTANCE_F_M, 
PROTECTED_STATIC_F_M,

  PUBLIC_STATIC_F_M, PUBLIC_C)
 .denied (PRIVATE_INSTANCE_F_M, PACKAGE_INSTANCE_F_M, 
PRIVATE_STATIC_F_M,

  PACKAGE_STATIC_F_M, PRIVATE_C, PACKAGE_C,
  PROTECTED_C)
 .perform();


And besides, you don't really have to review them all. The fact that 
running the test on unpatched JDK 9 finds just two differences:


- access to protected static method from subclass in another package
- access to protected static field from subclass in another package

...is a reassurance that the patch does exactly what it should. No less, 
no more.



Builder::allowAll and Builder::denyAll would be useful.  allowAccessMember 
of a specific modifier can imply both field and method.

This is a good idea. Here's a modified test (no changes to patched files, just 
tests):

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.03/

I like these grouping and it does help.  One more nit: would be good to replace 
the class name strings with constant variables.  I don’t need a new webrev.


Then I would have to have a mapping from class name -> constant name for 
the generator. Besides, constant names would not be any prettier than 
class name string literals. At least now it is obvious to anyone what 
package a particular class belongs to:


"a.Package" vs. A_PACKAGE ?

Note that I can't use a.Package.class literal(s) here (thought I would 
like to) as they don't compile if they refer to a package-private class 
from another package.


I would like to keep those things unchanged, If you don't mind.


thanks
Mandy


Regards, Peter

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Mandy Chung]

> On Oct 16, 2016, at 11:18 AM, Peter Levart  wrote:
> 
> 
> I think specifying both is more verbose on one hand, but OTOH it allows one 
> to visually inspect all the cases and think of each and every one in 
> isolation to see if it is valid in a particular caller/member/target 
> arrangement. The test infrastructure verifies that the test case covers all 
> the MemberFactory(s) so one must only verify each individual allowed / denied 
> MemberFactory.

I understand the intention there.  But when each test case enumerates 20 
constants, it’s getting harder to review what’s going on and catch any issue.

> 
>>Builder::allowAll and Builder::denyAll would be useful.  
>> allowAccessMember of a specific modifier can imply both field and method.
> 
> This is a good idea. Here's a modified test (no changes to patched files, 
> just tests):
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.03/


I like these grouping and it does help.  One more nit: would be good to replace 
the class name strings with constant variables.  I don’t need a new webrev.

thanks
Mandy

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Peter Levart]

Hi Mandy,

Thanks for looking into this patch.

On 10/15/2016 11:31 PM, Mandy Chung wrote:

Hi Peter,


On Oct 2, 2016, at 2:51 PM, Peter Levart  wrote:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.02/

This change looks good to me.  Thanks for adding the test enumerating 
exhaustive combinations.  I ran JCK tests and verified that no new failure.

With this change, sun.reflect.misc.ReflectUtil.ensureMemberAccess could be 
removed when Atomic*FieldUpdater are updated to use 
Reflection::ensureMemberAccess directly. As of now, we will keep 
ReflectUtil::ensureMemberAccess.

AccessControlTest.java is a great test.  I wonder if AccessControlTest.java 
could be made less verbose and make it easier to read.  For example, can we add 
a builder class that takes either the list of allowed or denied MemberFactory  
(but not both) to reduce the verbosity.


I think specifying both is more verbose on one hand, but OTOH it allows 
one to visually inspect all the cases and think of each and every one in 
isolation to see if it is valid in a particular caller/member/target 
arrangement. The test infrastructure verifies that the test case covers 
all the MemberFactory(s) so one must only verify each individual allowed 
/ denied MemberFactory.



Builder::allowAll and Builder::denyAll would be useful.  allowAccessMember 
of a specific modifier can imply both field and method.


This is a good idea. Here's a modified test (no changes to patched 
files, just tests):


http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.03/


Is it easier on the eye now?

I also added Copyright headers to all the test sources.


Regards, Peter

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Mandy Chung]

Hi Peter,

> On Oct 2, 2016, at 2:51 PM, Peter Levart  wrote:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.02/


This change looks good to me.  Thanks for adding the test enumerating 
exhaustive combinations.  I ran JCK tests and verified that no new failure.

With this change, sun.reflect.misc.ReflectUtil.ensureMemberAccess could be 
removed when Atomic*FieldUpdater are updated to use 
Reflection::ensureMemberAccess directly. As of now, we will keep 
ReflectUtil::ensureMemberAccess.

AccessControlTest.java is a great test.  I wonder if AccessControlTest.java 
could be made less verbose and make it easier to read.  For example, can we add 
a builder class that takes either the list of allowed or denied MemberFactory  
(but not both) to reduce the verbosity.   Builder::allowAll and 
Builder::denyAll would be useful.  allowAccessMember of a specific modifier can 
imply both field and method.

The builder will generate a test case that allowed and denied sets are distinct 
and cover the full set of MemberFactory.

Mandy

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Peter Levart]

To a potential reviewer...

The change might look scary at first as it touches reflective access 
controls and by that, security of the platform, but:


- it is just (32 ins; 56 del; 62 mod) lines. The rest is a new jtreg 
test which is beneficial by itself as such test did not exist until now.
- the jtreg test is exhaustive and proves that the patch does not have 
undesired effects.


Thanks,

Peter Levart

On 10/02/2016 11:51 PM, Peter Levart wrote:

Hi,

I added an exhaustive jtreg test that covers all possible situations.

From the set of the following classes:

package a;
public class PublicSuper {...}

package a;
class Package {...}

package b;
public class PublicSub extends a.PublicSuper {...}

package b;
class Package {...}

it creates a set of all possible triplets:

(currentClass, memberClass, targetClass)

where:

currentClass - the class making the reflective access
memberClass - the member's declaring class
targetClass - the target object's class (for accessing instance fields 
and methods - must be equal to or subclass of memberClass)


For each such triplet it checks the reflective access to each of the 
following members:


{private, package, protected, public} x {instance, static} x {field, 
method}


and:

 {private, package, protected, public} x {constructor}

When running on unpatched build 9-ea+137, the result is:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/AccessControlTest_unpatched.jtr

When running on patched build of 9, the result is:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/AccessControlTest_patched.jtr


The difference is exactly in the following two cases which fail for 
unpatched and are fixed by the patch:


b.PublicSub accessing a.PublicSuper's PROTECTED_STATIC_FIELD - 
expected allowed, actual denied : FAILURE
b.PublicSub accessing a.PublicSuper's PROTECTED_STATIC_METHOD - 
expected allowed, actual denied : FAILURE


QED.


This is new webrev:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.02/

I think the test proves the effect of the patch is as intended, 
therefore it should not be a problem to review it.



Regards, Peter


On 10/01/2016 12:20 AM, Peter Levart wrote:

Hi,

I have a fix for a 10 year old bug (JDK-6378384 
). It was marked as 
a duplicate of a 19 year old bug (JDK-4032740 
) which is marked 
as a duplicate of a 17 year old bug (JDK-4283544 
) which is still 
open. But this bug is not a strict duplicate. This bug only concerns 
reflective access to protected members.


Here's a proposed fix:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.01/


The bug manifests itself as not being able to access protected static 
methods or fields from a subclass located in a different package. 
Instance protected methods and fields can be accessed, and using an 
undocumented trick, also static methods and fields, but the trick is 
very subtle. The specification for Field.get/set and Method.invoke 
says, respectively:


 * If the underlying field is a static field, the {@code obj} 
argument

 * is ignored; it may be null.

and:

 * If the underlying method is static, then the specified 
{@code obj}

 * argument is ignored. It may be null.

Well, it is not exactly so! The obj argument is used as a 'target' 
even for protected static members and it is ensured that its class is 
equal or a subclass of the class that accesses the member. So if you 
pass an instance of a subclass of the protected method's declaring 
class into the get/set/invoke, you can access the static protected 
member. If you pass 'null', you get IllegalAccessException.


The problem is in the design of 
jdk.internal.reflect.Reflection#ensureMemberAccess method which is 
used to check reflective access. It takes an Object 'target' 
argument, which is supposed to be null when accessing static 
methods/fields and it is null also when accessing constructors. 
Because of constructors and the method's API, it has to be overly 
restrictive as it must only allow calling protected constructors from 
within the constructor's declaring class itself or same package, 
while protected static methods could be called from any subclass.


By redesigning the API of this method, replacing Object 'target' 
parameter with Class 'targetClass' parameter and by passing the 
constructor's declaring class into this method instead of null, 
reflective checks suddenly start to look more like JLS dictates (but 
still a long way from it, unfortunately).


As a bonus, sun.reflect.misc.ReflectUtil#ensureMemberAccess method 
(used from AtomicXXXFieldUpdater classes) does not need the following 
comment any more:


 * Reflection.ensureMemberAccess is overly-restrictive
 * due to a bug. We awkwardly work around it for now.

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Peter Levart]

Hi,

I added an exhaustive jtreg test that covers all possible situations.

From the set of the following classes:

package a;
public class PublicSuper {...}

package a;
class Package {...}

package b;
public class PublicSub extends a.PublicSuper {...}

package b;
class Package {...}

it creates a set of all possible triplets:

(currentClass, memberClass, targetClass)

where:

currentClass - the class making the reflective access
memberClass - the member's declaring class
targetClass - the target object's class (for accessing instance fields 
and methods - must be equal to or subclass of memberClass)


For each such triplet it checks the reflective access to each of the 
following members:


{private, package, protected, public} x {instance, static} x {field, method}

and:

 {private, package, protected, public} x {constructor}

When running on unpatched build 9-ea+137, the result is:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/AccessControlTest_unpatched.jtr

When running on patched build of 9, the result is:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/AccessControlTest_patched.jtr


The difference is exactly in the following two cases which fail for 
unpatched and are fixed by the patch:


b.PublicSub accessing a.PublicSuper's PROTECTED_STATIC_FIELD - expected 
allowed, actual denied : FAILURE
b.PublicSub accessing a.PublicSuper's PROTECTED_STATIC_METHOD - expected 
allowed, actual denied : FAILURE


QED.


This is new webrev:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.02/

I think the test proves the effect of the patch is as intended, 
therefore it should not be a problem to review it.



Regards, Peter


On 10/01/2016 12:20 AM, Peter Levart wrote:

Hi,

I have a fix for a 10 year old bug (JDK-6378384 
). It was marked as 
a duplicate of a 19 year old bug (JDK-4032740 
) which is marked as 
a duplicate of a 17 year old bug (JDK-4283544 
) which is still 
open. But this bug is not a strict duplicate. This bug only concerns 
reflective access to protected members.


Here's a proposed fix:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.01/


The bug manifests itself as not being able to access protected static 
methods or fields from a subclass located in a different package. 
Instance protected methods and fields can be accessed, and using an 
undocumented trick, also static methods and fields, but the trick is 
very subtle. The specification for Field.get/set and Method.invoke 
says, respectively:


 * If the underlying field is a static field, the {@code obj} 
argument

 * is ignored; it may be null.

and:

 * If the underlying method is static, then the specified 
{@code obj}

 * argument is ignored. It may be null.

Well, it is not exactly so! The obj argument is used as a 'target' 
even for protected static members and it is ensured that its class is 
equal or a subclass of the class that accesses the member. So if you 
pass an instance of a subclass of the protected method's declaring 
class into the get/set/invoke, you can access the static protected 
member. If you pass 'null', you get IllegalAccessException.


The problem is in the design of 
jdk.internal.reflect.Reflection#ensureMemberAccess method which is 
used to check reflective access. It takes an Object 'target' argument, 
which is supposed to be null when accessing static methods/fields and 
it is null also when accessing constructors. Because of constructors 
and the method's API, it has to be overly restrictive as it must only 
allow calling protected constructors from within the constructor's 
declaring class itself or same package, while protected static methods 
could be called from any subclass.


By redesigning the API of this method, replacing Object 'target' 
parameter with Class 'targetClass' parameter and by passing the 
constructor's declaring class into this method instead of null, 
reflective checks suddenly start to look more like JLS dictates (but 
still a long way from it, unfortunately).


As a bonus, sun.reflect.misc.ReflectUtil#ensureMemberAccess method 
(used from AtomicXXXFieldUpdater classes) does not need the following 
comment any more:


 * Reflection.ensureMemberAccess is overly-restrictive
 * due to a bug. We awkwardly work around it for now.

...as it can now delegate straight to Reflection.ensureMemberAccess 
without invoking it twice with different modified member access 
modifiers and performing part of the check itself.


java.lang.reflect.AccessibleObject#checkAccess delegates to 
Reflection.ensureMemberAccess and caches the result, so it had to be 
modified too.


Constructor now passes it's declaring class to the 'targetClass' 
parameter and Filed/Method obey the spec and REALLY IGNORE

RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

[Peter Levart]

Hi,

I have a fix for a 10 year old bug (JDK-6378384 
). It was marked as a 
duplicate of a 19 year old bug (JDK-4032740 
) which is marked as a 
duplicate of a 17 year old bug (JDK-4283544 
) which is still open. 
But this bug is not a strict duplicate. This bug only concerns 
reflective access to protected members.


Here's a proposed fix:

http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.01/


The bug manifests itself as not being able to access protected static 
methods or fields from a subclass located in a different package. 
Instance protected methods and fields can be accessed, and using an 
undocumented trick, also static methods and fields, but the trick is 
very subtle. The specification for Field.get/set and Method.invoke says, 
respectively:


 * If the underlying field is a static field, the {@code obj} 
argument

 * is ignored; it may be null.

and:

 * If the underlying method is static, then the specified {@code 
obj}

 * argument is ignored. It may be null.

Well, it is not exactly so! The obj argument is used as a 'target' even 
for protected static members and it is ensured that its class is equal 
or a subclass of the class that accesses the member. So if you pass an 
instance of a subclass of the protected method's declaring class into 
the get/set/invoke, you can access the static protected member. If you 
pass 'null', you get IllegalAccessException.


The problem is in the design of 
jdk.internal.reflect.Reflection#ensureMemberAccess method which is used 
to check reflective access. It takes an Object 'target' argument, which 
is supposed to be null when accessing static methods/fields and it is 
null also when accessing constructors. Because of constructors and the 
method's API, it has to be overly restrictive as it must only allow 
calling protected constructors from within the constructor's declaring 
class itself or same package, while protected static methods could be 
called from any subclass.


By redesigning the API of this method, replacing Object 'target' 
parameter with Class 'targetClass' parameter and by passing the 
constructor's declaring class into this method instead of null, 
reflective checks suddenly start to look more like JLS dictates (but 
still a long way from it, unfortunately).


As a bonus, sun.reflect.misc.ReflectUtil#ensureMemberAccess method (used 
from AtomicXXXFieldUpdater classes) does not need the following comment 
any more:


 * Reflection.ensureMemberAccess is overly-restrictive
 * due to a bug. We awkwardly work around it for now.

...as it can now delegate straight to Reflection.ensureMemberAccess 
without invoking it twice with different modified member access 
modifiers and performing part of the check itself.


java.lang.reflect.AccessibleObject#checkAccess delegates to 
Reflection.ensureMemberAccess and caches the result, so it had to be 
modified too.


Constructor now passes it's declaring class to the 'targetClass' 
parameter and Filed/Method obey the spec and REALLY IGNORE 'obj' 
parameter in get/set/invoke on a static member.


All java/lang/reflect and java/util/concurrent/atomic tests pass with 
this patch applied except the following:


java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java: Test 
java.lang.reflect.AccessibleObject with modules
java/lang/reflect/Generics/TestBadSignatures.java: Test bad signatures 
get a GenericSignatureFormatError thrown.
java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java: 
Reflection support for private methods in interfaces
java/lang/reflect/Module/AddExportsTest.java: Test Module isExported 
methods with exports changed by -AddExportsTest
java/lang/reflect/Proxy/ProxyModuleMapping.java: Basic test of proxy 
module mapping and the access to Proxy class

java/lang/reflect/WeakPairMap/Driver.java: Functional test for WeakPairMap

...which all fail because of:

javac: invalid flag: -XaddExports:java.base/jdk.internal



Regards, Peter