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