Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

Hi Kevin,

On 29.01.2020 13:24, Kevin Rushforth wrote:
> The RFE you filed is now available here:
>
> https://bugs.openjdk.java.net/browse/JDK-8238080

thank you very much!

Cheers

---rony

P.S.: Have not received any automatic notification e-mail so far.

Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Kevin Rushforth]

Hi Rony,

The RFE you filed is now available here:

https://bugs.openjdk.java.net/browse/JDK-8238080

-- Kevin


On 1/25/2020 6:32 AM, Rony G. Flatscher wrote:

Hi Kevin,

On 24.01.2020 16:50, Kevin Rushforth wrote:

This bug was transferred to the JDK project on 28-Nov-2019. I don't know why 
you didn't get an
email at that time, but I will inquire of the team who processes incoming bugs.

Also, I'll keep an eye out for the RFE you filed today, and let you know when 
it is transferred in
case there is still a problem with the notification.

thank you very much!

---rony



On 1/22/2020 9:52 AM, Rony G. Flatscher wrote:

Hi Anthony,

On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:

Your issue has been converted into a JDK issue, with your testcase attached [1].

Thank you *very* much for this information!


Normally you should’ve received an e-mail at the time of this conversion,

Just searched all my e-mail folders and could not find it (looking for 
"FXMLLoader" in the subject
of e-mails as the bug title contains that word) but could not find a matching 
e-mail for whatever
reasons.


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 


Thank you also for these links (and I learned something new on how to check for 
it using the
internal review id with your [2], thanks a lot for this hint as well)!

Will go back and study all the necessary procedures (forgot a lot since reading 
them the last time)
and will try to contribute the fix in the proper way but it may take me a 
little while (currently
quite busy around here).

---

Maybe one more question: there would be an optimization possible by compiling 
scripts for script
engines that have the javax.script.Compilable interface implemented and use the 
compiled version to
execute/evaluate the scripts (may be helpful for event handler code e.g. for 
onMouseMove event
handlers). Can the fix include such an optimization or should there be a 
separate discussion/RFE for
it beforehand? (Adding this would be trivial in the context of the fix, however 
the bug description
would not hint at such an optimization.)

---rony

Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

Hi Kevin,

On 24.01.2020 16:50, Kevin Rushforth wrote:
> This bug was transferred to the JDK project on 28-Nov-2019. I don't know why 
> you didn't get an
> email at that time, but I will inquire of the team who processes incoming 
> bugs.
>
> Also, I'll keep an eye out for the RFE you filed today, and let you know when 
> it is transferred in
> case there is still a problem with the notification.

thank you very much!

---rony


>
> On 1/22/2020 9:52 AM, Rony G. Flatscher wrote:
>> Hi Anthony,
>>
>> On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
>>> Your issue has been converted into a JDK issue, with your testcase attached 
>>> [1].
>> Thank you *very* much for this information!
>>
>>> Normally you should’ve received an e-mail at the time of this conversion,
>> Just searched all my e-mail folders and could not find it (looking for 
>> "FXMLLoader" in the subject
>> of e-mails as the bug title contains that word) but could not find a 
>> matching e-mail for whatever
>> reasons.
>>
>>> 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 
>>>
>> Thank you also for these links (and I learned something new on how to check 
>> for it using the
>> internal review id with your [2], thanks a lot for this hint as well)!
>>
>> Will go back and study all the necessary procedures (forgot a lot since 
>> reading them the last time)
>> and will try to contribute the fix in the proper way but it may take me a 
>> little while (currently
>> quite busy around here).
>>
>> ---
>>
>> Maybe one more question: there would be an optimization possible by 
>> compiling scripts for script
>> engines that have the javax.script.Compilable interface implemented and use 
>> the compiled version to
>> execute/evaluate the scripts (may be helpful for event handler code e.g. for 
>> onMouseMove event
>> handlers). Can the fix include such an optimization or should there be a 
>> separate discussion/RFE for
>> it beforehand? (Adding this would be trivial in the context of the fix, 
>> however the bug description
>> would not hint at such an optimization.)
>>
>> ---rony

Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Kevin Rushforth]

Hi Rony,

This bug was transferred to the JDK project on 28-Nov-2019. I don't know 
why you didn't get an email at that time, but I will inquire of the team 
who processes incoming bugs.


Also, I'll keep an eye out for the RFE you filed today, and let you know 
when it is transferred in case there is still a problem with the 
notification.


-- Kevin


On 1/22/2020 9:52 AM, Rony G. Flatscher wrote:

Hi Anthony,

On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:

Your issue has been converted into a JDK issue, with your testcase attached [1].

Thank you *very* much for this information!


Normally you should’ve received an e-mail at the time of this conversion,

Just searched all my e-mail folders and could not find it (looking for 
"FXMLLoader" in the subject
of e-mails as the bug title contains that word) but could not find a matching 
e-mail for whatever
reasons.


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 


Thank you also for these links (and I learned something new on how to check for 
it using the
internal review id with your [2], thanks a lot for this hint as well)!

Will go back and study all the necessary procedures (forgot a lot since reading 
them the last time)
and will try to contribute the fix in the proper way but it may take me a 
little while (currently
quite busy around here).

---

Maybe one more question: there would be an optimization possible by compiling 
scripts for script
engines that have the javax.script.Compilable interface implemented and use the 
compiled version to
execute/evaluate the scripts (may be helpful for event handler code e.g. for 
onMouseMove event
handlers). Can the fix include such an optimization or should there be a 
separate discussion/RFE for
it beforehand? (Adding this would be trivial in the context of the fix, however 
the bug description
would not hint at such an optimization.)

---rony

Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

On 23.01.2020 18:09, Anthony Vanelverdinghe wrote:
> On 22/01/2020 18:52, Rony G. Flatscher wrote:
... cut ...
>> Maybe one more question: there would be an optimization possible by 
>> compiling scripts for script
>> engines that have the javax.script.Compilable interface implemented and use 
>> the compiled version
>> to execute/evaluate the scripts (may be helpful for event handler code e.g. 
>> for onMouseMove event
>> handlers). Can the fix include such an optimization or should there be a 
>> separate discussion/RFE
>> for it beforehand? (Adding this would be trivial in the context of the fix, 
>> however the bug
>> description would not hint at such an optimization.)
> In my opinion, this should be filed as a separate issue, since it's unrelated 
> to the current issue
> and is an enhancement, rather than a bug.

Thank you very much Anthony, will do.

---rony

Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Anthony Vanelverdinghe]

On 22/01/2020 18:52, Rony G. Flatscher wrote:

Hi Anthony,

On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
Your issue has been converted into a JDK issue, with your testcase 
attached [1].


Thank you *very* much for this information!

Normally you should’ve received an e-mail at the time of this 
conversion,


Just searched all my e-mail folders and could not find it (looking for 
"FXMLLoader" in the subject of e-mails as the bug title contains that 
word) but could not find a matching e-mail for whatever reasons.


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 

Thank you also for these links (and I learned something new on how to 
check for it using the internal review id with your [2], thanks a lot 
for this hint as well)!


Will go back and study all the necessary procedures (forgot a lot 
since reading them the last time) and will try to contribute the fix 
in the proper way but it may take me a little while (currently quite 
busy around here).


---

Maybe one more question: there would be an optimization possible by 
compiling scripts for script engines that have the 
javax.script.Compilable interface implemented and use the compiled 
version to execute/evaluate the scripts (may be helpful for event 
handler code e.g. for onMouseMove event handlers). Can the fix include 
such an optimization or should there be a separate discussion/RFE for 
it beforehand? (Adding this would be trivial in the context of the 
fix, however the bug description would not hint at such an optimization.)


In my opinion, this should be filed as a separate issue, since it's 
unrelated to the current issue and is an enhancement, rather than a bug.


---rony



Kind regards, Anthony

Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

Hi Anthony,

On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
> Your issue has been converted into a JDK issue, with your testcase attached 
> [1].

Thank you *very* much for this information!

> Normally you should’ve received an e-mail at the time of this conversion,

Just searched all my e-mail folders and could not find it (looking for 
"FXMLLoader" in the subject
of e-mails as the bug title contains that word) but could not find a matching 
e-mail for whatever
reasons.

> 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 
>
Thank you also for these links (and I learned something new on how to check for 
it using the
internal review id with your [2], thanks a lot for this hint as well)!

Will go back and study all the necessary procedures (forgot a lot since reading 
them the last time)
and will try to contribute the fix in the proper way but it may take me a 
little while (currently
quite busy around here).

---

Maybe one more question: there would be an optimization possible by compiling 
scripts for script
engines that have the javax.script.Compilable interface implemented and use the 
compiled version to
execute/evaluate the scripts (may be helpful for event handler code e.g. for 
onMouseMove event
handlers). Can the fix include such an optimization or should there be a 
separate discussion/RFE for
it beforehand? (Adding this would be trivial in the context of the fix, however 
the bug description
would not hint at such an optimization.)

---rony

RE: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Anthony Vanelverdinghe]

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 th

Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

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
> .
>
> ---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 
>>> 
>>> 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
>>  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 
>>  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 

Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

As the zip-archive attachment got stripped, for a brief time the zip-archive 
can be fetched from
.

---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 
>> 
>> 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
>  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 
>  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