The main goals of Jainja are:
Simplicity and Maintainability (keep the code base small and modular)
Over the time, a lot of really good JVM were written.
Some are really portable if these conditions are simultaneously met for the target platform: 1) Availability of a C/C++ compiler (mostly GNU C) 2) Availability of pthread
- Sometimes the target platform doesn't provide a C compiler. For the web, it was fixed, thanks to a huge amount of work (Emscripten, Nacl and now WebAssembly)
- If pthread is not available, some of these implementations can still work by disabling threads at configure time. It works but you can't use more than one thread and a lot of libraries simply don't work
Again, it's a really huge amount of work with this potential issue: if you change your target platform, you may need to port all the platform framework/language.
A solution for a better portability : polymorphism using transpilation
Instead of porting the compilation tools to a target platform as it's done most of the time, the opposite is done: the JVM and the standard library code is translated to any language (hence to any platform) by using transpilation. The source code is written in a main language (Java) and can be converted to another one auto-magically. In a way, the main language can be seen as a meta-language.
By using the smallest possible subset of Java, we make sure that we can target all Java platforms or use simple transpilation tools to convert the code to target languages.
If transpilation solves most of the concerns, some other concepts are necessary to make the implementation small and simple.
Meta-circularity ("Do not reinvent the wheel")
The current implementation is inspired by the main idea found in meta-circular interpreters: implement a feature using the same feature in the host language. So Jainja doesn't implement by itself objects and the garbage collector: they are provided by the host language.
Pure Java libraries (Do not waste your time: "Write Once Run Anywhere")
While most JVM standard libraries implement their native part in C/C++, here most of the code is in Java. Only a thin (really-)native layer is needed for some platforms.
Green Threads ("DIY" to "Keep It Simple")
Threads are implemented in the VM itself, so native multi-threading is not required. IO are implemented by using non-blocking native calls.
Green threads are a really old concept which was used in first versions of the Sun's JVM. Sometimes "the old pipe gives the sweetest smoke"
Currently all major features of the Java 1.5 specifications are supported.
Full thread support
Standard core libraries
Codename One (previously LWUIT): fully supported
Jainja Graphical Toolkit (JAGT): a small/minimal graphical toolkit which allows to port standard UI APIs. JAGT backends are currently: AWT, GWT, MicroBackend