Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net

[Andrew Dinn]

Hi Rory,

I am afraid I spoke too soon as far as building/running Byteman on JDK9
b42 is concerned (I made an error during testing whihc meant that I did
nto test the correct version).

The Byteman agent code (that's everything in in byteman-jar) appears to
be working ok. However, there appears to be a problem with the BMUnit
package (that's bundled in byteman-bmunit.jar) which integrates the
Byteman agent into JUnit and TestNG.

The problem arises because BMUnit relies on class Virtual Machine and
other related classes to autoload the Byteman agent into a test JVM.
The relevant behaviour is defined by the following classes

  com.sun.tools.attach.VirtualMachine
  com.sun.tools.attach.VirtualMachineDescriptor
  com.sun.tools.attach.AttachNotSupportedException
  com.sun.tools.attach.AgentLoadException
  com.sun.tools.attach.AgentInitializationException

The code in byteman-bmunit.jar references the exception classes. There
are also references to these classes in the utility jar
byteman-install.jar which encapsulates the agent load routines.

Both these jars build ok with JDK9 b42 -- references to the attach
package are successfully resolved at compile time. However, I am getting
run-time resolve failures for when the classes which reference then are
loaded at runtime -- for example:


  -------------------------------------------------------
  Running TestSuite
  ATest::foo()
  org.apache.maven.surefire.booter.SurefireExecutionException:
com/sun/tools/attach/AgentInitializationException; nested exception is
java.lang.NoClassDefFoundError:
com/sun/tools/attach/AgentInitializationException
  java.lang.NoClassDefFoundError:
com/sun/tools/attach/AgentInitializationException
	at
org.jboss.byteman.contrib.bmunit.BMNGAbstractRunner.switchClass(BMNGAbstractRunner.java:231)
	at
org.jboss.byteman.contrib.bmunit.BMNGListener.onFinish(BMNGListener.java:156)
	. . .

Class BMNGAbstractRunner is a Byteman class which subclasses one of the
classes in the TestNG test package so that it can identify Byteman
annotations on test classes/methods before/after the associated tests
are run. It's job is to load the Byteman agent (if it is not already
present in the JVM) and then post it details of code transformations
needed in order to test the application and request removal of the
transforms once the test has been run. Transforms may require the agent
to inject trace code, validation checks or code which creates and
propagates faults into either application or runtime classes.

The error above occurs when BMNGAbstractRunner invokes a method which
initiates the agent load. The latter method calls Install.install()
(defined in byteman-install.jar) which in turn calls
VritualMachine.loadAgent(). If the agent load fails the BMUnit code
tries to catch an AgentInitializationException because that indicates
that the agent is already present. With JDK6/7/8 this exception class is
resolved at compile time and runtime. With JDK9 the runtime resolution
fails as you can see above.

It is worth noting that I can bypass the above resolution problem in the
BMUNit code by modifying the catch to use type Exception. However, when
I do that I then find that the code in the byteman-install.jar also
fails to resolve references to classes in the attach package. That in
itself is not very surprising. However, what makes this interesting is
that this resolution failure does not always happen.

Class Install has a main method which exposes the same behaviour that
BMUnit is employing allowing you to load an agent into an independently
running JVM. If I invoke this main method from the java command line
then references from Install (and other classes) to classes in the
attach package /are/ resolved at runtime. So, when TestNG or JUnit
invoke Install.install() we get runtime resolve failures but when class
Install is run and invokes Install.install() the attach classes are
resolved.

I have not yet looked at what is going on in the JDK9 code to identify
why the attach package class lookups fail under TestNG nor, indeed, why
the command line invocation of class Install somehow manages to resolve
those references. I will try to do so in the next few days. However, if
you have any inkling as to how changes in the class lookup that might
inhibit runtime (but not compile-time) resolution of references to this
package I'd be very interested to hear it.

regards,


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