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
