Java Platform Module System : Potential Additional Issue s

[Andrew Dinn]

I have a couple of concerns regarding the proposals in JEP 261. I know
this is still only a candidate but it still seems appropriate to place
these concerns on the record. Details are provided after my signature.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul
Argiry (US)


Issue:

The first point at issue in JEP 261 arises under heading/subheading
"Removed: Bootstrap class-path options/Open design issues" where it says:

"Should the -Xbootclasspath/a option, and the corresponding JVM TI API,
be deprecated in JDK 9 with the intent to remove them in JDK 10?"

Problem:

Byteman requires the JVMTI API in order to be able to instrument classes
which belong to the bootstrap. The byteman agent jar (and, possibly,
other agent 'helper' jars) can be hoisted into the bootstrap path during
agent loading so that Byteman classes can be referenced from injected
code (specifically, 3 Byteman exception classes need to be referenced
form injected code).

Injection into bootstrap classes is critical when it comes to
engineering many common fault injection scenarios during testing. For
example, Byteman is commonly used to force file stream operations to
throw synthetic exceptions in order to exercise error handling code.

Injection into bootstrap code is also critical to being able to inject
code which traces and monitors execution of errant programs. For
example, tracing of calls to Thread.setInterrupted has been used in the
past to identify errors in 3rd party libraries which fail to handle
InterruptedException correctly.

Possible Resolution:

Retain this privileged API for JVMTI agents

Issue:

The second point at issue in JEP 261 arises under heading "Risks and
Assumptions" where it says

"The java.lang.reflect.AccessibleObject::setAccessible method cannot be
used to gain access to members of packages that are not exported by
their defining modules; an InaccessibleObjectException will be thrown.
If a framework library, such as a serializer, needs access to such
members then the relevant packages must be exported to the framework
module either via exports declarations in module descriptors or the
-XaddExports command-line option."

Problem:

Byteman relies upon the use of reflective access via setAccessible to
enable injected code to invoke non-public methods and read or update
non-public fields. Such access is critical to support both tracing,
monitoring and debugging of application behaviour and engineering of
fault injection scenarios.

Since Byteman is frequently used ad hoc when an error situation arises
it will not normally be possible to pre-specify either the necessary
exports declaration or suitable -XaddExports command-line options when
using Byteman for tracing, monitoring and debugging.

Although these options are available when implementing fault injection
testing they significantly complicate test setup and management.

n.b. I have looked at recent implementations of JDK9 which include code
laid down in preparation for Jigsaw and I notice that something of this
sort appears already to have been implemented. setAccessible now
includes a check to ensure that the calling class and member are
'module-compatible'. The present code does not seem to be stopping the
Byteman agent from accessing private members of classes which belong to
modules (whether that's jdk.base or others). So, I am not sure if there
is a real problem here which has not yet manifested because the
implementation is incomplete or whether a get-out for JVMTI agent code
is already implemented.

Possible Resolution:

Provide agent code with special permissions to employ the setAccessible
API without risking an InaccessibleObjectException.