RFR: jsr166 jdk9 integration wave 2

Peter Levart peter.levart at gmail.com
Fri Dec 4 14:57:26 UTC 2015



On 12/04/2015 02:46 PM, Doug Lea wrote:
> Also, could you explain...
>
>>
>> Note that such code and similar code in 
>> ForkJoinTask.getThrowableException
>> will probably have to be modified for jigsaw to include dynamic 
>> addition of
>> read-edge to the module of exception class...
>>
>
> -Doug

As jigsaw currently stands (but this might change before JDK9 ships), 
reflective access to class members (Class.newInstance(), 
[Method|Constructor].invoke(), Field.[get()|set()]) is governed by same 
access checks as bytecode instructions accessing those members, which 
means that:

- the module doing access "must read" the module that the target class 
is declared in ("requires targetModule" in module-info of accessing module)
- the package of the target class "must be exported" to at least the 
module doing the access ("exports targetPackage [to accessingModule]" in 
module-info of target module)
- class/member access modifiers must allow access as normally


classes in java.util.concurrent and sub-packages are part of java.base 
module, but exceptions that will be thrown in ForkJoinTask(s) and 
CompletableFuture actions can come from any module (a user module for 
example).

- It is a responsibility of (user) modules to export exception types 
that they are throwing and which instances can escape to code of other 
modules.

- java.base module does not (at startup) read any module, but read-edges 
can be added dynamically at runtime from the module adding the read-edge 
(self module) to any module (Module.addRead(Module) API).

So before we can successfully invoke:

     exceptionClass.newInstance();

there would have to be something like:

     ThisClass.class.getModule().addRead(exceptionClass.getModule());


...because we are invoking the constructor of the exceptionClass which 
might be declared in some other module (not java.base) which is not read 
by java.base by default.

The solution with Throwable.clone() would not suffer from that, as the 
only type we would be dealing with is java.lang.Throwable (part of 
java.base).



Regards, Peter




More information about the core-libs-dev mailing list