On 18 Feb 2012, at 06:40, Niclas Hedhman wrote: > Hi, > I have noticed that package protected constructors can not be used, > and I tracked it down to the FragmentClassloader that doesn't create a > matching constructor for non-(public || protected) constructors. > > Once I changed that to non-private, I get this remarkable exception; > > Caused by: java.lang.IllegalAccessError: tried to access method > org.qi4j.library.scheduler.SchedulerService$ThreadFactory.<init>(Lorg/qi4j/library/scheduler/SchedulerService;)V > from class org.qi4j.library.scheduler.SchedulerService_ThreadFactory_Stub > > which says that the package protection is trying to be compromised, > even though it seems to be the same package. > > So to be sure, I added printing the package of the class and the superclass; > > Class package: package org.qi4j.library.scheduler > Superclass package: package org.qi4j.library.scheduler > > and they are identical!!! > > SO, I suspected that this was classloader related; > > Class CL: org.qi4j.runtime.composite.FragmentClassLoader@47ad6b4b > Superclass CL: sun.misc.Launcher$AppClassLoader@1ef6a746 > > Sure enough... > > I assume (guys like Stuart would know for sure) that there are some > kind of validation of cross-classloader packages in the JVM.
http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#75934 "A field or method R is accessible to a class or interface D if and only if any of the following conditions is true: * R is public. * R is protected and is declared in a class C, and D is either a subclass of C or C itself. * R is either protected or package private (that is, neither public nor protected nor private), and is declared by a class in the same runtime package as D. * R is private and is declared in D." Note for package-private methods it says "same runtime package", which means both the same package _and_ the same classloader. See also http://www.cooljeff.co.uk/2009/05/03/the-subtleties-of-overriding-package-private-methods/ for further twists when overriding package-private methods :) > So, I am placing an open question; Are we doing too much, or too > little, classloading tricks in Qi4j today? > Should we require that the FragmentClassloader becomes the System > Classloader for the entire Qi4j application, i.e. all client code > would be loaded via it? Or should we simply leave it as it is and live > with the rough edges around class/method protection? > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/6a2pl4j > I relax here; http://tinyurl.com/2cgsug > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
