Using jars that use java.beans classes (Introspector, BeanInfo or PropertyDescriptor)

Question

I have 3rd party jar ( which I can't change ) that uses java.beans.Introspector , java.beans.BeanInfo and java.beans.PropertyDescriptor .

How can I use that jar in my android application?

It fails loading the class (which uses Introspector ) from the 3th party jar:

WARN/dalvikvm(780): VFY: unable to resolve static method 6325: Ljava/beans/Introspector;.getBeanInfo (Ljava/lang/Class;)Ljava/beans/BeanInfo;
WARN/dalvikvm(780): VFY: unable to resolve exception class 962 (Ljava/beans/IntrospectionException;)
WARN/dalvikvm(780): Verifier rejected class Lorg/thirdpartyjar/SomeClass;

Answer 1

It's clear java.beans package is not complete on android. And common solution is to repackage both java.beans and jar dependent on them to use different package name instead of java.beans. This is exactly what previously mentioned openbeans do. And an interesting qoute from android error message states: If you find that you cannot do this, then that is an indication that the path you are on will ultimately lead to pain, suffering, grief, and lamentation.

To avoid this path i would start by looking into options of actually using openbeans and trying to force 3rd party into using those. From what your are writing it's not clear if jar can't be changed or is not allowed to be changed(you mention both). I don't know legal implications of changing jars, but technically it's always possible, eg trying reverse engineer classes, do some build time instrumentation with something like aspectj. If this is not allowed i think runtime instrumentation can be done, eg dexmaker can create proxy for your third party class, which is using java.beans and you can reimplement part of this class.

Also googling a little on the topic i saw this . They just use java.beans package and compile it for android. This seems fragile for me, but looks like it's working.

Unfortunately this is not a solution, just ideas i wanted to share. Hope you find those useful.

Answer 2

The only solution is a maintenance nightmare: Fork all 3th party jars from source and rewrite them so they don't use java.beans.* classes (possibly by replacing them for openbeans).

Then, every time one of those 3th party jars releases a hotfix (for example for a critical security bug), do that all over again .