Forum Xamarin.Android


The Xamarin Forums have officially moved to the new Microsoft Q&A experience. Microsoft Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

To create new threads and ask questions head over to Microsoft Q&A for .NET and get involved today.

How serious are a lot of Java Bindings Library Class JDK mismatches?

CaptainXamtasticCaptainXamtastic GBUniversity ✭✭✭

I'm presently doing the Java Binding Libraries for six different .aar files, and seeing that a substantial amount of top ancestors were not generated in the api.xml file, nor generated as C# class files in the obj/debug/generated/src output, I've looked at the Known Issues and spotted the following statements:
The version of the Android JDK that was used to package the Android library – Binding errors may occur if the Android library was built with a different version of JDK than the one in use by Xamarin.Android. If possible, recompile the Android library using the same version of the JDK that is used by your installation of Xamarin.Android.
Known Issues
Problem: Java Version Mismatch
Sometimes types will not be generated or unexpected crashes may occur because you are using either a newer or older version of Java compared to what the library was compiled with. R

I created a script that checked the Major version number (which corresponds to a JDK Version) of every .class file in each of the .aar files, and discovered the following:

The .aar classes themselves are built over three different versions of the JDK (Major versions 48 , 50, and 51) and the projects themselves are built over two versions (Major version 52, and 53)
48 (Java 1.4) - 191 classes (all an external library, dnsjava v2.1.9 from
50 (Java 6) - 397 classes
51 (Java 7) - 197 classes

Worse still, the Xamarin.Android app API version is 9.0 (Pie, Major 53).

  1. How strongly should I push to either get the client to recompile the source against a single JDK version, or get them to pass the source on so that I can do it?
  2. Based upon experience, is it possible that some of the top level ancestors not being visible, wont be able to be resolved without recdompiling against a common SDK?
  3. What is the common strategy to surface classes and interfaces that don't appear in api.xml, nor as C# classes in the obj/debug.generated/src output?

Kind regards!

For posterity, this is the Major to API version lookup table:

Java 1.2 uses major version 46
Java 1.3 uses major version 47
Java 1.4 uses major version 48
Java 5 uses major version 49
Java 6 uses major version 50
Java 7 uses major version 51
Java 8 uses major version 52
Java 9 uses major version 53
Java 10 uses major version 54
Java 11 uses major version 55
Sign In or Register to comment.