Scenario 3, OpenOffice/LibreOffice (Re: Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

Tue Sep 5 11:55:41 UTC 2023

On 05.09.2023 13:17, Ron Pressler wrote:
>> On 5 Sep 2023, at 11:03, Rony G. Flatscher <Rony.Flatscher at wu.ac.at> wrote:
>>
>> OpenOffice and its fork LibreOffice are original C++ applications.
>>
>> The German company Star created a portable C++ framework in order to become able to create their end-user tools (word processor, later spreadsheet etc.). It got bought by Sun which ordered the team to create Java APIs for the package. AOO/LO therefore have a need to interact with the JRE (the Java/OpenJDK installation).
>>
>> Among other things components in Java can be created, the scripting framework is implemented in Java (it predates the javax.script package).
>>
>> There is an ooRexx implementation for the AOO/LO Java scripting framework such that students become able to also create programs and take advantage of that infrastructure in addition. Here slides that teach the business administration students programming AOO/LO: <https://wi.wu.ac.at/rgf/wu/lehre/autojava/material/foils/240_AutoJava_AOO_LO_V03.pdf>.
>>
>> There is no "Java application author" that would be able to control that "easy" flag.
>>
>> If the user of AOO/LO gets to see that warning it would be a message that in effect Java/OpenJDK is not safe as Java/OpenJDK gives a warning about its use and if an error gets eventually thrown …
> Thank you!
>
> None of these use cases will require the user of the application to see any warning messages or configure the Java runtime. Even when a shared runtime is used (what you insist on calling a JRE)

See, there has been no change among the Java versions regarding the classic JRE infrastructure being 
made available. It is automatically available when OpenJDK gets installed. Just because there is no 
separate installation package anymore (and the Oracle jnlp infrastructure not available) does not 
change that technical infrastructure in any way.

The reason why using explicitly the technical term JRE is the attempt to communicate that 
Java/OpenJDK can be used as an incredible valuable (ported) class library that non-Java programs and 
applications can take advantage of. It seems that in this group this is not seen, realized as much 
as I had thought.

> the application needs to create an instance of the JVM somehow. I believe that in most of these situations it uses something called the JNI Invocation API, which has its own section in the JEP. When they create an internal instance of the JVM, they must also configure it, and they can configure it to disable the warning. The author of such applications is the direct user of Java, and they still have full control.

The problem is to a) make them aware and b) why incurring that burden on them at all as it does add 
nothing useful for them other than inhibiting being eventually killed by a new version of Java/OpenJDK?

All of the current AOO/LO installations are not aware of this situation and have also not the 
knowledge of that magic flag. Users may update versions of AOO/LO to Java/OpenJDK versions that 
issue the warning and maybe later even to versions that would create errors.

> I’ve also looked at some other material of yours where something called NetRexx is used. In that case, too, users of NetRexx will not need to see any warning or provide any flag because the interpreter is an executable JAR. As the JEP says, the executable JAR can disable the warning with no further action from the user.

NetRexx is the very first JVM language there was and is being used for development of Java 
applications, cf. <https://www.netrexx.org/>.

NetRexx got created by the original author of Rexx, Mike F. Cowlishaw, who got involved in Java when 
IBM assessed it for and eventually got included into OS/2. With that knowledge he devised a JVM 
language that needed 1/3 less tokens than the equivalent Java programs, quite some achievement. The 
non-profit SIG "Rexx Language Association (RexxLA)" has become the owner of NetRexx and has been 
developing it constantly and also publishes it as open-source from time to time. (NetRexx also 
supplies a powerful package making CMS pipelines available, cf. 
<https://en.wikipedia.org/wiki/CMS_Pipelines>!)

---

However, the samples I posted are not NetRexx samples, but "open object Rexx (ooRexx)" samples.

ooRexx was originally created by IBM as an object-oriented successor to Rexx, first released on OS/2 
Warp and then Windows (as a paid product making money in the transition phase from OS/2 to Windows), 
later handed over to RexxLA for further maintenance and open-sourcing it.

Unlike NetRexx, ooRexx is implemented in C++ hence a need for JNI to have a bi-directional bridge 
between ooRexx and Java. Among other things it is possible to implement abstract methods as ooRexx 
methods and be called back by Java transparently (allowing for e.g. Java event handlers implemented 
in ooRexx). It is a dynamic and dynamically typed language that incorporates the message paradigm of 
Smalltalk (c.f. Alan Kay's statement on the message paradigm in 
<https://en.wikipedia.org/wiki/Alan_Kay> where he states: 'I'm sorry that I long ago coined the term 
"objects" for this topic because it gets many people to focus on the lesser idea. The big idea is 
"messaging".).

To make a long story short: experimenting with different programming languages it has turned out 
that the language one chooses for teaching novices programming is a critical success factor and 
ooRexx (testing also VBA, Java and other languages) allows for saving a lot of time explaining 
syntax and programming language idiosyncracies compared with other programming languages. The 
message paradigm at first appears to be difficult for trained programmers but makes it easy for 
novices to create and interact with objects.

ooRexx gets used to successfully teach novices (business administration students) programming such 
that after only two (sic!) months they become able to program MS Office components, MS Excel, MS 
Word and/or MS Powerpoint, and then learn to interact and to exploit Java classes from the 
available, installed JRE/OpenJDK, among other things they learn to create client-/server programs, 
but also to program OpenOffice/LibreOffice (I posted the link to those slides) in a platform 
independent manner, creating GUIs with awt/swing and at the end with JavaFX and much more.

Some of these students have come up with small applications in ooRexx of their own where they 
exploit e.g. JavaFX to allow their parents in their offices to easily use these. Others keep on 
using ooRexx and the Java bridge for their purposes or deploy it in companies to take advantage of 
that powerful infrastructure.

These persons know nothing about the Java module system and JNI/FFM, nor the various switches one 
can use to configure a JVM and the like. If they all of a sudden get to see warnings from 
Java/OpenJDK then I expect, that they - or/and the users of their ooRexx scripts or little ooRexx 
applications - get afraid and are not able to understand what happens all of a sudden and why, such 
that they will get unsettled.

> Does that address your concerns?

No, because the warning (and the consequences to be expected later) gets addressed to the wrong 
people, users in these scenarios. If the warning that is intended to address Java application 
authors is shown to these only, then the concern would vanish immediately. :)

---rony