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...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
