[kaffe] java.lang.IllegalAccessError

[Helmer Krämer]

On Sat, 25 Oct 2003 17:07:52 +0200
Guilhem Lavaux <guilhem at kaffe.org> wrote:

> Helmer Krämer wrote:
> 
> >On Fri, 24 Oct 2003 20:14:38 +0200
> >Guilhem Lavaux <guilhem at kaffe.org> wrote:
> >
> >Hi Guilhem, hi Ito,
> > 
> >  
> >
> >>>The attached programs cause java.lang.IllegalAccessError,
> >>>which partly seemes to have something to do with KJC,
> >>>but class files compiled with Sun's javac also cause the
> >>>error.
> >>>
> >>>      
> >>>
> >>Apparently KJC choses to protect the inner class (as usual). I've not 
> >>really seen a specific restriction about access modifiers concerning 
> >>inner classes in doc but the JDK's compiler put your sample class in 
> >>public access (even though you explicitly specified it protected). The 
> >>best guess I can make is to ignore the access modifier for inner classes 
> >>in KJC. I'll prepare this for tomorrow.
> >>    
> >>
> >
> >I don't think that this would be the correct fix (altering
> >the access modifiers during compilation doesn't look right
> >to me). For a discussion of a similar problem have a look
> >at the thread starting at this mail:
> > 
> >http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.10.10010111327040.12800-100000%40green.usr.onet
> >
> >I think the real problem is kaffe's runtime access checking,
> >which is why I'm about to check in the following patch:
> >  
> >
> Yes, but this doesn't solve the problem concerning JDK. If you 
> disassemble the code generated
> from the classes provided by Ito you may notice that the inner class 
> doesn't have any protection
> although it is protected. But I've made another test with private and 
> apparently it changes something also
> concerning the modifier, so the problem should be more complicated.

The problem is that Base$Base1.class contains two different sets of
access modifiers that are applicable to Base.Base1 . One set is stored
in the 2 bytes following the constant pool, the other one can be extracted
from the "InnerClasses" attribute of the constant pool.

As far as inner classes are concerned, these two sets don't seem
to be identical. The one that is stored outside of the constant
pool doesn't seem to resemble the set of modifiers given in the
corresponding source file, whereas the one that is stored in the
"InnerClasses" attribute does.

The difference between jikes, javac and kjc is what they do with
the set stored outside of the constant pool. Javac and jikes put
the ACC_PUBLIC bit in this set, whereas kjc leaves it alone. As
you've said, this set even looks different when the inner class
is declared private.

However, the interesting question is, which set is to be choosen
when verifying accesses between classes at runtime. Kaffe at least
drops the one stored outside the constant pool and only works with
the one extracted from the "InnerClasses" attribute, which is why
kaffe works with my patch applied.

So, the question is whether the contents of the set stored outside
of the constant pool are specified for inner classes or whether
they're unspecified and setting ACC_PUBLIC in it is just a work
around for some vm, verifier, whatever, that doesn't extract the
access modifiers from the constant pool.

Regards,
Helmer