RFE/Suggestions to improve JavaFX deployment of javax.script (part of Java) engines and script code

[Rony G. Flatscher]

For scripting languages that possess javax.script (part of Java since Java 1.6/6!) implementations
the JavaFX infrastructure is of a great attractivity.

JavaFX would allow script programmers for creating platform independent GUIs to take fully advantage
for their own purposes, i.e. "surfing on Java" to get at a modern, maintained, up-to-date GUIs in an
open manner!

Of course, scripting support in form of Nashorn/ECMAScript/Javascript is on board of modern Java
distributions, however there are many more javax.script scripting languages available. (In my case I
am very interested in ooRexx, the opensource version of IBM's Open Object Rexx, which is a very easy
to learn, yet powerful OO language, and am the author of the JSR-223 implementation of ooRexx, which
will be included in the next distribution of BSF4ooRexx which is a bridge between ooRexx and Java.)

While evaluating the possibilities (for non-informatic students) of taking advantage of the JavaFX
infrastructure, I have been experimenting and exploring the JavaFX infrastructure. Being acquainted
with the details of javax.script/JSR223 it has been very interesting to learn how javax.script is
being deployed on JavaFX. Basically, using SceneBuilder and then manually editing the FXML file it
becomes possible to run any scripting programs from (I assume FXMLLoader), given that there is a
processing instruction like e.g.

    <?language rexx?>

or

    <?language Nashorn?>

which causes FXMLLoader to load the denoted scripting language by name. As a result all script code,
be it defined in fx:script elements with a source attribute pointing to the file containing the
script code or any code supplied in attributes like "onAction" will be executed with this denoted
scripting engine.

This is it. Nothing else is currently available. Not even employing javax.script programming
languages in the context of a WebView/WebEngine, although HTML defines a "type" attribute for the
"script" element!

E.g, it is not possible to employ more than one script language for the same document, although this
is plain easy! Or, it is not possible to have script controllers defined (only Java controllers) in
SceneBuilder. Or it is not possible to use javafxpackager to create a jar-file with pure
javax.script code and JavaFX resources, as there is no support to denote a script to be used as the
"main class".

---

As this is the JavaFX developer list, I would like to propose in this e-mail very few and (really!
:) ) easy to implement enhancements that immediately would increase the usability and the
attractiveness of JavaFX for script writers. If there is an official tracker infrastructure where I
could post at least the simple enhancements, please advise!

---

 1. Suggestion # 1: wherever script code can be denoted, allow a "type" attribute with the mime type
    value of the javax.script engine to be used to execute the script code. Whenever such a "type"
    attribute is found, one can load the respective javax.script engine by merely using
    javafx.script.ScriptManager.getEngineByMimeType(mimeType) and then have it execute the script code.

    FXML candidates are the fx:script element itself as well as all attributes (like "onAction")
    that allow to denote script code. But also in HTML 5 (WebView/WebEngine) the script element and
    its "type" attribute (cf. <https://www.w3.org/TR/html5/scripting-1.html>).

      * Examples in FXML-documents:

        <fx:script source="myProgram.js" type="text/javascript" /> <fx:script source="myProgram.rex"
        type="text/x-rexx-java" />

      * Example in any fx-elements that have attributes that allow code:

        <Button fx:id="button" layoutX="170.0" layoutY="89.0" onAction= "use arg slotDir /* always
        supplied by BSF4ooRexx as the last argument */ ; call klickButtonAction slotDir /* now
        process the event, pass on slotDir */ ;" type="text/x-rexx-java" text="Click Me!"
        textFill="GREEN" />

 2. Suggestion # 2: whenever (probably FXMLLoader, WebEngine) execute javax.script code, then please
    add the following entries to javax.script.ScriptContext.LOCAL_SCOPE javax.script.Bindings:

     1. if the "source" attribute (script-element in HTML 5, fx:script-element in FXML) denotes a
        file name, then use the key javax.script.Engine.FILENAME and store the value of "source" in
        the LOCAL_SCOPE Bindings. The scripting engine implementation is then able to supply that
        name to the script program (e.g. in the case of a runtime error, or for debugging purposes),
        which currently is not possible.

     2. if arguments are to be passed to the script code, then create a Java array object with the
        arguments, use the key javax.script.Engine.ARGV and store the Java array with it. The
        scripting engine implementation is supposed to pass on these arguments in the scripting
        language's format, which currently is not possible.

As you can see, these are very few suggestions, but for javax.script language programmers (no matter
which languages they use and mix) they immediately improve the usability of JavaFX tremendeously!

It would be great, if someone would be able and willing to implement these little suggestions
(probably in the FXMLLoader and WebEngine classes). If there is anything I could do to help, please
let me know (also, if anyone can point me to a formal way of submitting these requests for
enhancements to a JavaFX-tracker related system, I would appreciate it).

---rony

P.S.: It may be the case that the original javax.script developer(s) in JavaFX have departed and no
one else has a working knowledge of javax.script. Even if that would be the case the above
suggestions would be still very easy to implement for any professional Java programmer! In case
there would be javax.script related questions that I can answer (I served as an expert on JSR-223
that defined the javax.script framework), I would be more than happy to do so.

P.P.S.: If anyone can point me at the trackers for the Java development kit's "jrunscript.exe" (can
only run Nashorn scripts, running other script engines causes errors despite documenting, that that
should be possible) and to the Nashorn bug tracker (its script factory creates output statements
with syntax errors that Nashorn throws up upon), I would file the found bugs there.