[fpc-devel] FPC-JVM: Status report on Android

[Jonas Maebe]

On 28 Aug 2011, at 22:16, Sven Barth wrote:

> On 28.08.2011 21:38, Jonas Maebe wrote:
>> 
>> On 27 Aug 2011, at 17:43, Sven Barth wrote:
>> 
>>> And here the log entry when building the Java based example with a class that derives from TObject:
>>> 
>>> === begin build log ===
>>> 
>>>     [echo] Converting compiled files and external libraries into /home/sven/projects/android/helloandroid/bin/classes.dex...
>>>    [apply]
>>>    [apply] UNEXPECTED TOP-LEVEL EXCEPTION:
>>>    [apply] com.android.dx.cf.code.SimException: local variable type mismatch: attempt to set or access a value of type java.lang.Object using a local variable of type boolean. This is symptomatic of .class transformation tools that ignore local variable information.
>> 
>> Can you run the bytecode verifier on the class files generated for your program? See http://wiki.freepascal.org/FPC_JVM/Debugging#Bytecode_verification for the details. You may also have to add the android.jar to the class path for the verifier to work (although I'm not 100% certain whether that will work in case the android versions of java.lang.* start replacing the JDK versions of the same classes for running the verifier itself)
> 
> I don't think using the verifier on my own class files will be of much use, because if I understand the log correct it complains about the code in FpcBitSet.containsAll (mentioned in the last few lines before the next empty one).

The org.freepascal.rtl.system class verifies fine here, and the FpcBitSet stuff also works fine. Maybe the methods of java.util.BitSet (on which org.freepascal.rtl.FpcBitSet is based) have different signatures in the Android version compared to the Java version. Since the FPC RTL shipped with the snapshot is compiled against the JDK bindings, that would explain the problems.

You could try to regenerate rtl/java/java_sys(h).inc using the first invocation listed at http://wiki.freepascal.org/FPC_JVM/Building#Building_javapp (but adding "-classpath android.jar" so it will use the android version of all those classes) and then rebuild the RTL (if it still compiles with those different signatures).

> Also - regarding your android.jar comment - I'm not even using any Android classes in that example... just TObject (as a base class) and UnicodeString (it tried to convert all RTL classes, because I put the complete RTL in the projects bin directory, in which all contained .class files are converted).

The RTL uses android/JDK classes (such as several classes from java.lang and java.util).


Jonas