"Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script
Rony G. Flatscher
Rony.Flatscher at wu.ac.at
Wed Jan 22 13:44:01 UTC 2020
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
More information about the openjfx-dev
mailing list