(Edited to add: see the triumphant conclusion)

I mentioned this possible approach near the end of the last episode. This one hasn’t worked for me yet. I wrote a little activity, which tries to load a clojure .apk, then offers that .apk as a parent classloader to load my actual stuff from another apk. This starts well, in that my actual stuff gets access to the clojure libraries. But it goes wrong, because one of the first things it tries to do with those clojure libraries is load another class. But that class is in the “wrong” APK, and it falls over.

Here’s the structure. If you have a reference to something lower down the stack, you can pull it out specifically – so in A, I can get something from C – but by default you just get stuff from higher up the stack:

A – an activity in java
B – the clojure runtime
C – my activity in clojure

And what happens is that I load my activity from C, it hits up the clojure runtime, the clojure runtime starts looking for another part of my activity, but it looks up, not down, so it never finds it. I hoped to get around this by tweaking the clojure runtime to look to the thread’s contextClassLoader for all it’s class loading needs, then shoving classloader C in the diagram above in as the contextClassLoader before loading stuff from it, but no love from that one.

This is getting silly. I wanted to make a triumphant post telling of a beautiful and awesome approach that you could use to make this practical. Not there yet.

On the other hand, the build for this package is nice and fast. The compile+install only takes 7 seconds. But let’s not talk about the 30 second app startup time.

• Uncategorized