rebooting OpenJDK mobile

[Rony G. Flatscher]

Hi Johan,

On 02.07.2019 11:47, Johan Vos wrote:
> The Apple specific restrictions are still valid: you can not compile code at runtime. Hence,
> sending Java bytecode to a running app, and have it compiled there won't work. 
> The classes need to be compiled before runtime, and part of the executable. 
> I believe that in theory, it should be possible with e.g. Zero interpreter to interpret new
> bytecode, as that is not generating new native code. 
>
> Can you elaborate on your use case so that we can see how we can handle this?

Sure: one such important area is supporting dynamic scripting languages via the Java scripting
framework (javax.script package).

As an author of one such Java scripting engine implementation for ooRexx (and serving as an expert
on the JSR-223 which came up with the specifications implemented in javax.script) that itself is not
implemented in Java but in C++. [So JNI is in the picture here as well. This particular Java script
engine implementation is called BSF4ooRexx and hosted on Sourceforge; ooRexx is now an independent
open-source project hosted on Sourceforge as well.]

There is a constant need to create dynamically Java adapter classes at runtime. One example is for
extending abstract Java classes with ooRexx, another example is implementing Java interface classes
in ooRexx, another one extending normal Java classes in ooRexx.  E.g. implementing event handlers or
lambda functions in ooRexx or extending the abstract Java class javafx.application.Application with
ooRexx.

One important application area nowadays is to use this infrastructure to create JavaFX applications
without coding in Java at all, but solely in the programming language ooRexx, which has a very easy
syntax, hence is quite easy to learn (and easy to teach) but still is very powerful (ooRexx is a
message-based, dynamic, object-oriented programming language, originally developed by IBM, now in
opensource).

Therefore the (urgent) need to remain able to dynamically create and use those adapter Java classes
at runtime! [3] and [5] are slides demonstrating how one can use ooRexx to create
JavaFX-applications; the slides in [1] explain briefly the javax.script.Engine implementation for
ooRexx; [4], [6], [2] are the accompanying articles. (All these JavaFX applications created with
ooRexx run unchanged on Windows, Linux and MacOS.)

ASM [7] and later Janino [8] have been used for this purpose for more than fifteen years! Not
supporting compiling and loading Java classes at runtime will break such (and related) support.

Please note, the need for dynamically creating and using Java classes at run time is not restricted
to these use-cases, any dynamic Java programming technique would be affected.

Also, given today's power found in practically all computer devices, including mobile devices,
interpreting Java byte code in these use-cases would be fine (the overall speed improvement would be
gained by the pre-compiled run time/application anyway)!

---rony

Links:

[1] RexxScriptEngine, slides:
<http://www.rexxla.org/events/2017/presentations/AutoJava-BSF4ooRexx-06-RexxScript.pdf>

[2] RexxScriptEngine, article:
<http://www.rexxla.org/events/2017/presentations/201704-RexxScript-Article.pdf>

[3] JavaFX for ooRexx - Creating Powerful Portable GUIs, slides:
<http://www.rexxla.org/events/2017/presentations/AutoJava-BSF4ooRexx-07-JavaFx-201711.pdf>
Note: at the end there are screenshots of an ooRexx implementation of the classic JavaFX tutorial
"address book" which gets distributed with the BSF4ooRexx package and can be studied there.

[4] JavaFX for ooRexx - Creating Powerful Portable GUIs, article:
<http://www.rexxla.org/events/2017/presentations/201711-ooRexx-JavaFX-Article.pdf>

[5] Anatomy of a GUI (Graphical User Interface) Application for Rexx Programmers, slides:
<http://www.rexxla.org/events/2018/presentations/201803-AnatomyOfGUI.pdf>

[6] Anatomy of a GUI (Graphical User Interface) Application for Rexx Programmers, article:
<http://www.rexxla.org/events/2018/presentations/201803-AnatomyOfGUI-Article.pdf>

[7] Homepage of ASM: <https://asm.ow2.io/>

[8] Homepage of Janino, noting some projects using it: <https://janino-compiler.github.io/janino/>

P.S.: I have been puzzled by Apple's restriction, which is inhibiting any form of innovation by
non-Apple software and wonder whether such a restriction would be legal in the European Union.

P.P.S.: Also, I have been thinking on improving javax.script support in the FXMLLoader class and
maybe the WebView class a little bit.



>
> On Sun, Jun 30, 2019 at 1:45 PM Rony <rony.flatscher at wu.ac.at <mailto:rony.flatscher at wu.ac.at>> wrote:
>
>     Hi Johan,
>
>     would it still be possible to compile Java classes and load them at runtime?
>
>     —-rony
>
>     Rony G. Flatscher (mobil/e)
>
>     > Am 28.06.2019 um 16:09 schrieb Johan Vos <johan.vos at gluonhq.com <mailto:johan.vos at gluonhq.com>>:
>     >
>     > Hi,
>     >
>     > After a long time, it is a good moment now to restart the public work in
>     > the OpenJDK Mobile project.
>     > In the past, we had a repository with code based on OpenJDK 9 that allows
>     > to build the class libraries (including native code) and one or more VM's,
>     > for Android and iOS.
>     >
>     > While this works, we still have the limitation on iOS where dynamic code is
>     > not allowed, hence a JIT is not an option. The Zero VM works there
>     > (interpreter mode) but is slow.
>     >
>     > Today, we can use the GraalVM AOT compiler to compile the code at build
>     > time. We can link the compiled Java code with native libraries compiled for
>     > the target OS, and create executables. Most of the VM functionality is
>     > provided by a very small set of files in SubstrateVM (linked to by GraalVM
>     > native image)
>     >
>     > We already did this for iOS, based on Java 11 (see
>     > https://github.com/johanvos/openjdk-mobile11/tree/mobile) and JavaFX 13.
>     > (see our announcement at https://gluonhq.com/java-on-ios-for-real/)  The
>     > diff to the upstream code is remarkably small.
>     >
>     > It is my goal now to use project Skara to create a synchronized fork of the
>     > OpenJDK master, and to push the changes required to build the native libs
>     > for the core libraries in there.
>     > Ultimately, it would be ideal if all required changes can go upstream.
>     >
>     > At this moment, this is iOS only, but there are no showstoppers to do this
>     > for Android as well. The architectures are pretty similar.
>     >
>     > - Johan
>