As the zip-archive attachment got stripped, for a brief time the zip-archive can be fetched from <https://www.dropbox.com/s/l4uesrwm0iw5vb9/testcaseFXMLLoaderScriptEngines.zip?dl=0>.
---rony On 21.11.2019 15:29, Rony G. Flatscher wrote: > On 15.11.2019 16:08, Rony G. Flatscher wrote: >> On 14.11.2019 22:57, Kevin Rushforth wrote: >>> On 11/14/2019 10:12 AM, Rony G. Flatscher wrote: >>>> On 14.11.2019 16:34, Rony G. Flatscher wrote: >>>>> On 13.11.2019 19:50, Kevin Rushforth wrote: >>>>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote: >>>> ... cut ... >>>>>>> To reproduce the testcase one would need ooRexx and the Java bridge >>>>>>> BSF4ooRexx (all >>>>>>> opensource) for >>>>>>> which I could come up with a zip-archive (assuming binaries within >>>>>>> should be 64-bit) and a >>>>>>> script to >>>>>>> set up the environment either for Windows, Linux or MacOS, whatever you >>>>>>> advise. Would that be >>>>>>> o.k.? >>>>>> We prefer not to rely on third-party libraries for test cases. In any >>>>>> case we would not be able to >>>>>> use that for a regression test / unit test. >>>> If test units really seem to be important in this particular case, one >>>> possibility would be to >>>> create a minimalistic ScriptEngine implementation in pure Java just for >>>> the sole purpose to allow >>>> the creation of a test unit that is able to assert that FXMLLoader puts >>>> the ScriptEngine.ARGV and >>>> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having >>>> the ScriptEngine's eval() >>>> methods return the ScriptContext at invocation time in order to allow >>>> inspection of the Bindings. >>>> This way it would become also possible to write in addition test units >>>> that also check whether all >>>> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE >>>> Bindings. >>> Something like that seems reasonable, and would avoid a dependence on >>> Nashorn, which in addition >>> to having all the problems you mentioned, is deprecated for removal. >>> >>>> However, >>> Did you have something more to add? >> No, sorry for that. Rewrote my e-mail and had sent it too early by mistake >> and without noticing. >> >> Will study all the procedures and create a testcase to be submitted at >> <https://bugreport.java.com/> >> as per your advice (and will report back under this thread once submitted). >> The testcase would use >> an artificial ScriptEngine implementation that could be used for testunit >> testing as well. This >> might take a while due to other obligations that I will have to meet during >> the next few days. >> >> ---rony > O.K., so came up with a test case that contains an artificial script engine > implementation for > logging the eval() invocations together with the scripts to execute and the > ScriptContext > ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is > meant to be also usable > for creating script engine related test units for Java script hosts.) > > Packaged the source and binaries of that script engine as jar file that one > merely needs to put on > the CLASSPATH or add as a module. > > An updated FXMLLoader patch suggesting a fix is included as well. This > version appends the line > number to the file name if the script to be evaluated is embedded in the > fxml-file, such that in > case of an error it becomes possible to quickly find it in larger fxml files. > > With the zip-archive done I went to the Oracle Java Bug Database and just > entered a bug report at > <https://bugreport.java.com/bugreport/submit_start.do> got the internal "ID : > 9062887". > > As it was not possible to attach/upload the zip-archive at this point, I will > attach the zip-archive > (contains all sources and binaries) to this e-mail. The contained > <readme.txt> reads: > > Testcase that demonstrates that FXMLLoader does not set [1] > ScriptEngine.FILENAME and [2] ScriptEngine.ARGV entries in > ScriptContext.ENGINE_SCOPE Bindings. > > To run the test case: > > - unzip testcaseFXMLLoaderScriptEngines.zip, > > - change into "testcaseFXMLLoaderScriptEngines" subdirectory, > > - run the testcase by issuing the following command: > > - Unix: > > java -cp .:RgfPseudoScriptEngine.jar > FXMLLoaderTestCase4ScriptEngineScope > > - Windows: > > java -cp .;RgfPseudoScriptEngine.jar > FXMLLoaderTestCase4ScriptEngineScope > > FXMLLoaderTestCase4ScriptEngineScope loads "demo_01.fxml" which is a > controller > that uses the pseudo script language > rgf.scriptEngine.RgfPseudoScriptEngine, > which logs the eval() invocations with the script code and the Bindings > of the > ScriptContext. > > Comparing "demo_01.fxml" and the output of the above test case > demonstrates that > FXMLLoader does not popuplate the [3] ENGINE_SCOPE Bindings with the > filename of > the script that gets evaluated, nor does add the ARGV entry to the > ENGINE_SCOPE > Bindings in the case of events (just an entry named "event"). > > In case of errors (during development or deployment) it is not possible > therefore to point to the file (external file or the fxml-file defining > explicitly script code) in which a runtime error has occurred. > > In the case of an event callback, if ARGV was defined the script code > could > directly fetch and interact with the supplied event object argument. In > the > case that a script engine does not automatically make Bindings entry > available > as implicit variables (e.g. for scoping reasons) it becomes cumbersome > or even > impossible in some script engine implementations (if they do not provide > access > to the Bindings) to get at the event argument of the callback invocation. > > The JSR-223 specifications lists all the (reserved) ScriptEngine > constants that > are meant to be used as reserved keys for the ENGINE_SCOPE Bindings, > whenever > appropriate cf. [0] p. l50 ff. (A ScriptEngine is supposed to populate > and > maintain the ENGINE_SCOPE Bindings hence the definition of these > constants with > the class.) > > Running the above program on Windows yields the output captured and > supplied in > [4]. > > The supplied patch [5] changes FXMLLoader.java such, > > - that the ScriptEngine.FILENAME entry is always set in the ENGINE_SCOPE > Bindings. In the case that the scripts are hosted in a fxml-file that > file > path will be used together with an appended string that hints at the > location > in the fxml file from where the script has been taken for evaluation. > In the > case of event handling scripts that appended string hints at the > location in > the fxml-file where the event attribute with the script code got used. > > - and that the ScriptEngine.ARGV entry is always set in the ENGINE_SCOPE > Bindings for event callbacks using the 'event' object as the single > argument. > > Applying the patch and running the above program on Linux yields the > output > captured and supplied in [6]. > > --- > > The jar-file [7] needs merely to be put on the CLASSPATH (or MODULE_PATH > as a > proper module-info.class is included, the module name is > "rgf.scriptEngine") to > make the pseudo scripting language available and to run the supplied > testcase. > The RgfPseudoScriptEngine (script engine name and extension is "rpsl") > implementation should also make it possible to create test units for > asserting > that Java script hosts are populating the ScriptContext Bindings > according to > specifications. > > All Java classes come with their source code (the script engine service > file and > module-info.{java|class} are contained in the jar file). > > Having signed the OCA you may use all of the supplied code freely. > > If there is anything you need or that I could provide, please let me know. > > ---rony > > [0] JSR-223 specification at <https://jcp.org/en/jsr/detail?id=223>, > download > <https://jcp.org/aboutJava/communityprocess/pfd/jsr223/index.html>: > "java_scripting-1_0-fr-spec.pdf" > > [1] > > <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptEngine.html#FILENAME> > > [2] > > <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptEngine.html#ARGV> > > [3] > > <https://docs.oracle.com/en/java/javase/11/docs/api/java.scripting/javax/script/ScriptContext.html#ENGINE_SCOPE> > > [4] Output of running the testcase on Windows (Java 8): > "info/Demo_output_without_fix.txt" > > [5] FXMLLoader patch: > "info/diff_add_FILENAME_ARGV_to_FXMLLoader_preferable_20191121.txt" > > [6] Output of running the testcase after patching FXMLLoader with [5] on > Linux (OpenJDK 11.0.5): > "info/Demo_output_with_fix_and_linenumbers.txt" > > [7] Pseudo script engine implementation to be put on the CLASSPATH or > MODULE_PATH (module > name "rgf.scriptEngine"): <RgfPseudoScriptEngine.jar> > > [8] FXML test case: > > - FXMLLoaderTestCase4ScriptEngineScope.{java|class} > ... loads "demo_01.rxml" and dumps the engine and global Bindings > > - demo_01.fxml > ... FXML file using scripts in the pseudo script language [7] as > controller, > either as external or embedded scripts, including scripts for > event > handling Action and MouseClicked events > > - demo_01_bottomscript.rpsl ... serving as external script file > > - demo_01_middlescript.rpsl ... serving as external script file > > - demo_01_topscript.rpsl ... serving as external script file > > If there is anything else I can/should do, please advise. > (Being on the road in the next few days it might take me until the beginning > of next week to get back.) > > ---rony >
