A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9?

[Rony G. Flatscher]

Hi Tim,

On 20.01.2015 02:53, Tim Boudreau wrote:
>
>     Ad "not seeing a lot of usage": probably only those take advantage of the extension mechanism who
>     have no alternative to it. So it would make sense that only a few use it, but for them it is
>     probable, that it is of high importance.
>
>
> I'll express some kudos for the removal of that.
>
> Until you've worked full-time on an application where its users have random undiagnosable bugs
> caused because some other application installed something buggy into the JDK system-wide (ancient,
> broken versions of XML parsers come to mind), you can't appreciate how horrific a mistake it was
> to ever permit this sort of thing.
One can tell from such statements, that there are quite some emotions linked to this issue. :)

Of course, everything that solves or improves the cause of such nightmares is good as long as there
are alternatives for the exploited functionality (there has been a need for it).

[I have been around for quite some time too (since Java 1.1 on OS/2) and have experienced all sorts
of "horror-because-of-configuration-problems" that BTW continue to this very day. Just today I had
to debug a configuration problem with Java 1.8 on 64-bit Windows 7 Enterprise, because the registry
entries for 32-bit apps (and 32-bit Java that was installed in addition) pointed erroneously
(despite Windows' registry virtualisation) to the 64-bit Java on that particular system, which was
used to learn about Java's 32-bit configuration (using java.lang.System's properties).]

> It was a mistake that it ever existed, probably caused by someone seeing that that was the model
> for delivering libraries for Windows in the 90s and thinking that made it an okay thing to do
> (dll-hell, anyone?).  It never was, and there are decades of evidence to support that conclusion.
Yet, Java 6 extended the extension directory scheme to allow to define directories that are
independent of any particular Java version installed. And this functionality serves its purpose at
times. However, if there is an alternative that allows solving certain configuration problems, then
that would be fine with everyone, I assume.

> If OpenOffice or something else needs a list of scripting engines, it should bundle what it needs,
> or provide a way for users to add more, and make those available.  The idea of a magic JDK that
> grows new features thanks to other applications installing stuff on the system is a recipe for
> disaster.
Probably, I did not explain clearly enough (I am not a native English speaker): the point I tried to
make was that even non-Java-applications like OpenOffice that employ Java via JNI may not honor the
CLASSPATH environment variable. As a result it is not possible to allow Java from within OpenOffice
to access javax.script engines by placing them on the CLASSPATH.

[OpenOffice itself is self-contained including the Java modules. The OpenOffice way to add Java
modules is its extension mechanism which one needs to learn and to apply.]

Probably there are other applications (Java- and non-Java-based ones) that might have a need to be
extended dynamically (with the help of the current extension mechanism), hence being interested in
what Java 9 defines as an alternative for such scenarios.

> For the applet scenario, if the server and client do their HTTP cache headers right, there is no
> practical difference between loading a java extension from disk somewhere in the JDK and using a
> previously downloaded JAR cached by the browser from disk.
This might sound like a possible solution that also could work on older Java installations (have a
need for Java 1.6 and up as commercially deployed Java applications might run with older JRE).

There is one caveat though: in the case of scripting engines that are implemented with native code
and have a JNI bridge to javax.script there is more to be done to the target system than merely
downloading a jar package or two. In such a "non-pure Java" scenario the scripting engine with the
matching Java support gets installed on the target PCs (once) anyway. Downloading jar versions from
the Internet may still cause a "dll-hell"-comparable scenario over time, this time with different
types of jars (downloaded via the net) having different dependencies on the native scripting engine
(mixing wrong versions, "dll-hell").

For these scenarios it becomes important to make the locally installed native script engine with its
companion jars directly available to the locally executing JRE (no matter whether bundled with an
app or with a system wide installed JRE).

> It really can't be overstated how bad an idea that was from day one - for stability, for
> predictable behavior, for knowing what you're running against and for security.
:)
Not making fun, but inferring that you feel *very* reliefed by the outlook that what you have
experienced as a nightmare may be over with Java 9.

Probably there are more deployments of the Java extension mechanism in the field, than assumed.
Expecting that many of those will experience the loss of this mechanism only when Java 1.9 goes GA.

---

In the case of javax.script engines: they are infrastructural and can be added or removed easily
from the JRE with the currently supported Java extension mechanism. It is easy for applications
using javax.script engines to enumerate the currently available engines at runtime and make them
available to applications (e.g. as macro languages for deploying scripts written in a particular
engine). 

Therefore I hope for a general, workable solution for the current extension mechanism in Java 1.9
that does not have the mentioned drawbacks.

---rony

P.S.: If it was possible to somehow define such jars for already installed applications that ignore
the CLASSPATH environment variable, then most such problems could be solved already.

P.P.S.: If one could rely on Java apps to have to honor the CLASSPATH environment variable one way
or another, then there would be no problem either. Maybe something crazy like automatically
searching a set, but ignored, CLASSPATH environment path, if a class cannot be found (only those
fragments that have not been searched yet).