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).
