FULL PRODUCT VERSION :

java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows 10.0.10586

A DESCRIPTION OF THE PROBLEM :
We are getting "Agent JAR loaded, but failed to initialize" error on our Class Redefinition Agent. This is a fully functional agent and we have been using it normally for all our instrumentation operation.

The issue seems to have been reported quite a long time ago in
https://bugs.openjdk.java.net/browse/JDK-6962615

But our concern here is that the explanation for the exception thrown "AgentInitializationException" is not clear and the stacktrace is not recoverable, except the main message.

Also, the agent can successfully redefine other classes without offending the following restrictions:

1) Method signature change
2) New Method addition
3) Circular reference in class

We have seen this occurring twice and in both cases, the change was below:

From this:
***********************************************************************
if (this.getCondition() == true) {
method.setObjectSetup(someOtherObject.getObjectSetup());
method.setLocalString(someOtherObject.getLocalString());
}
***********************************************************************
to That:
***********************************************************************
if (this.getCondition() == true) {
//method.setObjectSetup(someOtherObject.getObjectSetup());
method.setLocalString(someOtherObject.getLocalString());
}
method.setObjectSetup(someOtherObject.getObjectSetup());
method.setActionStep(altObject.getActionStep());
***********************************************************************

As you can see this is a simply change in an existing method body which is perfectly legal. We have run this class file through SonarQube and SonarLint agents to identify any circular reference, but nothing was reported. This is leading us to believe that the error message which is coming from loadAgent() method for com.sun.tools.attach.VirtualMachine class implementation isn't correct/consistent.

We also checked the source code described here which has not changed from 8u66, so the same code is being run in 8u121

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/tools/attach/HotSpotVirtualMachine.java#HotSpotVirtualMachine.readInt%28java.io.InputStream%29

For IPR reasons, we cannot publish our source-code, but we can confirm that this is not happening for all classes. Only certain classes, but without a clear exception type or error message. We would be grateful if you could let us know whether a full explanation of such discrepancy is provided anywhere.



REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
Restart the production servers (a farm of 100 servers) in small batches to put changes into effect.