Name: nt126004 Date: 12/04/2002
FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)
FULL OPERATING SYSTEM VERSION :
Not important.
A DESCRIPTION OF THE PROBLEM :
IncompatibleClassChangeError needs to give more specific
information about the problem discovered in order to be useful.
It should tell us, what was expected, and what was found.
Well, in my case I'm trying to do a "clean room" implementation of a 3rd party library. As it turns out, there was an incompatability because part of my implementation used an interface (implemented under the hood) where
the commercial version used a concrete class.
As a result, applications would compile against and work with either version of the library. When the library was swapped without recompiling, the VM would find an "invokevirtual" bytecode where it expected an
"invokeinterface" or vice versa. I had to use a bytecode viewer to figure this out, because the IncompatableClassChangeError told me nothing of the fact.
The error should have told me something like: it expected XYZ to be an interface when it was actually a class, or vice versa.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected result:
java.lang.IncompatibleClassChangeError: found invoke_virtual
for Interface, com.Foo.bar().
Actual result:
java.lang.IncompatibleClassChangeError
REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 167256)
======================================================================
FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)
FULL OPERATING SYSTEM VERSION :
Not important.
A DESCRIPTION OF THE PROBLEM :
IncompatibleClassChangeError needs to give more specific
information about the problem discovered in order to be useful.
It should tell us, what was expected, and what was found.
Well, in my case I'm trying to do a "clean room" implementation of a 3rd party library. As it turns out, there was an incompatability because part of my implementation used an interface (implemented under the hood) where
the commercial version used a concrete class.
As a result, applications would compile against and work with either version of the library. When the library was swapped without recompiling, the VM would find an "invokevirtual" bytecode where it expected an
"invokeinterface" or vice versa. I had to use a bytecode viewer to figure this out, because the IncompatableClassChangeError told me nothing of the fact.
The error should have told me something like: it expected XYZ to be an interface when it was actually a class, or vice versa.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected result:
java.lang.IncompatibleClassChangeError: found invoke_virtual
for Interface, com.Foo.bar().
Actual result:
java.lang.IncompatibleClassChangeError
REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 167256)
======================================================================