[Bug libgcj/17021] libgcj verifier resolves classes too eagerly

thebohemian at gmx dot net gcc-bugzilla@gcc.gnu.org
Tue Oct 18 00:18:00 GMT 2005

------- Comment #6 from thebohemian at gmx dot net  2005-10-18 00:18 -------
With the help of Tromey and the team we made an interesting obervation:

class Foo{
     static Object o;

     void method(){
          o = new RemoveClassFile();

This is accepted by you-know-which VM but rejected by GIJ (processing putstatic
opcode in verify.cc leads to _Jv_BytecodeVerifier::ref_intersection::compatible
which in turn resolves the RHS).

Now takes this situation:

class Foo{
     static Thread t;

     void method(){
          t = new RemoveClassFileFromClassWhichInheritsFromThread();

This is rejected by the 'other' verifier, too if no class file could be found.
The idea seems to be that the assignment test is short-cutted if the LHS is

Now we have to find and fix every situation where this can happen. Here is a
partial list:
- static assignment
- non-static assignment
- array assignment
- arguments to methods
- return values
- type state merges (only tromey knows what this is ;) )

If you have real world class files where this bug happens please send them to



More information about the Java-prs mailing list