Sample 2 - using the JRE only (no configuration of the JVM) (Re: New candidate JEP: 454: Foreign Function & Memory API

[Rony G. Flatscher]

The following Java program launches scripts stored in files. It does not matter which scripting 
language one wishes to use as long as the respective scripting engine is available to the JVM. The 
jar files containing the respective scripting engine implementation can be made available via 
CLASSPATH (also via module-info).

Here the Java program RunScripts.java

    import javax.script.*;
    import java.io.*;

    // run script from file
    public class RunScripts
    {
         public static void main (String args[]) throws ScriptException, FileNotFoundException
         {
             String fileName = args[0];          // get script's file name
             String ext = fileName.substring(fileName.lastIndexOf('.')+1);
             ScriptEngine se = new ScriptEngineManager().getEngineByExtension(ext);
             Object result = se.eval(new FileReader(fileName));  // run script
             System.exit(0);
         }
    }

To take advantage of this Java program, after compiling it, on any operating system where Java/JDK 
is installed as a JRE, one merely has to issue:

    java RunScripts scriptFileName.ext

If the file extension was e.g. ".js" and e.g. the Rhino is available then any JavaScript program 
would get executed, if the file extension was ".py" and Jython was available then any Python program 
could be run, if the file extensions was ".rex" and BSFooRexx was available then any Rexx and ooRexx 
program could be executed, and so forth.

[Note: the Java scripting framework would allow for supplying arguments to such scripts which would 
be able to fetch them, and the scripts would be able to return a return value to the Java caller.]

---

As with Sample 1 it easy to exploit the functionality of the Java scripting framework in this case 
distributed with the standard Java class libraries of the JRE on all operating system platforms. It 
is easy because it is easy to launch the Java programs as the JRE is available. If the JRE gets 
updated by installing a bugfix or a newer Java/JDK all of the existing Java programs keep on running 
unchanged and uninterrupted.

It is easy to exploit Java in this manner and has been done for more than a decade.

---

But note: if the JRE gets updated to 22 then any script engine that accesses native code will all of 
a sudden, out of the blue cause that dreadful warning to the (end) user of that Java program that 
may have worked flawlessly for years and will work flawlessly in the future except that now that 
warning gets issued and later it is to be expected that even an error gets thrown! (And the authors 
of such jars implementing script engines with proven and tested native access cannot do anything 
against it!)

Later even an arbitrary error will get thrown by Java, effectively sabotaging error free and safe 
Java programs!
:(

Worse, there is nothing that any author of Java class libraries in such a use case could do to 
inhibit this terrible and damaging behaviour!

---rony

P.S.: Please realize that these are extremely stripped down samples that try to show the core of the 
problem. Java programs and Java applications that exploit the javax.script have never had a need to 
do any JVM configuration whatsoever. If such deployed Java programs and Java applications evoke that 
warning meant for "application authors" once Java/JDK 22 got installed the negative effect occurs, 
destroying the trust in Java starts to take place as Java warns from using Java programs and Java 
applications. They would not know why this all of a sudden happens and will not be able to know what 
they could do against it.

Hence please do not show that warning to (end) users.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230918/2b8d25bb/attachment-0001.htm>