[
https://issues.apache.org/jira/browse/FELIX-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629559#comment-16629559
]
Tom Rutchik commented on FELIX-5913:
------------------------------------
Paul,
I'm not quite following the argument. The statement:
"However, I think it is somewhat problematic that we can not be the classloader
itself."
Is what's confusing me. The claim seem to suggest I've made some kind of false
assumption. That could be case, but I'm not seeing it.
In the case of not running on an android system, there's really no change in
how the code executes. I'm also not seeing any direct dependences on Android.
In my inspection, all the android classes only come into play when you're
running on an Android VM. And all those classes are all produced through Java
reflections, so it shouldn't interfer with the Java implementation. I also
don't see any import statements that have any android dependencies in them.
All I've done is subclassed the BundleClassLoader and delegated the loadClass
method to a PathClassLoader (produce through Java reflection) whose parent is
the normal BundleClassLoader. It's only affect is that it tries the
PathClassLoader's path to load the class if the BundleClassLoader fails to load
the class; this is effectively what the 5.6.10 version did except it did it as
a direct call to the DexFile class after as the last step of the
BundleCLassLoader. In the new model, the BundleClassLoader fails and then the
PathClassLoader tries to see if it can find the class on its path.
I also don't see how BundleReference and Lazy Evaluation would be affected.
Are they using some different mechanism that bypasses the normal
BundleClassLoader? I was only aware of the one place in the code that DexFile
was used, and that was in the BundleWiringImpl! If that's not the case, then
yes, there is something wrong, but I don't think so.
What I'm trying to say, IMHO is that the code changes I made all preserve the
original semantics (SPT - semantic preservation transformation). How
BundleWiringImp Class and the BundleClassLoader was used before, remains the
same. In the case of the Java VM, you work directly with the BundleClassLoader,
and in the case of the Dalvik VM your actually working with the
DexBundleClassLoader, which is treated like any other BundleClassLoader.
----------------------------------------------------------
That said, I will be looking at your branch and see how you approached the
problem. Maybe that'll clear up some of the confusing that I referred to
above. I'll try to send you some comment back tomorrow. I can also try
running it in my project to test it out.
-Tom Rutchik
> Support Android
> ---------------
>
> Key: FELIX-5913
> URL: https://issues.apache.org/jira/browse/FELIX-5913
> Project: Felix
> Issue Type: Wish
> Components: Framework
> Affects Versions: framework-6.0.0, framework-6.0.1
> Reporter: Tom Rutchik
> Priority: Major
> Attachments: BundleWiringImpl.java,
> FelixAndroidSupportImplementationNotes.pdf
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> The lastest 6.0.0 and 6.0.1 release no longer works on Android.
> The code form the 5.6.10 version necessary to make it work was not ported
> into these versions.
> Some code needs to be added to the class BundleWiringImpl class to allow for
> android support. All of the code necessary to due that can be found in the
> 5.6.10 version.
> I've added the code and have tested it and it's working fine again. I've
> attached an implementation of BundleWiringImpl that works with android. It's
> basically the 6.0.1 implementation with the extra code from 5.6.10. You
> should be able to do a file diff on the 6.0.1 to see where I had to add the
> missing code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
