The standard Lookup class has got a number of ways for the programmer to provide his own implementation behind the scenes of Lookup.getDefault(): a class name in a system property, or a Lookup or Lookup.Provider class registered in META-INF/services. Unfortunately, as I said before, I wasn't able to make any of those work because of issues with the classloader. I think that these issues can be solved (after all, OSGi can run on Android and it's heavily classloader-based), but need to learn more stuff. So, I resorted to an old trick of NetBeans developers that relies on reflection:
public class BlueBillApplication extends Application
public void onCreate()
final Field defaultLookup = Lookup.class.getDeclaredField("defaultLookup");
final BlueBillLookup blueBillLookup = new BlueBillLookup();
catch (Exception e)
throw new RuntimeException(e);
Properly configured in the Android manifest, BlueBillApplication gets notified of the fundamental life-cycle events of the application and is able to initialize the global Lookup before any other part of the application kicks in.
What's ahead? I need to better understand the part about how Android does (not) manage resources embedded in jar files. If it's an unworkable limitation, one alternative could be to use the Maven Shade plugin that is able to transform and relocate files in a jar; it could copy the content of the META-INF/services/* directory in a properly Android-style resource under 'res' or 'assets'. In the same way, I could replace the code inside org-openide-util.jar that scans META-INF/services with a proper alternate implementation.
Also, I've also run into some incompatibilities between Lookup and the Android runtime. For instance, an internal implementation class had to be patched, as it raised an exception that doesn't occur with the Sun JDK; and there's an internal dependency on a simple event-related class of Swing, that is not available in Android. The Maven Shade plugin, that is able to replace single pieces in JAR contents and even renaming all the references to a given class, proved to be ok to deal with this kind of problems, as it allowed me to provide a patched for the broken class and the missing class without having to fork the original sources. I'm not going into details about this stuff, since in the end these fixes aren't needed in my current trunk - maybe I'll be back with this topic in a new post.