On Thursday, April 16, 2009 5:31:45 PM UTC-4, fadden wrote:
> Most of what you're describing falls into the category of, "that's how
> class loaders work in the Java programming environment". If you
> create a class loader, and load a class called MyClass from it, you
> can't trivially refer to MyClass because the current class' loader
> can't resolve it. You have to use reflection to get at it. Class
> cast operations don't always do what you want.
> You can see some twisted examples in dalvik/tests/068-classloader.
> The cross-loader complaints arise when you do something like this:
> mystuff.dex has "MyClass" and "MyOtherClass"
> newstuff.dex has "NewClass" and "MyOtherClass"
> FancyClassLoader knows about mystuff.dex and newstuff.dex
> FancyClassLoader uses MyOtherClass from newstuff.dex
> When mystuff.dex was run through "dexopt", it was verified and
> optimized with the assumption that references from MyClass to
> MyOtherClass would refer to the implementation in the same DEX file.
> However, FancyClassLoader chose to load a different implementation of
> MyOtherClass. This can cause Issues, so it's not allowed. (This
> could work in a more traditional VM, where the verification and
> optimization aren't performed ahead of time, but might not do what you
> expect.)
> If you want specifics about the classes involved, there's an intensely
> cryptic message in the log file ("Class resolved by unexpected DEX")
> that has some info.
> You can avoid this situation by only having one implementation of a
> given class. And by not loading the same DEX file into multiple class
> loaders.
> BTW, just so we don't confuse each other with terminology:
> (1) bootstrap class loader. Path set by BOOTCLASSPATH. Includes
> core / ext / framework / android.policy / services. Implemented
> directly by the VM.
> (2) system class loader, a/k/a application class loader. Path set by
> CLASSPATH. I don't think this is used by the Android framework.
> (3) user-defined class loader. The Android app framework
> implementation uses the ApplicationLoaders class to manage a
> dalvik.system.PathClassLoader per app.
> On Apr 16, 6:24 am, Eborix13 <ebori...@yahoo.com> wrote:
> > Hi,
> > Seeing that the new 1.5 pre-release has support for loading classes
> > dynamically I immediately tried to see if it works. I used the
> > DexClassLoader(String dexPath, String dexOutputDir, String libPath,
> > ClassLoader parent) constructor. But I soon found out that it works
> > only partially.
> > What I am trying to do is dynamically load a class from a given jar
> > file which contains a classes.dex file. If I try to use the current
> > class loader (this.getClass().getClassLoader()) as the "parent"
> > parameter I get a "java.lang.IllegalAccessError: cross-loader access
> > from pre-verified class" error. But if I use the SystemClassLoader as
> > the "parent" parameter everything works out nicely. But using the
> > SystemClassLoader is a problem for me because the class that is loaded
> > using the SystemClassLoader is a subclass of a class which was
> > previously loaded by the current class loader. Casting the derived
> > class to the base class generates a ClassCastException because the
> > base class was not loaded with the same class loader as the derived
> > class.
> > Is there a way to solve this problem? Am I doing something wrong? Is
> > there a way to dynamically load a class using the current class loader
> > instead of the system class loader? Is this problem caused by the fact
> > that the 1.5 release is incomplete yet, so perhaps this problem is
> > going to be solved in the final release?
> > Thank you...
