Hi Alan, On 16.01.2015 16:39, Alan Bateman wrote: > On 12/01/2015 16:09, Rony G. Flatscher wrote: >> : >> >> Now, having learned that JDK 9 will remove the "extension" mechanism, I am >> very interested in >> learning what alternatives are discussed, planned for Java 9 to enable this >> particular important >> use-case: making javax.script engines (packaged as jars) available to any >> Java app! >> >> > Yes, the extension mechanism and specifically the discovery of installed > optional packages has > been removed in JDK 9. In general then we haven't seen a lot of usage of this > mechanism in a long > time (it's problematic when upgrading or switching JDKs for example). Yes, that has been probably the reason, why starting with Java 6 a version independent ext-directory got defined (cf. <http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/spec.html>).
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. (Speculation: I would also expect that many of those will only realize the missing of the extension mechanism, once Java 9 gets GA and is planned to be deployed. The alternative for those affected in such a scenario would be to stick to their older Java deployments, if no alternative to the extension mechanism becomes availabel.) > For standalone applications then you can put the service provider JARs (in > this this case a > scripting engine) on the class path and it should just work the same as if > you had copied it into > the extensions directory. The only difference might be if you are running > with a security manager > then you might have to configure the security policy whereas in JDK 8 and > older then you might > have replied on it getting AllPermission (this is something that is also > changed in JDK 9, code > loaded by the extension class loader does not get AllPermission by default > now). This works only, if the application honors the CLASSPATH environment variable or if it becomes possible for oneself to supply the classpath information upon startup of the application. Unfortunately, this is not always the case/possible. E.g OpenOffice starts from native code and uses JNI to interface with Java using its own classloader that ignores the CLASSPATH envrionment variable. > The applet scenario that you bring up is interesting in that it assumes that > the users of the > applet have copied the scripting engine into their ext directory. In this concrete example the scripting engine (ooRexx) is not written in Java, but in C++. The support for ooRexx for Java gets installed via the BSF4ooRexx package, such that it is feasible to supply the scripting jar to the extension directory once and have all Java apps, including the Java plugin, access that script engine thereafter, without any additional configuration needs. > That is, I think that is what you mean rather than JAR packaged applets > triggering the download of > optional packages. I wonder if you've tried creating the applet with JNLP and > putting a reference > to the scripting engine in the resources section? Will look into this for this particular scenario (making scripting engines accessible via Java plugin) as one can use the Java plugin to download resources. However, preliminary experiments with the Java plugin (quite a while ago, then deciding to place the script jar simply into an extension directory which solved the problem for all versions of Java) where everything packaged in a jar was quite cumbersome and caused nightmare in configuration and resource overhead, removing also quite soem flexibility. Having the Java plugin in place and access to javax.script jars from it (without any need on the user side for configuration), would solve the problem, if the Java plugin would cater for that (it also would make the Java plugin interesting for many scripting language aficionados, if all javax.script languages could be used for scripting x|html in lieu of JavaScript, just by setting the language attribute on the script tag; the Java plugin could probably allow for such a functionality). > In any case, once JDK 9 is further along then we expect to have support for > runtime images that > are built by linking a set of module so that might be an alternative approach > to having a runtime > image with the scripting engines available. This sounds very interesting, hoping that it becomes possible with it to define for certain applications (in this particular important case, the Java plugin for browsers) the modules that should be made available to them. (Pure speculation, expecting that an installation program becomes able to check out the Java version and whether certain applications are installed, configuring those applications to get access to the installed jars/modules, if running under Java 9 or higher.) Where would one be able to learn (about and experiment with) what you are creating/thinking here as a replacement? Maybe there are some blogs sketching the ideas, possibilities? ---rony
