JNI and JVM interface

  • By: JAmiga
  • Posted on: 29 May 2012

Currently I am working on implementing the JVM interface from OpenJDK. This work is done in parallell with GNU Classpath. I.e. I will try to use OpenJDK's JVM interface in JAmiga's GNU Classpath implementation. Basically I have refactored the classpath specific code from the JAmiga binary into its own library, gnuclasspath.library (an upcoming library will of course be openjdk.library). This will then in turn get access to the JAmiga VM's exported JVM interface, in the same way OpenJDK would do it. In this work I have also found a need to implement more of the JNI standard, and also add support to native libraries for JNI_OnLoad and JNI_OnUnload. These two functions are run when a native library is loaded into JAmiga. The JNI_OnLoad function will, besides whatever it might do that's specific to the library, also initialize the JVM interface.

To summarize what is currently going on with JAmiga:

  • Native libraries export JNI_OnLoad/OnUnload
  • Implementation of JVM interface
  • Implementation of more JNI functions
  • Implementation of java-net stuff

The last point is actually what has motivated the other updates. OpenJDK's java-net uses the JVM interface for much of its functionality, and rather than implementing the methods in my own abstraction, I chose the existing one.

Native libraries export JNI_OnLoad/OnUnload

Since there still are native libraries that don't implement JNI_OnLoad/OnUnload, the library needs to be of at least version 2.x. I don't know a way to determine if an Amiga library only implements a few functions. Since the function pointers aren't set, I can't really look for NULL. Perhaps it could be solved with AmigaOS 4 interfaces, but that is not an option.

Implementation of JVM interface

I have started with a struct with function pointers to each JVM function (their basically functions with a name like JVM_Open, JVM_Close, JVM_ArrayCopy and so on). this struct gets copied to each native library when JNI_OnLoad is called. I thought of letting JAmiga registering a "jvm.library" that each native library could open if needed. I kind of like that idea. I might actually go that way in the future.

Implementation of more JNI functions

While moving GNU Classpath stuff, I found lots of places where both JVM interface functions should be used, and also where some new JNI 1.6 methods could be used, for instance the DirectByteBuffer functions are used by java-nio, and java-net.

Implementation of java-net stuff

This is how all the above started. I wanted java-net support. And kind of had it. But then I stumbled upon problem. And I got think that "why not do this, and that". So, java-net was kind of a can of worms. Or, rather, the entire JAmiga is a can of worms.

So, what does this all mean — when will we get Java on Amiga?

Sorry. But this actually doesn't change the actual state of JAmiga — the functionality is still the same as JAmiga 0.0.6. But all these actions taken are very important steps into taking JAmiga to OpenJDK support which is our only chance of getting Java 8 to Amiga, and with that JavaFX (enhanced Swing, i.e. GUI), cool lambda expression (geeky parallell stuff) and, and, all sorts of other stuff.

PS. I also added a Donate-button to the right. If you feel I deserve a danish while coding, any contribution is welcome. A +1 or comment is even more welcome! If enough of you +1 JAmiga I promise to update the blog more.