On Sat, 25 Oct 2003 17:07:52 +0200 Guilhem Lavaux <[EMAIL PROTECTED]> wrote:
> Helmer Krämer wrote: > > >On Fri, 24 Oct 2003 20:14:38 +0200 > >Guilhem Lavaux <[EMAIL PROTECTED]> 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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe