[kaffe] java.lang.IllegalAccessError

[Chris Gray]

This is an aspect of a known security misfeature of inner classes: some 
access controls which are enforced by the compiler cannot be enforced by the 
VM with the same granularity, because the VM doesn't really grok the 
inner/outer class hierarchy.  E.g from 
<http://www.lsd-pl.net/documents/javasecurity-1.0.0.pdf>:

<blockquote>In the case where system classes use inner classes, these inner 
classes can be accessed from anycode in the same package. This is due to the 
fact that Java bytecode has no concept of inner classes,so they are 
translated by the compiler into ordinary classes. Besides, inner classes are 
allowed toaccess private fields of the outer classes. This is caused by the 
fact that they are always translatedinto separate classes. Therefore, in 
order to let the inner class access the fields of the correspondingouter 
class, the compiler silently changes these fields from private to package 
scope.
</blockquote>

Chris

On Saturday 25 October 2003 17:07, Guilhem Lavaux 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.1001
> >0111327040.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.
>
> Cheers,
> Guilhem.
>
>
>
> _______________________________________________
> kaffe mailing list
> kaffe at kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

-- 
Chris Gray                                /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi              http://www.kiffer.be/k/
chris.gray at kiffer.be                      +32 477 599 703