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
