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
Sent: Wednesday, 22 January 2020 14:44
To: 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
> .
>
> ---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
>> 

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 

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

[Rony G. Flatscher]

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

Re: Ad NashornScriptEngine (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

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

Re: Ad NashornScriptEngine (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Kevin Rushforth]

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?

-- Kevin

Re: Ad NashornScriptEngine (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

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.

However,

Correct diff (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

Just for the record: attached the wrong diff, so attaching the correct one to 
this posting. Sorry
for the confusion.

---rony


On 13.11.2019 15:14, Rony G. Flatscher wrote:
> Hmm, not getting any feedback so far, so wondering if there are currently any 
> Java developers who
> take advantage of the ability of FXMLLoader to have FXML controllers 
> implemented in any of the Java
> javax.script languages?
>
> For those, who use scripting languages for FXML controllers the request that 
> FXMLLoader adds both
> entries, ScriptEngine.FILENAME (for debugging, logging) and ScriptEngine.ARGV 
> () (for making the
> event object available directly as an argument) into the engine Bindings, 
> should be quite helpful
> while developing and running the scripts.
>
> [Personally I am using the scripting engine ooRexx successfully for teaching 
> oo programming from
> scratch to JavaFX in a single semester (four hour lecture, eight ECTS) at a 
> Business Administration
> university. So these two missing features in the current FXMLLoader support 
> for FXML controllers
> would help tremendously, especially in case of coding errors as currently it 
> is not clear from which
> file the script that has an error comes from, making it extremely cumbersome 
> and time consuming in
> JavaFX applications that use multiple and complex FXML files.]
>
> Therefore I would kindly ask interested committers for mentoring the proposed 
> changes. Enclosed
> please find a simpler version of the patch that adds these missing features 
> to the ENGINE_SCOPE
> Bindings in the three locations where ScriptEngine.eval() gets invoked (it ).
>
> To comment this simple patch, maybe I should add a few remarks such that the 
> context becomes clear:
>
>   * invoking a script via ScriptEngine.eval() will always be accompanied with 
> a ScriptContext that
> usually maintains two Bindings (Maps):
>
>   o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. for putting 
> the FXML elements that
> have an fx:id attribute defined, such that scripts can get access to 
> them, independent of a
> particular ScriptEngine) which can also be used for sharing values 
> among different script
> invocations,
>
>   o one, ENGINE_SCOPE Bindings, usually used for individual invocations.
>
>   * while a FXML file gets processed sequentially by the FXMLLoader elements 
> in the form of
> "" will cause invoking the 
> ScriptEngine.eval(Reader): this
> patch fetches the ENGINE_SCOPE Bindings and puts the value 
> "someScript.ext" with the key
> ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public class 
> FXMLLoader" and "@@
> -1582,6 +1585,8 @@ public class FXMLLoader" in the patch),
>
>   * if an event handler gets defined (e.g. with the event attribute 
> " onAction="someScript">") the FXMLLoader creates a ScriptEventHandler and 
> stores "someScript" and
> the ScriptEngine for executing that script whenever the event fires.
>
>   o When an event fires, the current implementation creates a copy of the 
> current ENGINE_SCOPE
> Bindings from the ScriptEngine's ScriptContext, adds its entries to 
> it after saving the
> entry "event" with the ActionEvent object in it. It then changes the 
> ScriptEngine's current
> ScriptContext such that it now uses the new copy of the Bindings as 
> its ENGINE_SCOPE
> Bindings, runs the script using eval() and then restores the 
> ScriptContext ENGINE_SCOPE
> Bindings.
>
>   o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public class 
> FXMLLoader") instead will
> create a copy of the ENGINE_SCOPE Bindings only once at creation time 
> (and puts the
> appropriate ScriptEngine.FILENAME into it using the name of the FXML 
> file that defines the
> event script attribute) and will reuse that Bindings each time the 
> handler gets invoked,
> after putting the actual "event" object and the respective 
> ScriptEngine.ARGV entry into it.
> Using ScriptEngine.eval(String,Bindings) will use the supplied 
> Bindings as the ENGINE_SCOPE
> Bindings for this invocation only, such that no restore is necessary 
> upon return.
>
> As only entries get added to the engine Bindings that have not been used by 
> FXMLLoader this simple
> patch should not affect existing scripts. The patch has been tested and works.
>
> Maybe it helps the cause for applying this patch, if I point out that I have 
> been active in a number
> of opensource projects, including Apache's BSF which led to my participation 
> as an expert in JSR-223
> which originally defined the javax.script framework introduced with Java 6 
> (also authored a complete
> ScriptEngine implementation with both, the javax.script.Compilable and the 
> javax.script.Invocable
> interfaces).
>
> So looking for interested committers who would be willing to mentor this 
> patch. Please advise.
>
> ---rony
>
>
>
> On 

Ad NashornScriptEngine (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

On 13.11.2019 19:50, Kevin Rushforth wrote:
>
> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote:
>> Will come up with a short reproducible testcase in ooRexx with brief 
>> comments such that the testcase
>> could be understood without the runtime (ooRexx reads almost like 
>> pseudo-code).
>>
>> 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. 

Yes, this is understandable.

> How hard to you think it would be to use NashornScriptEngine for a test case?

Probably impossible. Have researched NashornScriptEngine a little bit for a 
couple of hours now in
order to assess it with respect to writing a testcase to demonstrate the 
problem.

According to [1] the implementation has some Nashorn specific uses with respect 
to the ENGINE_SCOPE
Bindings like: 

- "... The default context's ENGINE_SCOPE is a wrapped instance of ECMAScript 
"global" object -
which is the "this" in top level script expressions. ..."

- "...  Please note that the context's GLOBAL_SCOPE Bindings and nashorn global 
object are
different. Nashorn's global object is associated with ENGINE_SCOPE and not with 
GLOBAL_SCOPE.
GLOBAL_SCOPE object of default script context is a javax.script.SimpleBindings 
instance. ..."

- "... If you create a new ScriptContext object and use it to evaluate scripts, 
then ENGINE_SCOPE of
that context has to be associated with a nashorn Global object somehow - or 
else script execution is
not possible with that context - this is because evaluated script expects 
standard ECMAScript global
builtins always. ..."

- "... But, user can supply any ScriptContext implementation containing any 
Bindings object as
ENGINE_SCOPE, nashorn engine cannot always assume ENGINE_SCOPE Bindings to be 
backed by a nashorn
Global instance. Nashorn engine checks if ENGINE_SCOPE of the ScriptContext is 
backed by a Nashorn
Global object or not. If not, it creates a fresh Bindings backed by a nashorn 
Global instance and
associates the same with the ENGINE_SCOPE that the user provided. ..."

- "... Limitations/Known issues / While nashorn attempts to give a seamless 
illusion of
ScriptObjectMirrors and JSObjects, not every operation and script API (JSON, 
Array, Function's
properties/functions) treats ScriptObjectMirror and 
jdk.nashorn.internal.runtime.ScriptObject
uniformly. There are places where ScriptObjects work as expected but if you 
pass ScriptObjectMirror
or your own JSObject implementation, it won't work as expected. ..."

[2] states: "Summary: Nashorn uses javax.script.filename uses as "source name" 
of the generated
class *only* for engine.eval calls. For "load", it uses the  URL/file name of 
the loaded script as
"source name". As for  javax.script.filename variable, Nashorn never sets - 
only uses it."

In addition [3] indicates that scripts themselves should not get access to 
ScriptEngine.FILENAME.
Indeed, adding the entry ScriptEngine.FILENAME to the NashornScriptEngine 
supplied ENGINE_SCOPE
Bindings (which will be of type "jdk.nashorn.api.scripting.ScriptObjectMirror") 
will not leave that
entry in the Bindings.

Also, invoking a Javascript script stored in a file via ScriptEngine.eval() 
does not make the
arguments (entry ScriptEngine.ARGV) available to the invoked Javascript script 
(i.e.
"arguments.length" will return 0), e.g. in the following testscript.js:

   print( "hi, this is from 'testargs.js', arguments.length="+arguments.length);
   print( "arguments.length: " + arguments.length );
   print( "---")
   func1 ( "uno", "deux", 3);

   function func1(a, b, c) {
       print( "--> func1(a, b, c) - arguments.length: " + arguments.length );
       print( "\ta: "+ a + " / arguments[0]: " + arguments[0] );
       print( "\tb: "+ b + " / arguments[1]: " + arguments[1] );
       print( "\tc: "+ c + " / arguments[2]: " + arguments[2] );
   }

Doing a ScriptEngine.eval() with the ENGINE_SCOPE Bindings possessing the 
argument entry by the name
of ScriptEngine.ARGV will yield the following output in this case:

   hi, this is from 'testargs.js', arguments.length=0
   arguments.length: 0
   ---
   --> func1(a, b, c) - arguments.length: 3
       a: uno / arguments[0]: uno
       b: deux / arguments[1]: deux
       c: 3 / arguments[2]: 3

[1] Sundararajan A., "Nashorn jsr223 engine notes":


[2] Sundararajan A., "Nashorn, javax.script.filename, and load()":


[3] "JDK-8050432 : javax.script.filename variable should not be enumerable with 
nashorn 

Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Kevin Rushforth]

On 11/13/2019 9:42 AM, Rony G. Flatscher wrote:
Will come up with a short reproducible testcase in ooRexx with brief 
comments such that the testcase

could be understood without the runtime (ooRexx reads almost like pseudo-code).

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. 
How hard to you think it would be to use NashornScriptEngine for a test 
case?


-- Kevin

Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

On 13.11.2019 16:53, Kevin Rushforth wrote:
> Actually, in this case, sending an email to this list is the right way to 
> start this discussion. I
> had meant to reply last week, but was out of town (at Devoxx), and busy with 
> other things.
>
> Before we take a look at a patch that implements what you propose to change, 
> we need a little more
> information about what problems are being caused by the current behavior. Do 
> you have a test
> program that isn't working correctly? Since this proposed fix changes visible 
> behavior, we also
> need to consider whether there are any compatibility or documentation 
> implications.
>
> The next step would be to file a bug at bugreport.java.com [1]. The bug 
> report should include a
> test case that demonstrates the problem. Also, if you haven't already done 
> so, please read the
> CONTRIBUTING [2] guidelines.
>
> Before a pull request, we will need a bug report with a standalone 
> reproducible test case,
> submitted at https://bugreport.java.com/
>  -- ideally a test case that could be turned into an automated test.

Thank you very much, indeed!

Will come up with a short reproducible testcase in ooRexx with brief comments 
such that the testcase
could be understood without the runtime (ooRexx reads almost like pseudo-code).

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

---rony

Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Kevin Rushforth]

Actually, in this case, sending an email to this list is the right way 
to start this discussion. I had meant to reply last week, but was out of 
town (at Devoxx), and busy with other things.


Before we take a look at a patch that implements what you propose to 
change, we need a little more information about what problems are being 
caused by the current behavior. Do you have a test program that isn't 
working correctly? Since this proposed fix changes visible behavior, we 
also need to consider whether there are any compatibility or 
documentation implications.


The next step would be to file a bug at bugreport.java.com [1]. The bug 
report should include a test case that demonstrates the problem. Also, 
if you haven't already done so, please read the CONTRIBUTING [2] guidelines.


Before a pull request, we will need a bug report with a standalone 
reproducible test case, submitted at https://bugreport.java.com/

 -- ideally a test case that could be turned into an automated test.

-- Kevin


On 11/13/2019 6:40 AM, Michael Paus wrote:

Hi,
have you considered directly contributing your proposed change via a 
PR on
? According to my experience this may 
speed
up things considerably but don't forget to follow the procedures as 
outlined in

.
--Michael

Am 13.11.19 um 15:14 schrieb Rony G. Flatscher:
Hmm, not getting any feedback so far, so wondering if there are 
currently any Java developers who
take advantage of the ability of FXMLLoader to have FXML controllers 
implemented in any of the Java

javax.script languages?

For those, who use scripting languages for FXML controllers the 
request that FXMLLoader adds both
entries, ScriptEngine.FILENAME (for debugging, logging) and 
ScriptEngine.ARGV () (for making the
event object available directly as an argument) into the engine 
Bindings, should be quite helpful

while developing and running the scripts.

[Personally I am using the scripting engine ooRexx successfully for 
teaching oo programming from
scratch to JavaFX in a single semester (four hour lecture, eight 
ECTS) at a Business Administration
university. So these two missing features in the current FXMLLoader 
support for FXML controllers
would help tremendously, especially in case of coding errors as 
currently it is not clear from which
file the script that has an error comes from, making it extremely 
cumbersome and time consuming in

JavaFX applications that use multiple and complex FXML files.]

Therefore I would kindly ask interested committers for mentoring the 
proposed changes. Enclosed
please find a simpler version of the patch that adds these missing 
features to the ENGINE_SCOPE
Bindings in the three locations where ScriptEngine.eval() gets 
invoked (it ).


To comment this simple patch, maybe I should add a few remarks such 
that the context becomes clear:


   * invoking a script via ScriptEngine.eval() will always be 
accompanied with a ScriptContext that

 usually maintains two Bindings (Maps):

   o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. 
for putting the FXML elements that
 have an fx:id attribute defined, such that scripts can get 
access to them, independent of a
 particular ScriptEngine) which can also be used for sharing 
values among different script

 invocations,

   o one, ENGINE_SCOPE Bindings, usually used for individual 
invocations.


   * while a FXML file gets processed sequentially by the FXMLLoader 
elements in the form of
 "" will cause invoking the 
ScriptEngine.eval(Reader): this
 patch fetches the ENGINE_SCOPE Bindings and puts the value 
"someScript.ext" with the key
 ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public 
class FXMLLoader" and "@@

 -1582,6 +1585,8 @@ public class FXMLLoader" in the patch),

   * if an event handler gets defined (e.g. with the event attribute 
" onAction="someScript">") the FXMLLoader creates a 
ScriptEventHandler and stores "someScript" and
 the ScriptEngine for executing that script whenever the event 
fires.


   o When an event fires, the current implementation creates a 
copy of the current ENGINE_SCOPE
 Bindings from the ScriptEngine's ScriptContext, adds its 
entries to it after saving the
 entry "event" with the ActionEvent object in it. It then 
changes the ScriptEngine's current
 ScriptContext such that it now uses the new copy of the 
Bindings as its ENGINE_SCOPE
 Bindings, runs the script using eval() and then restores the 
ScriptContext ENGINE_SCOPE

 Bindings.

   o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public 
class FXMLLoader") instead will
 create a copy of the ENGINE_SCOPE Bindings only once at 
creation time (and puts the
 appropriate ScriptEngine.FILENAME into it using the name of 
the FXML file that defines the
 event script attribute) and will 

Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Michael Paus]

Hi,
have you considered directly contributing your proposed change via a PR on
? According to my experience this may speed
up things considerably but don't forget to follow the procedures as 
outlined in

.
--Michael

Am 13.11.19 um 15:14 schrieb Rony G. Flatscher:

Hmm, not getting any feedback so far, so wondering if there are currently any 
Java developers who
take advantage of the ability of FXMLLoader to have FXML controllers 
implemented in any of the Java
javax.script languages?

For those, who use scripting languages for FXML controllers the request that 
FXMLLoader adds both
entries, ScriptEngine.FILENAME (for debugging, logging) and ScriptEngine.ARGV 
() (for making the
event object available directly as an argument) into the engine Bindings, 
should be quite helpful
while developing and running the scripts.

[Personally I am using the scripting engine ooRexx successfully for teaching oo 
programming from
scratch to JavaFX in a single semester (four hour lecture, eight ECTS) at a 
Business Administration
university. So these two missing features in the current FXMLLoader support for 
FXML controllers
would help tremendously, especially in case of coding errors as currently it is 
not clear from which
file the script that has an error comes from, making it extremely cumbersome 
and time consuming in
JavaFX applications that use multiple and complex FXML files.]

Therefore I would kindly ask interested committers for mentoring the proposed 
changes. Enclosed
please find a simpler version of the patch that adds these missing features to 
the ENGINE_SCOPE
Bindings in the three locations where ScriptEngine.eval() gets invoked (it ).

To comment this simple patch, maybe I should add a few remarks such that the 
context becomes clear:

   * invoking a script via ScriptEngine.eval() will always be accompanied with 
a ScriptContext that
 usually maintains two Bindings (Maps):

   o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. for putting 
the FXML elements that
 have an fx:id attribute defined, such that scripts can get access to 
them, independent of a
 particular ScriptEngine) which can also be used for sharing values 
among different script
 invocations,

   o one, ENGINE_SCOPE Bindings, usually used for individual invocations.

   * while a FXML file gets processed sequentially by the FXMLLoader elements 
in the form of
 "" will cause invoking the 
ScriptEngine.eval(Reader): this
 patch fetches the ENGINE_SCOPE Bindings and puts the value 
"someScript.ext" with the key
 ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public class 
FXMLLoader" and "@@
 -1582,6 +1585,8 @@ public class FXMLLoader" in the patch),

   * if an event handler gets defined (e.g. with the event attribute 
"") the FXMLLoader creates a ScriptEventHandler and stores 
"someScript" and
 the ScriptEngine for executing that script whenever the event fires.

   o When an event fires, the current implementation creates a copy of the 
current ENGINE_SCOPE
 Bindings from the ScriptEngine's ScriptContext, adds its entries to it 
after saving the
 entry "event" with the ActionEvent object in it. It then changes the 
ScriptEngine's current
 ScriptContext such that it now uses the new copy of the Bindings as 
its ENGINE_SCOPE
 Bindings, runs the script using eval() and then restores the 
ScriptContext ENGINE_SCOPE
 Bindings.

   o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public class 
FXMLLoader") instead will
 create a copy of the ENGINE_SCOPE Bindings only once at creation time 
(and puts the
 appropriate ScriptEngine.FILENAME into it using the name of the FXML 
file that defines the
 event script attribute) and will reuse that Bindings each time the 
handler gets invoked,
 after putting the actual "event" object and the respective 
ScriptEngine.ARGV entry into it.
 Using ScriptEngine.eval(String,Bindings) will use the supplied 
Bindings as the ENGINE_SCOPE
 Bindings for this invocation only, such that no restore is necessary 
upon return.

As only entries get added to the engine Bindings that have not been used by 
FXMLLoader this simple
patch should not affect existing scripts. The patch has been tested and works.

Maybe it helps the cause for applying this patch, if I point out that I have 
been active in a number
of opensource projects, including Apache's BSF which led to my participation as 
an expert in JSR-223
which originally defined the javax.script framework introduced with Java 6 
(also authored a complete
ScriptEngine implementation with both, the javax.script.Compilable and the 
javax.script.Invocable
interfaces).

So looking for interested committers who would be willing to mentor this patch. 
Please advise.

---rony



On 06.11.2019 16:05, Rony G. 

Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

Hmm, not getting any feedback so far, so wondering if there are currently any 
Java developers who
take advantage of the ability of FXMLLoader to have FXML controllers 
implemented in any of the Java
javax.script languages?

For those, who use scripting languages for FXML controllers the request that 
FXMLLoader adds both
entries, ScriptEngine.FILENAME (for debugging, logging) and ScriptEngine.ARGV 
() (for making the
event object available directly as an argument) into the engine Bindings, 
should be quite helpful
while developing and running the scripts.

[Personally I am using the scripting engine ooRexx successfully for teaching oo 
programming from
scratch to JavaFX in a single semester (four hour lecture, eight ECTS) at a 
Business Administration
university. So these two missing features in the current FXMLLoader support for 
FXML controllers
would help tremendously, especially in case of coding errors as currently it is 
not clear from which
file the script that has an error comes from, making it extremely cumbersome 
and time consuming in
JavaFX applications that use multiple and complex FXML files.]

Therefore I would kindly ask interested committers for mentoring the proposed 
changes. Enclosed
please find a simpler version of the patch that adds these missing features to 
the ENGINE_SCOPE
Bindings in the three locations where ScriptEngine.eval() gets invoked (it ).

To comment this simple patch, maybe I should add a few remarks such that the 
context becomes clear:

  * invoking a script via ScriptEngine.eval() will always be accompanied with a 
ScriptContext that
usually maintains two Bindings (Maps):

  o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. for putting 
the FXML elements that
have an fx:id attribute defined, such that scripts can get access to 
them, independent of a
particular ScriptEngine) which can also be used for sharing values 
among different script
invocations,

  o one, ENGINE_SCOPE Bindings, usually used for individual invocations.

  * while a FXML file gets processed sequentially by the FXMLLoader elements in 
the form of
"" will cause invoking the 
ScriptEngine.eval(Reader): this
patch fetches the ENGINE_SCOPE Bindings and puts the value "someScript.ext" 
with the key
ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public class 
FXMLLoader" and "@@
-1582,6 +1585,8 @@ public class FXMLLoader" in the patch),

  * if an event handler gets defined (e.g. with the event attribute "") the FXMLLoader creates a ScriptEventHandler and 
stores "someScript" and
the ScriptEngine for executing that script whenever the event fires.

  o When an event fires, the current implementation creates a copy of the 
current ENGINE_SCOPE
Bindings from the ScriptEngine's ScriptContext, adds its entries to it 
after saving the
entry "event" with the ActionEvent object in it. It then changes the 
ScriptEngine's current
ScriptContext such that it now uses the new copy of the Bindings as its 
ENGINE_SCOPE
Bindings, runs the script using eval() and then restores the 
ScriptContext ENGINE_SCOPE
Bindings.

  o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public class 
FXMLLoader") instead will
create a copy of the ENGINE_SCOPE Bindings only once at creation time 
(and puts the
appropriate ScriptEngine.FILENAME into it using the name of the FXML 
file that defines the
event script attribute) and will reuse that Bindings each time the 
handler gets invoked,
after putting the actual "event" object and the respective 
ScriptEngine.ARGV entry into it.
Using ScriptEngine.eval(String,Bindings) will use the supplied Bindings 
as the ENGINE_SCOPE
Bindings for this invocation only, such that no restore is necessary 
upon return.

As only entries get added to the engine Bindings that have not been used by 
FXMLLoader this simple
patch should not affect existing scripts. The patch has been tested and works.

Maybe it helps the cause for applying this patch, if I point out that I have 
been active in a number
of opensource projects, including Apache's BSF which led to my participation as 
an expert in JSR-223
which originally defined the javax.script framework introduced with Java 6 
(also authored a complete
ScriptEngine implementation with both, the javax.script.Compilable and the 
javax.script.Invocable
interfaces).

So looking for interested committers who would be willing to mentor this patch. 
Please advise.

---rony



On 06.11.2019 16:05, Rony G. Flatscher wrote:
> Using a script engine (javax.script.ScriptEngine) for implementing a FXML 
> controller there are two
> important information missing in the ScriptContext.ENGINE_SCOPE Bindings 
> supplied to the script used
> to eval() the script code:
>
>   * ScriptEngine.FILENAME
>   o This value denotes the file name from where the script code was 
> fetched that is being eval()'d.

FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Rony G. Flatscher]

Using a script engine (javax.script.ScriptEngine) for implementing a FXML 
controller there are two
important information missing in the ScriptContext.ENGINE_SCOPE Bindings 
supplied to the script used
to eval() the script code:

  * ScriptEngine.FILENAME
  o This value denotes the file name from where the script code was fetched 
that is being eval()'d.
  o When debugging script controllers in a complex JavaFX application it is 
mandatory to know
the file name the script code was taken from (as such scripts could be 
called/run from
different FXML files). Also, in the case of script runtime errors, 
usually the file name is
given by the script engine where the error has occurred to ease 
debugging, such that it is
important to really supply the filename.
  + Note: the 'location'-URL in ScriptContext.GLOBAL_SCOPE refers the 
FXML file,  not to the
file that hosts the script that gets run if using the "diff --git a/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java 
b/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java
index 7f3d2f3083..eab4541659 100644
--- a/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java
+++ b/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java
@@ -1558,6 +1558,12 @@ public class FXMLLoader {
 location = new URL(FXMLLoader.this.location, source);
 }
 
+Bindings engineBindings = 
engine.getBindings(ScriptContext.ENGINE_SCOPE);
+Bindings localBindings = engine.createBindings();
+localBindings.put(engine.FILENAME, location.getPath());
+localBindings.putAll(engineBindings);
+scriptEngine.setBindings(localBindings, 
ScriptContext.ENGINE_SCOPE);
+
 InputStreamReader scriptReader = null;
 try {
 scriptReader = new 
InputStreamReader(location.openStream(), charset);
@@ -1569,6 +1575,9 @@ public class FXMLLoader {
 scriptReader.close();
 }
 }
+
+// Restore the original bindings
+engine.setBindings(engineBindings, 
ScriptContext.ENGINE_SCOPE);
 } catch (IOException exception) {
 throw constructLoadException(exception);
 }
@@ -1582,7 +1591,16 @@ public class FXMLLoader {
 if (value != null && !staticLoad) {
 // Evaluate the script
 try {
+Bindings engineBindings = 
scriptEngine.getBindings(ScriptContext.ENGINE_SCOPE);
+Bindings localBindings = scriptEngine.createBindings();
+localBindings.put(scriptEngine.FILENAME, 
location.getPath());
+localBindings.putAll(engineBindings);
+scriptEngine.setBindings(localBindings, 
ScriptContext.ENGINE_SCOPE);
+
 scriptEngine.eval((String)value);
+
+   // Restore the original bindings
+scriptEngine.setBindings(engineBindings, 
ScriptContext.ENGINE_SCOPE);
 } catch (ScriptException exception) {
 System.err.println(exception.getMessage());
 }
@@ -1687,6 +1705,9 @@ public class FXMLLoader {
 Bindings engineBindings = 
scriptEngine.getBindings(ScriptContext.ENGINE_SCOPE);
 Bindings localBindings = scriptEngine.createBindings();
 localBindings.put(EVENT_KEY, event);
+localBindings.put(scriptEngine.ARGV, new Object[]{event});
+URL location=(URL) 
scriptEngine.getBindings(ScriptContext.GLOBAL_SCOPE).get(LOCATION_KEY);
+localBindings.put(scriptEngine.FILENAME, location.getPath());
 localBindings.putAll(engineBindings);
 scriptEngine.setBindings(localBindings, 
ScriptContext.ENGINE_SCOPE);