-
Bug
-
Resolution: Unresolved
-
P4
-
24
-
None
The sun.instrument.TransformerManager.transform() method implementation, currently has this:
try {
transformedBytes = transformer.transform( module,
loader,
classname,
classBeingRedefined,
protectionDomain,
bufferToUse);
}
catch (Throwable t) {
// don't let any one transformer mess it up for the others.
// This is where we need to put some logging. What should go here? FIXME
}
As you will notice, anything thrown from the ClassFileTransformer's transform() method gets eaten up in the catch block without it ever being reported. There's even a FIXME code comment about it.
Addressing this may not be straightforward since java.lang.instrument.Instrument.addTransformer(...) notes (among other things):
> If a transformer throws an exception during execution, the JVM will still call the other registered transformers in order.
So it might need some additional thought on how/when these exceptions can be reported.
try {
transformedBytes = transformer.transform( module,
loader,
classname,
classBeingRedefined,
protectionDomain,
bufferToUse);
}
catch (Throwable t) {
// don't let any one transformer mess it up for the others.
// This is where we need to put some logging. What should go here? FIXME
}
As you will notice, anything thrown from the ClassFileTransformer's transform() method gets eaten up in the catch block without it ever being reported. There's even a FIXME code comment about it.
Addressing this may not be straightforward since java.lang.instrument.Instrument.addTransformer(...) notes (among other things):
> If a transformer throws an exception during execution, the JVM will still call the other registered transformers in order.
So it might need some additional thought on how/when these exceptions can be reported.
- relates to
-
JDK-8164165 JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded
-
- Open
-
-
JDK-8334167 Test java/lang/instrument/NativeMethodPrefixApp.java timed out
-
- Resolved
-