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
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
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: