Hi Rony,
does javax.script discovery implementation use java.util.ServiceLoader
convention ?
If the answer is yes, then it will work out of the box.
cheers,
Rémi
On 01/12/2015 05:09 PM, Rony G. Flatscher wrote:
Hi there,
reading <http://openjdk.java.net/jeps/220 this is a question or maybe a request
for information
regarding the removal of the "extension" mechanism and what can be used instead?
There is one particular use-case that I regard to be of tremendeous importance
for the Java world,
recognizing that many Java movers and shakers do not really realize ;) : making
javax.script
scripting languages available to Java applications.
Background: I served as an expert on JSR-223 which defined javax.script
(personal background: Apache
Commons BSF scripting framework, BSF4ooRexx a JNI-bridge to the opensource
ooRexx.org scripting
language, which itself is implemented in C++, creator of the Apache OpenOffice
AOO ooRexx plugin
using the AOO Java scripting framework, teaching at a Business University among
other things
scripting, ...).
"javax.script" defines a discovery mechanism which allows a Java app to
enumerate all available
scripting engines. This way all discoverable (= installed) javax.script engines
are available to any
Java app and script/macro programmers. As a result the (end) users become able
to pick the script
language they wish to use to create macros/scripts for their Java application.
[An example would be
Apache OpenOffice (AOO), which allows using any script language, provided it is
made available via
AOOs Java based scripting framework, like BeanShell, JavaScript, ooRexx, et.al.]
Please note, that a Java application developer may not even (and need not) know
in advance which
javax.script engines will be available on a target installation, just that it
is rather easy to
enumerate the javax.script engines available to it and allow the (end) user
programmer to pick one
for creating scripts targeted at the Java application.
---
Currently (in pre-Java 9 environments), if one wishes to use javax.script
engines (e.g. in web
browsers via the Oracle browser Java plugin and in parallel in other Java
apps), one can make any
javax.script engine available by placing it in the Java "extension" directory,
which works even
then, when Java apps (like the Oracle browser Java plugin or AOO) does not
honor the CLASSPATH
environment variable.
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!
TIA,
---rony
