Hi Rony Your issue has been converted into a JDK issue, with your testcase attached [1]. Normally you should’ve received an e-mail at the time of this conversion, but you can check this yourself by using the internal review ID as in [2]. If you’d like to contribute a fix, see [3].
Kind regards, Anthony [1] https://bugs.openjdk.java.net/browse/JDK-8234959 [2] https://bugs.openjdk.java.net/browse/JI-9062887 [3] https://github.com/openjdk/jfx From: Rony G. Flatscher<mailto:rony.flatsc...@wu.ac.at> Sent: Wednesday, 22 January 2020 14:44 To: openjfx-dev@openjdk.java.net<mailto:openjfx-dev@openjdk.java.net> Subject: Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script Last November I submitted an appropriate bug report and mailed the testcase on November 27th per Oracle's request without hearing anything to this date. Therefore I was wondering how long such an assessment usually takes place and what to do? (Maybe it "fell off the desk" due to the end-of-year stress and Christmas vacation?) Any advice? ---rony On 21.11.2019 15:39, Rony G. Flatscher wrote: > 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
