<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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).</p>
<p>Here the Java program RunScripts.java</p>
<blockquote>
<p>import javax.script.*;<br>
import java.io.*;<br>
<br>
// run script from file<br>
public class RunScripts<br>
{<br>
public static void main (String args[]) throws
ScriptException, FileNotFoundException<br>
{<br>
String fileName = args[0]; // get script's file
name<br>
String ext =
fileName.substring(fileName.lastIndexOf('.')+1);<br>
ScriptEngine se = new
ScriptEngineManager().getEngineByExtension(ext);<br>
Object result = se.eval(new FileReader(fileName)); //
run script<br>
System.exit(0);<br>
}<br>
}<br>
</p>
</blockquote>
<p>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:</p>
<blockquote>
<p>java RunScripts scriptFileName.ext<br>
</p>
</blockquote>
<p>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.</p>
<p>[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.]</p>
<p>---</p>
<p>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.<br>
</p>
<p>It is easy to exploit Java in this manner and has been done for
more than a decade. <br>
</p>
<p>---<br>
</p>
<p>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!)<br>
</p>
<p>Later even an arbitrary error will get thrown by Java,
effectively sabotaging error free and safe Java programs! <br>
:(</p>
<p>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! <br>
</p>
<p>---rony</p>
<p>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.</p>
<p>Hence please do not show that warning to (end) users.<br>
</p>
<br>
</body>
</html>