Porting Jainja JVM

Sorry, I should have explained more clearly what jainja is on the project page:

• It is a JVM which aims to comply with official specifications at low level (support for all bytecodes) which allows the core logic of an application to work everywhere (the Java motto “Write Once Run Anywhere” / WORA is respected)
• For portability reasons (which is the main objective compared to other JVMs), only a subset of the standard libraries is supported. Developers must adapt their code to only use this subset. WORA is only respected in one direction: if the code works on Jainja then it will work on the Oracle JDK/OpenJDK but it is unlikely the other way.

Why not use the standard OpenJDK library? Because when we look at its implementation, the non-explicit presuppositions are the following (non-exhaustive list):

• The underlying platform is POSIX or Windows
• Native threads are preemptive
• The JVM has a JIT (or failing that it is launched on a very fast processor). Example: the low-level implementation of AWT/Swing relies on a rasterizer (Marlin) in Java which is inevitably slow without JIT.
• The JVM has a lot of memory available at startup (a simple hello world will load more than 400 classes with OpenJDK11)
• The JVM can generate classes on the fly. This is required by the choice to use the Invokedynamic instruction to implement lambda expressions (since Java 8) instead of implementing it with anonymous inner classes (drawbacks)
• Swing: “Desktop” provides multiple windows for a given application that can be resized by the user or application at any time (it doesn’t work this way on most mobile OSes or web)

Consequently, the different attempts to port Java to platforms other than those previously mentioned often arrive at the same decision which is to only support a subpart of the specifications:

• At the source code level like GWT (project initially developed by Google) or Android
• At the bytecode level (Android)
• At the library level: Android, GWT, TeaVM, JSweet,…

Jainja tries to find a compromise (sometimes to the detriment of performance) by supporting all bytecodes and a sufficient part of the libraries so as not to have to rewrite all the code for the GUI (MIDP, AWT, Swing, Codename One) that is to say by just making adaptations.

It is therefore unlikely that an application with a GUI developed in Swing using all the features of OpenJDK will work directly on Jainja (nor on Android, GWT, …) but it is possible with code adaptations.

In conclusion, Jainja rather targets developers who want to run their application with as little effort as possible on non-standard platforms. It is not suitable for running a complex application with a GUI out of the box.

Thank you all. Guillaume, I appreciate the explanation and how it sets expectations. Also, I found the various scripts in the Run file useful. :) Nice.

A really, really, cool project :)

Wow – just came across this – and happy to contribute. I did have a play years ago with extending Kaffe to work on RiscOS with an AWT port from UNIX land, but aborted this attempt as it was getting nowhere. I’ll take a look.