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