Not finding installed font family on Windows

[Rony G. Flatscher]

Having installed the "IBM Plex" (otf) fonts (e.g. a file like "IBMPlexMono-Text.otf") to the global 
Windows font directory at "C:\Windows\Fonts" (%windir%\Fonts) the font family "IBM Plex Mono" and 
the like does not get listed with "javafx.scene.text.Font.getFamilies()".


Using javafx.scene.text.Font.getFontNames() the fonts are listed (e.g. as 
"IBMPlexMono-Text").

Is this to be expected, no font family, but font names carrying the name of the otf-font file only 
rather than the logical name of the "open type font"?


---rony

P.S.: This may be related to  although it sounds 
to be a different issue.

Question ad css' -fx-font-family

[Rony G. Flatscher]

Not sure whether these are bugs or working as intended:

 * setting in a css "-fx-font-family" to:

    -fx-font-family: "IBM Plex Mono","Liberation 
Mono",Consolas,Monaco,Terminus,Courier,monospace;

   If the first listed font is not found then JavaFX uses the "family=System" 
rather than trying
   all listed fonts in sequence and if none is found using "family=Monospaced". 
Testing on a
   Windows system with "Liberation Mono", "Consolas" and "Courier" installed 
will yield
   "family=System" if retrieving the used font from the control.

 * It seems that if the first font family in the list is not found in 
"-fx-font-family" by JavaFX
   then all other listed font families get ignored and the fallback seems to be 
"family=System".

Is this to be expected or is this a bug (have not found anything in the bug 
database)?

---rony

Re: Seeking FXML examples with the "onChange" attribute defined for ObservableList, ObservableMap, ObservableSet ...

[Rony G. Flatscher]

Maybe asking the same with a different question: what JavaFX classes can have 
an "onChange"
attribute in a FXML file defined, such that one can look into it and explore 
that particular feature?

As there are three change listener types (ListChangeListener.Change, 
MapChaneListener.Change,
SetChangeListener.Change) for that purpose, it would be helpful to be pointed 
at three respective
JavaFX classes.

---rony

On 28.07.2020 13:18, Rony G. Flatscher wrote:
> Hi Nir,
>
> On 27.07.2020 22:39, Nir Lisker wrote:
> > Hi Rony,
> >
> > I think that this PR is not the place for this question since it only 
> fixes a typo there.
>
> sorry, my bad, not realizing that the reply will be taken as part of the PR! 
> This time with a proper
> new e-mail.
>
> ---
>
> In <https://github.com/openjdk/jfx/pull/274> there are corrections for the 
> text relating to
> documenting the "onChange" attribute for "ObservableList" supplying a 
> "ListChangeListener.Change"
> [1], "ObservableMap" supplying a "MapChangeListener.Change" [2] or 
> "ObservableSet" supplying a
> "SetChangeListener.Change" [3].
>
> Does anyone have FXML examples for defining the "onChange" attribute for any 
> of the three
> Observable{List|Map|Set}?
>
> ---rony
>
> [1] "ListChangeListener.Change":
> <https://docs.oracle.com/javase/8/javafx/api/javafx/collections/ListChangeListener.Change.html>
> [2] "MapChangeListener.Change": 
> <https://docs.oracle.com/javase/8/javafx/api/javafx/collections/MapChangeListener.Change.html>
> [3] "SetChangeListener.Change":
> <https://docs.oracle.com/javase/8/javafx/api/javafx/collections/SetChangeListener.Change.html>

Seeking FXML examples with the "onChange" attribute defined for ObservableList, ObservableMap, ObservableSet ...

[Rony G. Flatscher]

Hi Nir,

On 27.07.2020 22:39, Nir Lisker wrote:
> Hi Rony,
>
> I think that this PR is not the place for this question since it only 
fixes a typo there.

sorry, my bad, not realizing that the reply will be taken as part of the PR! 
This time with a proper
new e-mail.

---

In  there are corrections for the text 
relating to
documenting the "onChange" attribute for "ObservableList" supplying a 
"ListChangeListener.Change"
[1], "ObservableMap" supplying a "MapChangeListener.Change" [2] or 
"ObservableSet" supplying a
"SetChangeListener.Change" [3].

Does anyone have FXML examples for defining the "onChange" attribute for any of 
the three
Observable{List|Map|Set}?

---rony

[1] "ListChangeListener.Change":

[2] "MapChangeListener.Change": 

[3] "SetChangeListener.Change":

A request for FXML exxamples (Re: [jfx15] Fix mistakes in FX API docs [v3]

[Rony G. Flatscher]

On 26.07.2020 12:10, Nir Lisker wrote:
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional 
>> fixes in the vicinity.
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
>
>   VBox and HBox fixes
>
> -
>
> Changes:
>   - all: https://git.openjdk.java.net/jfx/pull/274/files
>   - new: https://git.openjdk.java.net/jfx/pull/274/files/5c7d74ef..141e78f1
>
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jfx/274/webrev.02
>  - incr: https://webrevs.openjdk.java.net/jfx/274/webrev.01-02
>
>   Stats: 11 lines in 2 files changed: 0 ins; 2 del; 9 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/274.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/274/head:pull/274
>
> PR: https://git.openjdk.java.net/jfx/pull/274

One of the changes reads (at ):


modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html



Viewed

@@ -720,7 +720,7 @@ Special 
handlers for
collections a

 Collections and object properties cannot be listen to using setOnEvent() methods.

For these reason, special handler methods need to be used.

ObservableList, ObservableMap or ObservableSet

uses a special onChange attribute that points to 
a handler method with
a ListChangeListener.Change, MapChangeListener.Change or SetChangeListener.Change parameter, respectively.





VBox fx:controller="com.foo.MyController"

Does anyone have FXML examples where "onChange" for ObservableList, 
ObservableMap and ObservableSet 
get employed?

---rony

Integrated: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

On Mon, 20 Apr 2020 12:45:30 GMT, Rony G. Flatscher 
 wrote:

> This PR adds a "compile" process instruction to FXML files with the optional 
> PI data "true" (default) and "false". The
> PI data is turned into a boolean value using "Boolean.parseBoolean(String)".
> This makes it possible to inject the compile PI everywhere in a FXML file and 
> turn on and off compilation of scripts if
> the scripting engine implements the javax.script.Compilable interface. The PR 
> adds the ability for a fallback in case
> compilation of scripts fails, in which case a warning gets issued about this 
> fact and evaluation of the script will be
> done without compilation. Because of the fallback scripts get compiled with 
> this version by default.
> -
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
> 
> ### Issue
>  * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): 
> FXMLLoader: if script engines implement
>javax.script.Compilable compile scripts
> 
> 
> ### Download
> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192`
> `$ git checkout pull/192`

This pull request has now been integrated.

Changeset: 45c9854c
Author:Rony G. Flatscher 
Committer: Kevin Rushforth 
URL:   https://git.openjdk.java.net/jfx/commit/45c9854c
Stats: 2553 lines in 29 files changed: 2 ins; 2523 del; 28 mod

8238080: FXMLLoader: if script engines implement javax.script.Compilable 
compile scripts

Reviewed-by: kcr, aghaisas

-

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6]

[Rony G Flatscher]

Hi Ajit,

Kevin looked into it already yesterday. There was some problem at github at the 
time I submitted the /integrate comment, which merely needs to be reissued by 
me. Having been on the road I was not able to do it yesterday, will be first 
thing after arriving at  the office today.
Also, thank you very much for your review efforts!

Best regards

—-rony

Rony G. Flatscher (mobil/e)

> Am 29.06.2020 um 07:56 schrieb Ajit Ghaisas :
> 
> On Sat, 27 Jun 2020 14:07:24 GMT, Rony G. Flatscher 
>  wrote:
> 
>>> This PR adds a "compile" process instruction to FXML files with the 
>>> optional PI data "true" (default) and "false". The
>>> PI data is turned into a boolean value using "Boolean.parseBoolean(String)".
>>> This makes it possible to inject the compile PI everywhere in a FXML file 
>>> and turn on and off compilation of scripts if
>>> the scripting engine implements the javax.script.Compilable interface. The 
>>> PR adds the ability for a fallback in case
>>> compilation of scripts fails, in which case a warning gets issued about 
>>> this fact and evaluation of the script will be
>>> done without compilation. Because of the fallback scripts get compiled with 
>>> this version by default.
>>> -
>>> ### Progress
>>> - [x] Change must not contain extraneous whitespace
>>> - [x] Commit message must refer to an issue
>>> - [ ] Change must be properly reviewed
>>> 
>>> ### Issue
>>> * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): 
>>> FXMLLoader: if script engines implement
>>>   javax.script.Compilable compile scripts
>>> 
>>> 
>>> ### Download
>>> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192`
>>> `$ git checkout pull/192`
>> 
>> Rony G. Flatscher has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>  Incorporating Kevin's review comments (overlooked some places).
> 
> Marked as reviewed by aghaisas (Reviewer).
> 
> -
> 
> PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6]

[Rony G . Flatscher]

On Sat, 27 Jun 2020 14:41:29 GMT, Kevin Rushforth  wrote:

>> Rony G. Flatscher has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Incorporating Kevin's review comments (overlooked some places).
>
> Looks good.

It seems that there is a need of 2 reviewers though only one is defined (when 
clicking "Show all reviewers").  Is there
anything I can/need to do to advance the state?

-

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6]

[Rony G . Flatscher]

> This PR adds a "compile" process instruction to FXML files with the optional 
> PI data "true" (default) and "false". The
> PI data is turned into a boolean value using "Boolean.parseBoolean(String)".
> This makes it possible to inject the compile PI everywhere in a FXML file and 
> turn on and off compilation of scripts if
> the scripting engine implements the javax.script.Compilable interface. The PR 
> adds the ability for a fallback in case
> compilation of scripts fails, in which case a warning gets issued about this 
> fact and evaluation of the script will be
> done without compilation. Because of the fallback scripts get compiled with 
> this version by default.
> -
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
> 
> ### Issue
>  * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): 
> FXMLLoader: if script engines implement
>javax.script.Compilable compile scripts
> 
> 
> ### Download
> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192`
> `$ git checkout pull/192`

Rony G. Flatscher has updated the pull request incrementally with one 
additional commit since the last revision:

  Incorporating Kevin's review comments (overlooked some places).

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/192/files
  - new: https://git.openjdk.java.net/jfx/pull/192/files/f7f9cacb..52da8a35

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/192/webrev.05
 - incr: https://webrevs.openjdk.java.net/jfx/192/webrev.04-05

  Stats: 138 lines in 7 files changed: 20 ins; 2 del; 116 mod
  Patch: https://git.openjdk.java.net/jfx/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v5]

[Rony G . Flatscher]

> This PR adds a "compile" process instruction to FXML files with the optional 
> PI data "true" (default) and "false". The
> PI data is turned into a boolean value using "Boolean.parseBoolean(String)".
> This makes it possible to inject the compile PI everywhere in a FXML file and 
> turn on and off compilation of scripts if
> the scripting engine implements the javax.script.Compilable interface. The PR 
> adds the ability for a fallback in case
> compilation of scripts fails, in which case a warning gets issued about this 
> fact and evaluation of the script will be
> done without compilation. Because of the fallback scripts get compiled with 
> this version by default.
> -
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
> 
> ### Issue
>  * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): 
> FXMLLoader: if script engines implement
>javax.script.Compilable compile scripts
> 
> 
> ### Download
> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192`
> `$ git checkout pull/192`

Rony G. Flatscher has updated the pull request incrementally with one 
additional commit since the last revision:

  Incorporating Kevin's review comments.

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/192/files
  - new: https://git.openjdk.java.net/jfx/pull/192/files/f2ea3d0e..f7f9cacb

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/192/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/192/webrev.03-04

  Stats: 38 lines in 6 files changed: 3 ins; 10 del; 25 mod
  Patch: https://git.openjdk.java.net/jfx/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v4]

[Rony G . Flatscher]

On Thu, 25 Jun 2020 23:59:47 GMT, Kevin Rushforth  wrote:

>> Rony G. Flatscher has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Incorporating Kevin's review comments (final int, fix for loop test, 
>> correct formatting).
>
> The API changes look good. Also, the CSR has been approved.
> 
> The code changes in FXMLLoader look good.
> 
> The newly added tests pass with your fix.
> 
> I also verified that at least some of the newly added tests fail without fix 
> (good)
> 
> Most of the rest of the comments are on formatting and code style, so this 
> looks about ready to go in.

Kevin, thank you for your feedback and sponsorship!

Hope that I have applied the changes to all affected files appropriately. (It 
is interesting for me that despite trying
to adhere to the OpenJDK formatting, sometimes my own - decadelong trained :) - 
formattings slip thru without noticing
it.)

-

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v3]

[Rony G . Flatscher]

On Fri, 19 Jun 2020 00:04:37 GMT, Kevin Rushforth  wrote:

>> Rony G. Flatscher has updated the pull request with a new target base due to 
>> a merge or a rebase. The pull request now
>> contains 27 commits:
>>  - Updates to meet Kevin's comment in PR 192 as of May 27th.
>>  - Merge remote-tracking branch 'upstream/master' into 
>> scriptCompilablePIcompileFallback
>>  - Reword the compile processing instructions (replace 'Hint' with 'Note:', 
>> adjust text to context), remove spurious empty
>>line in script example code.
>>  - Document the compile processing instruction for scripts.
>>  - Add missing language processing instruction.
>>  - Correct typo, replace tabs, remove trailing blanks.
>>  - Make sure we test the default behaviour to compile script by leaving out 
>> the compile PI.
>>  - Revert temporary rename of test method.
>>  - Correct ModuleLauncherTest (remove non-existing test), correct formatting.
>>  - Always supply the script's filename in the error message first to further 
>> ease spotting the location of script
>>exceptions.
>>  - ... and 17 more: 
>> https://git.openjdk.java.net/jfx/compare/6bd0e22d...7ef1bd68
>
> I reviewed the implementation, and I think this is close to being ready, but 
> I have a couple questions. I also still
> need to review the test and run it, but that will be later.
> I also noticed a few places with minor formatting issues -- mostly missing 
> spaces and extra blank lines added to some
> files, but also `else {` when it should be `} else {`. I'll wait until the 
> substantive part of the review is done to
> note them all (so if you can fix them ahead of time, that would be good).

@CSR-update: looks good!

> modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1769:
> 
>> 1768: try {
>> 1769: if (isCompiled) {
>> 1770:compiledScript.eval(localBindings);
> 
> I think there may be other places you need to set isCompiled (it isn't set in 
> the first couple of methods where you
> compile scripts). Can you check this?

isCompiled gets set explicitly to false at object creation time. It only will 
be changed to true, if the script was
successfully compiled.

-

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v4]

[Rony G . Flatscher]

> This PR adds a "compile" process instruction to FXML files with the optional 
> PI data "true" (default) and "false". The
> PI data is turned into a boolean value using "Boolean.parseBoolean(String)".
> This makes it possible to inject the compile PI everywhere in a FXML file and 
> turn on and off compilation of scripts if
> the scripting engine implements the javax.script.Compilable interface. The PR 
> adds the ability for a fallback in case
> compilation of scripts fails, in which case a warning gets issued about this 
> fact and evaluation of the script will be
> done without compilation. Because of the fallback scripts get compiled with 
> this version by default.
> -
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
> 
> ### Issue
>  * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): 
> FXMLLoader: if script engines implement
>javax.script.Compilable compile scripts
> 
> 
> ### Download
> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192`
> `$ git checkout pull/192`

Rony G. Flatscher has updated the pull request incrementally with one 
additional commit since the last revision:

  Incorporating Kevin's review comments (final int, fix for loop test, correct 
formatting).

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/192/files
  - new: https://git.openjdk.java.net/jfx/pull/192/files/7ef1bd68..f2ea3d0e

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/192/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/192/webrev.02-03

  Stats: 15 lines in 1 file changed: 1 ins; 5 del; 9 mod
  Patch: https://git.openjdk.java.net/jfx/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192

PR: https://git.openjdk.java.net/jfx/pull/192

Re: [Rev 02] RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

> This PR adds a "compile" process instruction to FXML files with the optional 
> PI data "true" (default) and "false". The
> PI data is turned into a boolean value using "Boolean.parseBoolean(String)".
> This makes it possible to inject the compile PI everywhere in a FXML file and 
> turn on and off compilation of scripts if
> the scripting engine implements the javax.script.Compilable interface. The PR 
> adds the ability for a fallback in case
> compilation of scripts fails, in which case a warning gets issued about this 
> fact and evaluation of the script will be
> done without compilation. Because of the fallback scripts get compiled with 
> this version by default.
> -
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
> 
> ### Issue
>  * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): 
> FXMLLoader: if script engines implement
>javax.script.Compilable compile scripts
> 
> 
> ### Download
> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192`
> `$ git checkout pull/192`

Rony G. Flatscher has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now
contains 27 commits:

 - Updates to meet Kevin's comment in PR 192 as of May 27th.
 - Merge remote-tracking branch 'upstream/master' into 
scriptCompilablePIcompileFallback
 - Reword the compile processing instructions (replace 'Hint' with 'Note:', 
adjust text to context), remove spurious empty
   line in script example code.
 - Document the compile processing instruction for scripts.
 - Add missing language processing instruction.
 - Correct typo, replace tabs, remove trailing blanks.
 - Make sure we test the default behaviour to compile script by leaving out the 
compile PI.
 - Revert temporary rename of test method.
 - Correct ModuleLauncherTest (remove non-existing test), correct formatting.
 - Always supply the script's filename in the error message first to further 
ease spotting the location of script
   exceptions.
 - ... and 17 more: https://git.openjdk.java.net/jfx/compare/6bd0e22d...7ef1bd68

-

Changes: https://git.openjdk.java.net/jfx/pull/192/files
 Webrev: https://webrevs.openjdk.java.net/jfx/192/webrev.02
  Stats: 2545 lines in 29 files changed: 2516 ins; 2 del; 27 mod
  Patch: https://git.openjdk.java.net/jfx/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192

PR: https://git.openjdk.java.net/jfx/pull/192

Re: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLL

[Rony G Flatscher]

Hi Kevin,

is there anything I need to do? What are the next steps I should look for?

—-rony

Rony G. Flatscher (mobil/e)

> Am 12.05.2020 um 19:23 schrieb Rony G. Flatscher :
> 
> Hi Kevin,
> 
> in the meantime I have tried to come up with a formulation for the 
> "Introduction to FXML"
> specification about the new compile processing instruction which is brief and 
> complete. While being
> there I fixed a typo in the document and added a missing language processing 
> instruction to an
> existing script example, hope that was o.k. as I have not filed an explicit 
> bug for it.
> 
> Also closed the PR 129 and 187, removed the WIP from PR 192, and supplied the 
> CSR draft as a comment.
> 
> If there is anything else I should do, please let me know.
> 
> Cheers,
> 
> ---rony
> 
> 
>> On 11.05.2020 14:12, Rony G. Flatscher wrote:
>> Hi Kevin,
>> 
>>> On 09.05.2020 17:16, Kevin Rushforth wrote:
>>> I'm finally getting back to this. I took a look at 
>>> https://github.com/openjdk/jfx/pull/192 and I
>>> like that as the direction for this enhancement.
>>> 
>>> The initial CSR you have is a good start.
>> Thank you!
>> 
>>> Next steps are:
>>> 
>>> 1. Update the "Introduction to FXML" specification (see my comment in the 
>>> PR)
>>> 2. Update PR 192 with the draft CSR as a comment, modifying it to include 
>>> the above additions to
>>> "Introduction to FXML"
>>> 3. Remove WIP from the title
>>> 
>>> You can then close the other two PRs (129 and 187).
>> will do (may take a little bit).
>> 
>> Cheers
>> 
>> ---rony
>> 
>> 
>>> On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:
>>>> Hi Kevin,
>>>> 
>>>> what should be the next steps?
>>>> 
>>>> Should I remove "WIP" from the title in 
>>>> <https://github.com/openjdk/jfx/pull/192> and add the CSR
>>>> draft text of my last e-mail as a "CSR" comment with PR # 192, thereby 
>>>> requesting it to be added
>>>> to <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?
>>>> 
>>>> Please advise.
>>>> 
>>>> TIA,
>>>> 
>>>> ---rony
>>>> 
>>>> P.S.: This is the RFE:
>>>> 
>>>>  * RFE (2020-01-24): 
>>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>> 
>>>> These are the three versions (all with appropriate unit tests) that I came 
>>>> up with
>>>> chronologically to implement the RFE, would prefer the latest version (PR 
>>>> # 192):
>>>> 
>>>>  * Compile if Compilable implemented (2020-02-28): 
>>>> <https://github.com/openjdk/jfx/pull/129>
>>>>  * Compile if compile PI and Compilable is implemented (2020-04-11):
>>>><https://github.com/openjdk/jfx/pull/187>
>>>>  * Compile with fallback, if Compilable is implemented, compile PI for 
>>>> fine-grained control
>>>>(2020-04-14): <https://github.com/openjdk/jfx/pull/192>
>>>> 
>>>> 
>>>> On 22.04.2020 20:01, Rony G. Flatscher wrote:
>>>>> Hi Kevin,
>>>>> 
>>>>> as I am not able to file a CSR with the issue you suggested to come up 
>>>>> with a draft, so here it goes:
>>>>> 
>>>>>Summary
>>>>>===
>>>>>Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating 
>>>>> them, if the script engine
>>>>>implements the javax.script.Compilable interface to speed up 
>>>>> execution. In case compilation
>>>>>throws a javax.script.ScriptException fall back to evaluating the 
>>>>> uncompiled script. Allow
>>>>>control of script compilation with a "compile" PI for FXML files.
>>>>> 
>>>>>Problem
>>>>>===
>>>>>javafx.fxml.FXMLLoader is able to execute scripts in Java script 
>>>>> languages
>>>>>(javax.script.ScriptEngine implementations) referred to or embedded in 
>>>>> a FXML file.
>>>>> 
>>>>>If a script engine implements the javax.script.Compilable interface, 
>>>>> then such scripts could be
>>>>>compiled and the resulting javax.script.Compiled

Re: Questions ad JavaScript in JavaFX' WebEngine

[Rony G. Flatscher]

Hi Mike,

thank you for your pointers!

On 14.05.2020 14:21, Mike Hearn wrote:
> The WebKit binding code is some of the more complex code in JavaFX. Rather 
> than try to extend the
> script tag you could instead look at the code for the  tag and the 
> old support for
> Netscape-style plugins. 
>
> https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebCore/plugins
>
> I've looked at this in the past to investigate embedding of arbitrary JavaFX 
> nodes into a web
> page. It doesn't look particularly unfeasible as there's still a lot of old 
> code lying around that
> used to do exactly that, it's just not used much anymore. However wiring it 
> up to the Java level
> would require a fairly adventurous programmer with good knowledge of C++, 
> rendering engines and
> JavaFX internals.

In the meantime I had some time to peek around that location which is quite 
interesting!

What I would be interested in is a possibility to get callbacks into Java while 
the DOM tree gets
built, such that one could run scripts and define script callbacks for plain 
HTML text.

The idea would be to think about possibilities to enable all of the Java script 
languages to become
usable as script languages for HTML, i.e. for WebView applications.

As it stands now it should be possible with the help of WebEngine to process 
the DOM tree after
loading concluded and process and set up event attribute scripts, if necessary. 
(Again, this is a
very coarse idea at the moment.)

---rony


>
> On Mon, May 11, 2020 at 14:17:07, Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> On 09.05.2020 17:23, Kevin Rushforth wrote:
>
> WebEngine uses WebKit's JavaScriptCore as its JavaScript engine. The 
> sources are in the
> jfx repo, along with the JavaFX-specific classes that implement the 
> two-way Java <-->
> JavaScript bridge. Other than the public API docs for WebEngine, 
> which you referred to in
> your message, there isn't any documentation of the interface.
>
> OK, thank you very much, this is reassuring! :)
>
> What sort of information are you looking for?
>
> Well, as event handlers and script tags in HTML have a type attribute 
> that allows to denote
> script languages other than JavaScript, I am interested in evaluating 
> what WebEngine/WebView
>     allows for to support this with any of the Java script engines.
>
> ---rony
>
> On 5/8/2020 7:01 AM, Rony G. Flatscher wrote:
>
> Wondering which JavaScript engine gets referred to in WebEngine 
> [1].
>
> In case it is currently (JavaFX 14) Nashorn [2], what happens 
> after Nashorn gets
> removed from the next [3] version? In case it is WebKit's 
> JavaScriptCore [4] where can
> one study the interface from WebEngine to it?
>
> ---rony
>
> [1] WebEngine:
> 
> <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/class-use/WebEngine.html
> 
> <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/class-use/WebEngine.html>>
> [2] Nashorn: <https://openjdk.java.net/projects/nashorn/
> <https://openjdk.java.net/projects/nashorn/>>
> [3] Nashorn removal from JDK 15: 
> <https://openjdk.java.net/jeps/372
> <https://openjdk.java.net/jeps/372>>
> [4] JavaScriptCore: <https://trac.webkit.org/wiki/JavaScriptCore
> <https://trac.webkit.org/wiki/JavaScriptCore>>
>
>

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

On Wed, 13 May 2020 09:22:20 GMT, Rony G. Flatscher 
 wrote:

>> Doc addition for the CSR:
>> =
>> The following text was added to the [Introduction to
>> FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
>> at two locations, the "Script Event Handlers" ("#script_event_handlers") and 
>> the "Scripting" (#scripting") sections:
>>> Hint: to turn off automatic compilation of script code place the 
>>> processing instruction >> class="code">?compile false? before the script. To turn on 
>>> compilation of script code again use the
>>> processing instruction ?compile true? (or 
>>> short: >> class="code">?compile?). The compile processing instruction 
>>> can be used repeatedly to turn compilation
>>> of script code off and on.
>> 
>> This documents the compile processing instruction, that it compilation is on 
>> by default and that it can be turned off
>> and on repeatedly. It is hoped that this formulation plays well with the 
>> context where this paragraph got introduced.
>
> Doc addition for the CSR (update)
> -
> In the event handler section:
>> Note: to turn off automatic compilation of script code place the 
>> processing instruction > class="code">?compile false? before the element that contains 
>> the script. To turn on compilation of
>> script code again use the processing instruction > class="code">?compile true? (or short: > class="code">?compile?). The compile processing instruction 
>> can be used repeatedly to turn compilation
>> of script code off and on.
> 
> In the Scripting section:
>> Note: to turn off automatic compilation of script code place the 
>> processing instruction > class="code">?compile false? before the script element. To 
>> turn on compilation of script code again use
>> the processing instruction ?compile true? 
>> (or short: > class="code">?compile?). The compile processing instruction 
>> can be used repeatedly to turn compilation
>> of script code off and on.

/solves

-

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

On Tue, 12 May 2020 17:33:06 GMT, Rony G. Flatscher 
 wrote:

>> Suggested CSR:
>> 
>> Summary
>> ===
>> Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if 
>> the script engine
>> implements the javax.script.Compilable interface to speed up execution. In 
>> case compilation
>> throws a javax.script.ScriptException fall back to evaluating the uncompiled 
>> script. Allow
>> control of script compilation with a "compile" PI for FXML files.
>> 
>> Problem
>> ===
>> javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
>> (javax.script.ScriptEngine implementations) referred to or embedded in a 
>> FXML file.
>> 
>> If a script engine implements the javax.script.Compilable interface, then 
>> such scripts could be
>> compiled and the resulting javax.script.CompiledScript could be executed 
>> instead using its
>> eval() methods.
>> 
>> Evaluating the javax.script.CompiledScript objects may help speed up the 
>> execution of script
>> invocations, especially for scripts defined for event attributes in FXML 
>> elements (e.g. like
>> onMouseMove) which may be repetitively invoked and evaluated.
>> 
>> Solution
>> 
>> Before evaluating the script code test whether the javax.script.ScriptEngine 
>> implements
>> javax.script.Compilable. If so, compile the script to a 
>> javax.script.CompiledScript object first
>> and then use its eval() method to evaluate the script, otherwise continue to 
>> use the
>> javax.script.ScriptEngine's eval() method instead. Should compilation of a 
>> script yield
>> (unexpectedly) a javax.script.ScriptException then fall back to using the
>> javax.script.ScriptEngine's eval() method. A new process instruction 
>> "compile" allows control of
>> the compilation of scripts ("true" sets compilation on, "false" to set 
>> compilation off) in FXML
>> files.
>> 
>> Specification
>> =
>> If a javax.script.ScriptEngine implements the javax.script.Compilable 
>> interface, then use its
>> compile() method to compile the script to a javax.script.CompiledScript 
>> object and use its
>> eval() method to run the script. In the case that the compilation throws 
>> (unexpectedly) a
>> javax.script.ScriptException log a warning and fall back to using the
>> javax.script.ScriptEngine's eval() method instead.
>> To allow setting this feature off and on while processing the FXML file a 
>> "compile" process
>> instruction ("" or "") gets defined that 
>> allows to turn
>> compilation off and on throughout a FXML file.
>
> Doc addition for the CSR:
> =
> The following text was added to the [Introduction to
> FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
> at two locations, the "Script Event Handlers" ("#script_event_handlers") and 
> the "Scripting" (#scripting") sections:
>> Hint: to turn off automatic compilation of script code place the 
>> processing instruction > class="code">?compile false? before the script. To turn on 
>> compilation of script code again use the
>> processing instruction ?compile true? (or 
>> short: > class="code">?compile?). The compile processing instruction 
>> can be used repeatedly to turn compilation
>> of script code off and on.
> 
> This documents the compile processing instruction, that it compilation is on 
> by default and that it can be turned off
> and on repeatedly. It is hoped that this formulation plays well with the 
> context where this paragraph got introduced.

Doc addition for the CSR (update)
-
In the event handler section:
> Note: to turn off automatic compilation of script code place the 
> processing instruction  class="code">?compile false? before the element that contains 
> the script. To turn on compilation of
> script code again use the processing instruction  class="code">?compile true? (or short:  class="code">?compile?). The compile processing instruction 
> can be used repeatedly to turn compilation
> of script code off and on.

In the Scripting section:
> Note: to turn off automatic compilation of script code place the 
> processing instruction  class="code">?compile false? before the script element. To 
> turn on compilation of script code again use
> the processing instruction ?compile true? 
> (or short:  class="code">?compile?). The compile processing instruction 
> can be used repeatedly to turn compilation
> of script code off and on.

-

PR: https://git.openjdk.java.net/jfx/pull/192

Re: [Rev 01] RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

> This WIP adds the ability for a fallback in case compilation of scripts 
> fails, in which case a warning gets issued
> about this fact and evaluation of the script will be done without 
> compilation. Because of the fallback scripts get
> compiled with this version by default. It extends PR 187 
> <https://github.com/openjdk/jfx/pull/187>.  To further ease
> spotting scripts that cause a ScriptException a message in the form of 
> "filename: caused ScriptException" gets added to
> the exception handling in either of the three locations: an error message, a 
> stack trace or a wrap-up into a
> RuntimeException (having three different kinds of reporting ScriptExceptions 
> may be questioned, however none of these
> tear down the FXML GUI).

Rony G. Flatscher has updated the pull request incrementally with one 
additional commit since the last revision:

  Reword the compile processing instructions (replace 'Hint' with 'Note:', 
adjust text to context), remove spurious empty
  line in script example code.

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/192/files
  - new: https://git.openjdk.java.net/jfx/pull/192/files/44b0f9f8..59a16c9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/192/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/192/webrev.00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

On Tue, 12 May 2020 16:51:08 GMT, Rony G. Flatscher 
 wrote:

>> I think the approach proposed in this PR is the best solution for this 
>> enhancement. Go ahead and remove the `WIP` from
>> the title, and we can proceed with the review.
>> The interface and behavior change will need to be specified in the API docs. 
>> This can be done by modifying the
>> [Introduction to
>> FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
>> document. I recommend documenting the new behavior and `` 
>> attribute somewhere in the
>> [Scripting](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html#L769)
>> section.  As discussed on the mailing list, this will need a CSR, which 
>> should include the changes to the docs.
>
> Suggested CSR:
> 
> Summary
> ===
> Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if 
> the script engine
> implements the javax.script.Compilable interface to speed up execution. In 
> case compilation
> throws a javax.script.ScriptException fall back to evaluating the uncompiled 
> script. Allow
> control of script compilation with a "compile" PI for FXML files.
> 
> Problem
> ===
> javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
> (javax.script.ScriptEngine implementations) referred to or embedded in a FXML 
> file.
> 
> If a script engine implements the javax.script.Compilable interface, then 
> such scripts could be
> compiled and the resulting javax.script.CompiledScript could be executed 
> instead using its
> eval() methods.
> 
> Evaluating the javax.script.CompiledScript objects may help speed up the 
> execution of script
> invocations, especially for scripts defined for event attributes in FXML 
> elements (e.g. like
> onMouseMove) which may be repetitively invoked and evaluated.
> 
> Solution
> 
> Before evaluating the script code test whether the javax.script.ScriptEngine 
> implements
> javax.script.Compilable. If so, compile the script to a 
> javax.script.CompiledScript object first
> and then use its eval() method to evaluate the script, otherwise continue to 
> use the
> javax.script.ScriptEngine's eval() method instead. Should compilation of a 
> script yield
> (unexpectedly) a javax.script.ScriptException then fall back to using the
> javax.script.ScriptEngine's eval() method. A new process instruction 
> "compile" allows control of
> the compilation of scripts ("true" sets compilation on, "false" to set 
> compilation off) in FXML
> files.
> 
> Specification
> =
> If a javax.script.ScriptEngine implements the javax.script.Compilable 
> interface, then use its
> compile() method to compile the script to a javax.script.CompiledScript 
> object and use its
> eval() method to run the script. In the case that the compilation throws 
> (unexpectedly) a
> javax.script.ScriptException log a warning and fall back to using the
> javax.script.ScriptEngine's eval() method instead.
> To allow setting this feature off and on while processing the FXML file a 
> "compile" process
> instruction ("" or "") gets defined that 
> allows to turn
> compilation off and on throughout a FXML file.

Doc addition for the CSR:
=
The following text was added to the [Introduction to
FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
at two locations, the "Script Event Handlers" ("#script_event_handlers") and 
the "Scripting" (#scripting") sections:

> Hint: to turn off automatic compilation of script code place the 
> processing instruction  class="code">?compile false? before the script. To turn on 
> compilation of script code again use the
> processing instruction ?compile true? (or 
> short:  class="code">?compile?). The compile processing instruction 
> can be used repeatedly to turn compilation
> of script code off and on.

This documents the compile processing instruction, that it compilation is on by 
default and that it can be turned off
and on repeatedly. It is hoped that this formulation plays well with the 
context where this paragraph got introduced.

-

PR: https://git.openjdk.java.net/jfx/pull/192

Re: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLL

[Rony G. Flatscher]

Hi Kevin,

in the meantime I have tried to come up with a formulation for the 
"Introduction to FXML"
specification about the new compile processing instruction which is brief and 
complete. While being
there I fixed a typo in the document and added a missing language processing 
instruction to an
existing script example, hope that was o.k. as I have not filed an explicit bug 
for it.

Also closed the PR 129 and 187, removed the WIP from PR 192, and supplied the 
CSR draft as a comment.

If there is anything else I should do, please let me know.

Cheers,

---rony


On 11.05.2020 14:12, Rony G. Flatscher wrote:
> Hi Kevin,
>
> On 09.05.2020 17:16, Kevin Rushforth wrote:
>> I'm finally getting back to this. I took a look at 
>> https://github.com/openjdk/jfx/pull/192 and I
>> like that as the direction for this enhancement.
>>
>> The initial CSR you have is a good start.
> Thank you!
>
>> Next steps are:
>>
>> 1. Update the "Introduction to FXML" specification (see my comment in the PR)
>> 2. Update PR 192 with the draft CSR as a comment, modifying it to include 
>> the above additions to
>> "Introduction to FXML"
>> 3. Remove WIP from the title
>>
>> You can then close the other two PRs (129 and 187).
> will do (may take a little bit).
>
> Cheers
>
> ---rony
>
>
>> On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:
>>> Hi Kevin,
>>>
>>> what should be the next steps?
>>>
>>> Should I remove "WIP" from the title in 
>>> <https://github.com/openjdk/jfx/pull/192> and add the CSR
>>> draft text of my last e-mail as a "CSR" comment with PR # 192, thereby 
>>> requesting it to be added
>>> to <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?
>>>
>>> Please advise.
>>>
>>> TIA,
>>>
>>> ---rony
>>>
>>> P.S.: This is the RFE:
>>>
>>>   * RFE (2020-01-24): 
>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>
>>> These are the three versions (all with appropriate unit tests) that I came 
>>> up with
>>> chronologically to implement the RFE, would prefer the latest version (PR # 
>>> 192):
>>>
>>>   * Compile if Compilable implemented (2020-02-28): 
>>> <https://github.com/openjdk/jfx/pull/129>
>>>   * Compile if compile PI and Compilable is implemented (2020-04-11):
>>> <https://github.com/openjdk/jfx/pull/187>
>>>   * Compile with fallback, if Compilable is implemented, compile PI for 
>>> fine-grained control
>>> (2020-04-14): <https://github.com/openjdk/jfx/pull/192>
>>>
>>>
>>> On 22.04.2020 20:01, Rony G. Flatscher wrote:
>>>> Hi Kevin,
>>>>
>>>> as I am not able to file a CSR with the issue you suggested to come up 
>>>> with a draft, so here it goes:
>>>>
>>>> Summary
>>>> ===
>>>> Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating 
>>>> them, if the script engine
>>>> implements the javax.script.Compilable interface to speed up 
>>>> execution. In case compilation
>>>> throws a javax.script.ScriptException fall back to evaluating the 
>>>> uncompiled script. Allow
>>>> control of script compilation with a "compile" PI for FXML files.
>>>>
>>>> Problem
>>>> ===
>>>> javafx.fxml.FXMLLoader is able to execute scripts in Java script 
>>>> languages
>>>> (javax.script.ScriptEngine implementations) referred to or embedded in 
>>>> a FXML file.
>>>>
>>>> If a script engine implements the javax.script.Compilable interface, 
>>>> then such scripts could be
>>>> compiled and the resulting javax.script.CompiledScript could be 
>>>> executed instead using its
>>>> eval() methods.
>>>>
>>>> Evaluating the javax.script.CompiledScript objects may help speed up 
>>>> the execution of script
>>>> invocations, especially for scripts defined for event attributes in 
>>>> FXML elements (e.g. like
>>>> onMouseMove) which may be repetitively invoked and evaluated.
>>>>
>>>> Solution 
>>>> 
>>>> Before evaluating the script code test whether the 
>>>> javax.script.ScriptEngine implements
>>

Re: [Closed] RFR: WIP 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

On Fri, 28 Feb 2020 17:46:58 GMT, Rony G. Flatscher 
 wrote:

> TODO: ADD DESCRIPTION OF PROPOSED FIX HERE.

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jfx/pull/129

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

On Sat, 9 May 2020 15:15:52 GMT, Kevin Rushforth  wrote:

>>  test units for: compile PI+fallback
>> 
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off.java
>> ... use compile PI to set off compilation of scripts; each script code 
>> starts with "demo_02_"
>> 
>> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off.fxml
>> ... set compilation for scripts off (""), therefore no 
>> script gets compiled
>> 
>> ---
>> 
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off_On.java
>> ... alternatively uses compile PI to turn compilation off and on; the script 
>> code starts alternatively with "demo_02_"
>> and "RgfPseudoCompiledScript.eval(", depending on the state set with the PI
>> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off_on.fxml
>> ... starts out explicitly with "" switching the state after 
>> each element containing a script
>> 
>> ---
>> 
>>  
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On.java
>>  ... no compile PI given, hence compilation of scripts is on; each script 
>> code starts with
>>  "RgfPseudoCompiledScript.eval("
>>  tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on.fxml
>> ... no compile PI given, starts out to compile scripts by default
>> 
>> ---
>> 
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On_Off.java
>> ... alternatively uses compile PI to turn compilation on and off; the script 
>> code starts alternatively with
>> "RgfPseudoCompiledScript.eval(", and "demo_02_" depending on the state set 
>> with the PI
>> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on_off.fxml
>> ... starts out explicitly with "" switching the state after 
>> each element containing a script (sometimes
>> using PI "" to test setting it to true)
>> ---
>> 
>> tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java
>> ... although compile scripts is on, none of the scripts get compiled as they 
>> all contain the string "FAIL COMPILATION"
>> which causes RgfPseudoScriptEngineCompilable.compile(...) to throw a 
>> ScriptException causing the fallback to be used;
>> all scripts therefore start with "demo_03_"
>>  
>> tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_03_fail_compile.fxml
>>  ... explicitly turns on compilation (which is on by default anyway), adds 
>> "FAIL COMPILATION" to all inline scripts and
>>  to all external scripts with the filename that starts with "demo_03_"
>
> I think the approach proposed in this PR is the best solution for this 
> enhancement. Go ahead and remove the `WIP` from
> the title, and we can proceed with the review.
> The interface and behavior change will need to be specified in the API docs. 
> This can be done by modifying the
> [Introduction to
> FXML](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html)
> document. I recommend documenting the new behavior and `` attribute 
> somewhere in the
> [Scripting](https://github.com/openjdk/jfx/blob/master/modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html#L769)
> section.  As discussed on the mailing list, this will need a CSR, which 
> should include the changes to the docs.

Suggested CSR:

Summary
===
Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the 
script engine
implements the javax.script.Compilable interface to speed up execution. In case 
compilation
throws a javax.script.ScriptException fall back to evaluating the uncompiled 
script. Allow
control of script compilation with a "compile" PI for FXML files.

Problem
===
javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
(javax.script.ScriptEngine implementations) referred to or embedded in a FXML 
file.

If a script engine implements the javax.script.Compilable interface, then such 
scripts could be
compiled and the resulting javax.script.CompiledScript could be executed 
instead using its
eval() methods.

Evaluating the javax.script.CompiledScript objects may help speed up the 
execution of script
invocations, especially for scripts defined for event attributes in FXML 
elements (e.g. like
onMouseMove) which may be repetitively invoked and evaluated.

Solution

Before evaluating the script code test whether the javax.script.ScriptEngine 
implements
javax.script.Compilable. If so, compile the script to a 
javax.script.CompiledScript object first
and then use its eval() method to evaluate the script, otherwise continue to 
use the
javax.script.ScriptEngine's eval() method instead. Should compilation of a 
script yield
(unexpectedly) a javax.script.ScriptException then fall back to using the
javax.script.ScriptEngine's eval() method. A new process instruction "compile" 
allows control of
the compilation of 

Re: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

On Mon, 20 Apr 2020 12:45:30 GMT, Rony G. Flatscher 
 wrote:

> This WIP adds the ability for a fallback in case compilation of scripts 
> fails, in which case a warning gets issued
> about this fact and evaluation of the script will be done without 
> compilation. Because of the fallback scripts get
> compiled with this version by default. It extends PR 187 
> <https://github.com/openjdk/jfx/pull/187>.  To further ease
> spotting scripts that cause a ScriptException a message in the form of 
> "filename: caused ScriptException" gets added to
> the exception handling in either of the three locations: an error message, a 
> stack trace or a wrap-up into a
> RuntimeException (having three different kinds of reporting ScriptExceptions 
> may be questioned, however none of these
> tear down the FXML GUI).

 test units for: compile PI+fallback

tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off.java
... use compile PI to set off compilation of scripts; each script code starts 
with "demo_02_"

tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off.fxml
... set compilation for scripts off (""), therefore no script 
gets compiled

---

tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off_On.java
... alternatively uses compile PI to turn compilation off and on; the script 
code starts alternatively with "demo_02_"
and "RgfPseudoCompiledScript.eval(", depending on the state set with the PI

tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_off_on.fxml
... starts out explicitly with "" switching the state after 
each element containing a script

---

 
tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On.java
 ... no compile PI given, hence compilation of scripts is on; each script code 
starts with
 "RgfPseudoCompiledScript.eval("
 
 tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on.fxml
... no compile PI given, starts out to compile scripts by default

---

tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_On_Off.java
... alternatively uses compile PI to turn compilation on and off; the script 
code starts alternatively with
"RgfPseudoCompiledScript.eval(", and "demo_02_" depending on the state set with 
the PI

tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_02_on_off.fxml
... starts out explicitly with "" switching the state after 
each element containing a script (sometimes
using PI "" to test setting it to true)

---

tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java
... although compile scripts is on, none of the scripts get compiled as they 
all contain the string "FAIL COMPILATION"
which causes RgfPseudoScriptEngineCompilable.compile(...) to throw a 
ScriptException causing the fallback to be used;
all scripts therefore start with "demo_03_"

 
tests/system/src/testscriptapp2/resources/mymod/myapp2/demo_03_fail_compile.fxml
 ... explicitly turns on compilation (which is on by default anyway), adds 
"FAIL COMPILATION" to all inline scripts and
 to all external scripts with the filename that starts with "demo_03_"

-

PR: https://git.openjdk.java.net/jfx/pull/192

RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

This WIP adds the ability for a fallback in case compilation of scripts fails, 
in which case a warning gets issued
about this fact and evaluation of the script will be done without compilation. 
Because of the fallback scripts get
compiled with this version by default. It extends PR 187 
.

To further ease spotting scripts that cause a ScriptException a message in the 
form of "filename: caused
ScriptException" gets added to the exception handling in either of the three 
locations: an error message, a stack trace
or a wrap-up into a RuntimeException (having three different kinds of reporting 
ScriptExceptions may be questioned,
however none of these tear down the FXML GUI).

-

Commit messages:
 - Document the compile processing instruction for scripts.
 - Add missing language processing instruction.
 - Correct typo, replace tabs, remove trailing blanks.
 - Make sure we test the default behaviour to compile script by leaving out the 
compile PI.
 - Revert temporary rename of test method.
 - Correct ModuleLauncherTest (remove non-existing test), correct formatting.
 - Always supply the script's filename in the error message first to further 
ease spotting the location of script exceptions.
 - Make message more pregnant.
 - Compile by default, have fallback if compilation fails, adapt/add test unig
 - add compile process instruction to control compilation of compilable 
scripts; PI data can be truei (default) or false
 - ... and 14 more: https://git.openjdk.java.net/jfx/compare/159f6516...44b0f9f8

Changes: https://git.openjdk.java.net/jfx/pull/192/files
 Webrev: https://webrevs.openjdk.java.net/jfx/192/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8238080
  Stats: 2544 lines in 29 files changed: 2514 ins; 2 del; 28 mod
  Patch: https://git.openjdk.java.net/jfx/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192

PR: https://git.openjdk.java.net/jfx/pull/192

Re: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLL

[Rony G. Flatscher]

Hi Kevin,

On 09.05.2020 17:16, Kevin Rushforth wrote:
> I'm finally getting back to this. I took a look at 
> https://github.com/openjdk/jfx/pull/192 and I
> like that as the direction for this enhancement.
>
> The initial CSR you have is a good start.

Thank you!

> Next steps are:
>
> 1. Update the "Introduction to FXML" specification (see my comment in the PR)
> 2. Update PR 192 with the draft CSR as a comment, modifying it to include the 
> above additions to
> "Introduction to FXML"
> 3. Remove WIP from the title
>
> You can then close the other two PRs (129 and 187).

will do (may take a little bit).

Cheers

---rony


> On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:
>>
>> Hi Kevin,
>>
>> what should be the next steps?
>>
>> Should I remove "WIP" from the title in 
>> <https://github.com/openjdk/jfx/pull/192> and add the CSR
>> draft text of my last e-mail as a "CSR" comment with PR # 192, thereby 
>> requesting it to be added
>> to <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?
>>
>> Please advise.
>>
>> TIA,
>>
>> ---rony
>>
>> P.S.: This is the RFE:
>>
>>   * RFE (2020-01-24): 
>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>
>> These are the three versions (all with appropriate unit tests) that I came 
>> up with
>> chronologically to implement the RFE, would prefer the latest version (PR # 
>> 192):
>>
>>   * Compile if Compilable implemented (2020-02-28): 
>> <https://github.com/openjdk/jfx/pull/129>
>>   * Compile if compile PI and Compilable is implemented (2020-04-11):
>> <https://github.com/openjdk/jfx/pull/187>
>>   * Compile with fallback, if Compilable is implemented, compile PI for 
>> fine-grained control
>> (2020-04-14): <https://github.com/openjdk/jfx/pull/192>
>>
>>
>> On 22.04.2020 20:01, Rony G. Flatscher wrote:
>>> Hi Kevin,
>>>
>>> as I am not able to file a CSR with the issue you suggested to come up with 
>>> a draft, so here it goes:
>>>
>>> Summary
>>> ===
>>> Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating 
>>> them, if the script engine
>>> implements the javax.script.Compilable interface to speed up execution. 
>>> In case compilation
>>> throws a javax.script.ScriptException fall back to evaluating the 
>>> uncompiled script. Allow
>>> control of script compilation with a "compile" PI for FXML files.
>>>
>>> Problem
>>> ===
>>> javafx.fxml.FXMLLoader is able to execute scripts in Java script 
>>> languages
>>> (javax.script.ScriptEngine implementations) referred to or embedded in 
>>> a FXML file.
>>>
>>> If a script engine implements the javax.script.Compilable interface, 
>>> then such scripts could be
>>> compiled and the resulting javax.script.CompiledScript could be 
>>> executed instead using its
>>> eval() methods.
>>>
>>> Evaluating the javax.script.CompiledScript objects may help speed up 
>>> the execution of script
>>> invocations, especially for scripts defined for event attributes in 
>>> FXML elements (e.g. like
>>> onMouseMove) which may be repetitively invoked and evaluated.
>>>
>>> Solution 
>>> 
>>> Before evaluating the script code test whether the 
>>> javax.script.ScriptEngine implements
>>> javax.script.Compilable. If so, compile the script to a 
>>> javax.script.CompiledScript object first
>>> and then use its eval() method to evaluate the script, otherwise 
>>> continue to use the
>>> javax.script.ScriptEngine's eval() method instead. Should compilation 
>>> of a script yield
>>> (unexpectedly) a javax.script.ScriptException then fall back to using 
>>> the
>>> javax.script.ScriptEngine's eval() method. A new process instruction 
>>> "compile" allows control of
>>> the compilation of scripts ("true" sets compilation on, "false" to set 
>>> compilation off) in FXML
>>> files.
>>>
>>> Specification
>>> =
>>> If a javax.script.ScriptEngine implements the javax.script.Compilable 
>>> interface, then use its
>>> compile() method to compi

Re: Questions ad JavaScript in JavaFX' WebEngine

[Rony G. Flatscher]

On 09.05.2020 17:23, Kevin Rushforth wrote:
> WebEngine uses WebKit's JavaScriptCore as its JavaScript engine. The sources 
> are in the jfx repo,
> along with the JavaFX-specific classes that implement the two-way Java <--> 
> JavaScript bridge.
> Other than the public API docs for WebEngine, which you referred to in your 
> message, there isn't
> any documentation of the interface. 

OK, thank you very much, this is reassuring! :)

> What sort of information are you looking for?

Well, as event handlers and script tags in HTML have a type attribute that 
allows to denote script
languages other than JavaScript, I am interested in evaluating what 
WebEngine/WebView allows for to
support this with any of the Java script engines.

---rony


> On 5/8/2020 7:01 AM, Rony G. Flatscher wrote:
>> Wondering which JavaScript engine gets referred to in WebEngine [1].
>>
>> In case it is currently (JavaFX 14) Nashorn [2], what happens after Nashorn 
>> gets removed from the
>> next [3] version? In case it is WebKit's JavaScriptCore [4] where can one 
>> study the interface from
>> WebEngine to it?
>>
>> ---rony
>>
>> [1] WebEngine: 
>> <https://openjfx.io/javadoc/14/javafx.web/javafx/scene/web/class-use/WebEngine.html>
>> [2] Nashorn: <https://openjdk.java.net/projects/nashorn/>
>> [3] Nashorn removal from JDK 15: <https://openjdk.java.net/jeps/372>
>> [4] JavaScriptCore: <https://trac.webkit.org/wiki/JavaScriptCore> 

Questions ad JavaScript in JavaFX' WebEngine

[Rony G. Flatscher]

Wondering which JavaScript engine gets referred to in WebEngine [1].

In case it is currently (JavaFX 14) Nashorn [2], what happens after Nashorn 
gets removed from the
next [3] version? In case it is WebKit's JavaScriptCore [4] where can one study 
the interface from
WebEngine to it?

---rony

[1] WebEngine: 

[2] Nashorn: 
[3] Nashorn removal from JDK 15: 
[4] JavaScriptCore: 

Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoade

[Rony G. Flatscher]

Hi Kevin,

what should be the next steps?

Should I remove "WIP" from the title in 
<https://github.com/openjdk/jfx/pull/192> and add the CSR
draft text of my last e-mail as a "CSR" comment with PR # 192, thereby 
requesting it to be added to
<https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>?

Please advise.

TIA,

---rony

P.S.: This is the RFE:

  * RFE (2020-01-24): 
<https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>

These are the three versions (all with appropriate unit tests) that I came up 
with chronologically
to implement the RFE, would prefer the latest version (PR # 192):

  * Compile if Compilable implemented (2020-02-28): 
<https://github.com/openjdk/jfx/pull/129>
  * Compile if compile PI and Compilable is implemented (2020-04-11):
<https://github.com/openjdk/jfx/pull/187>
  * Compile with fallback, if Compilable is implemented, compile PI for 
fine-grained control
(2020-04-14): <https://github.com/openjdk/jfx/pull/192>


On 22.04.2020 20:01, Rony G. Flatscher wrote:
> Hi Kevin,
>
> as I am not able to file a CSR with the issue you suggested to come up with a 
> draft, so here it goes:
>
> Summary
> ===
> Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, 
> if the script engine
> implements the javax.script.Compilable interface to speed up execution. 
> In case compilation
> throws a javax.script.ScriptException fall back to evaluating the 
> uncompiled script. Allow
> control of script compilation with a "compile" PI for FXML files.
>
> Problem
> ===
> javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
> (javax.script.ScriptEngine implementations) referred to or embedded in a 
> FXML file.
>
> If a script engine implements the javax.script.Compilable interface, then 
> such scripts could be
> compiled and the resulting javax.script.CompiledScript could be executed 
> instead using its
> eval() methods.
>
> Evaluating the javax.script.CompiledScript objects may help speed up the 
> execution of script
> invocations, especially for scripts defined for event attributes in FXML 
> elements (e.g. like
> onMouseMove) which may be repetitively invoked and evaluated.
>
> Solution 
> 
> Before evaluating the script code test whether the 
> javax.script.ScriptEngine implements
> javax.script.Compilable. If so, compile the script to a 
> javax.script.CompiledScript object first
> and then use its eval() method to evaluate the script, otherwise continue 
> to use the
> javax.script.ScriptEngine's eval() method instead. Should compilation of 
> a script yield
> (unexpectedly) a javax.script.ScriptException then fall back to using the
> javax.script.ScriptEngine's eval() method. A new process instruction 
> "compile" allows control of
> the compilation of scripts ("true" sets compilation on, "false" to set 
> compilation off) in FXML
> files.
>
> Specification
> =
> If a javax.script.ScriptEngine implements the javax.script.Compilable 
> interface, then use its
> compile() method to compile the script to a javax.script.CompiledScript 
> object and use its
> eval() method to run the script. In the case that the compilation throws 
> (unexpectedly) a
> javax.script.ScriptException log a warning and fall back to using the
> javax.script.ScriptEngine's eval() method instead.
> To allow setting this feature off and on while processing the FXML file a 
> "compile" process
> instruction ("" or "") gets defined that 
> allows to turn
> compilation off and on throughout a FXML file.
>
> Having never seen a real CSR I hope that this matches what is expected and is 
> helpful for
> assessment. If not please advise (got the name of these fields from [1]).
>
> ---
>
> Also added brief information about the respective test units (what they test 
> and yield) in the WIP  [2].
>
> ---rony
>
> [1] "CSR-FAQ": <https://wiki.openjdk.java.net/display/csr/CSR+FAQs>
>
> [2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if 
> script engines implement
> javax.script.Compilable compile scripts #192":  
> <https://github.com/openjdk/jfx/pull/192>
>
>
> On 20.04.2020 14:58, Rony G. Flatscher wrote:
>> There is a new WIP at <https://github.com/openjdk/jfx/pull/192>:
>>
>> This WIP adds the ability for a fallback in case compilation of scripts 
>> fails, in which case a
>> warning gets issued about this fac

An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engin

[Rony G. Flatscher]

Hi Kevin,

as I am not able to file a CSR with the issue you suggested to come up with a 
draft, so here it goes:

Summary
===
Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if 
the script engine
implements the javax.script.Compilable interface to speed up execution. In 
case compilation
throws a javax.script.ScriptException fall back to evaluating the 
uncompiled script. Allow
control of script compilation with a "compile" PI for FXML files.

Problem
===
javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
(javax.script.ScriptEngine implementations) referred to or embedded in a 
FXML file.

If a script engine implements the javax.script.Compilable interface, then 
such scripts could be
compiled and the resulting javax.script.CompiledScript could be executed 
instead using its
eval() methods.

Evaluating the javax.script.CompiledScript objects may help speed up the 
execution of script
invocations, especially for scripts defined for event attributes in FXML 
elements (e.g. like
onMouseMove) which may be repetitively invoked and evaluated.

Solution 

Before evaluating the script code test whether the 
javax.script.ScriptEngine implements
javax.script.Compilable. If so, compile the script to a 
javax.script.CompiledScript object first
and then use its eval() method to evaluate the script, otherwise continue 
to use the
javax.script.ScriptEngine's eval() method instead. Should compilation of a 
script yield
(unexpectedly) a javax.script.ScriptException then fall back to using the
javax.script.ScriptEngine's eval() method. A new process instruction 
"compile" allows control of
the compilation of scripts ("true" sets compilation on, "false" to set 
compilation off) in FXML
files.

Specification
=
If a javax.script.ScriptEngine implements the javax.script.Compilable 
interface, then use its
compile() method to compile the script to a javax.script.CompiledScript 
object and use its
eval() method to run the script. In the case that the compilation throws 
(unexpectedly) a
javax.script.ScriptException log a warning and fall back to using the
javax.script.ScriptEngine's eval() method instead.
To allow setting this feature off and on while processing the FXML file a 
"compile" process
instruction ("" or "") gets defined that 
allows to turn
compilation off and on throughout a FXML file.

Having never seen a real CSR I hope that this matches what is expected and is 
helpful for
assessment. If not please advise (got the name of these fields from [1]).

---

Also added brief information about the respective test units (what they test 
and yield) in the WIP  [2].

---rony

[1] "CSR-FAQ": <https://wiki.openjdk.java.net/display/csr/CSR+FAQs>

[2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script 
engines implement
javax.script.Compilable compile scripts #192":  
<https://github.com/openjdk/jfx/pull/192>


On 20.04.2020 14:58, Rony G. Flatscher wrote:
> There is a new WIP at <https://github.com/openjdk/jfx/pull/192>:
>
> This WIP adds the ability for a fallback in case compilation of scripts 
> fails, in which case a
> warning gets issued about this fact and evaluation of the script will be 
> done without
> compilation. Because of the fallback scripts get compiled with this 
> version by default. It
> extends PR 187 #187.
>
> To further ease spotting scripts that cause a ScriptException a message 
> in the form of
> "filename: caused ScriptException" gets added to the exception handling 
> in either of the three
> locations: an error message, a stack trace or a wrap-up into a 
> RuntimeException (having three
> different kinds of reporting ScriptExceptions may be questioned, however 
> none of these tear down
> the FXML GUI).
>
> This WIP comes with proper test units as well. As per Kevin's suggestion a 
> warning gets logged
> whenever a script cannot be compiled and the fallback gets used.
>
> It is suggested to use this WIP as it includes the compilation by default 
> with a safe fallback to
> evaluate the uncompiled script, if compilation (unexpectedly) fails.
>
> Again, any feedback, discussion welcome!
>
> ---rony
>
> P.S.: In the log history there is a commit message "Make message more 
> pregnant.", it should have
> read "Make messages more terse." instead|.||
> |
>
>
> On 17.04.2020 19:37, Rony G. Flatscher wrote:
>> There is a new WIP at <https://github.com/openjdk/jfx/pull/187> which adds a 
>> compile PI (process
>> instruction) for turning on and off script 

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

[Rony G. Flatscher]

Hi Michael,

thank you very much for sharing this link, which is very interesting!

Reading the limitation section is interesting and also reveals current 
assumptions of the GraalVM
developers that may not meet reality in full, hence making it a little bit 
cumbersome/difficult to
fully support it in use cases that they have not thought of or have not seen a 
need for (e.g. not
invoking finalize() because it got deprecated in Java 9, where the discussions 
that led to that
deprecation annotation were related to stated misuse of finalize() by Java 
programmers; but in those
discussions it also was undisputed that there are use cases where finalize() is 
actually useful and
important, e.g. in native bridges where finalize() gets used to clean-up Java 
proxies and their
non-Java peers; for that reason finalize() was not "deprecated for removal" and 
should only be
deployed, if there is a good reason; removing the invocation of finalize() is 
just a wrong decision
in that context with implications leading to scenarios where GraalVM might be 
considered to not be
usable). However, GraalVM is also a project in motion/development and as long 
as the ultimate goal
is to become fully compatible with Java hopes are that eventually the current
shortcomings/restrictions get solved/lifted (but some may prefer to wait until 
that has happened).

In any case it is impressive already that you guys have become able to use 
GraalVM for allowing
JavaFX to run on iOS and Android.

Again, thank you very much for your link which helps me a lot to assess that 
route (and to think
about solutions for current problems that may exist in GraalVM in supporting a 
dynamic language,
that needs reflective support and uses JNI).

---rony


On 20.04.2020 19:29, Michael Paus wrote:
> The Android/iOS work is based on GraalVMs Native Image which has some 
> limitations.
> These can be found here: 
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
> I stumbled over the problem with Method Handles when I tried to integrate 
> some third-party
> software into it. (E.g. Log4J and NSMenuFX)(I had to abandon Log4J and fixed 
> the problems in
> NSMenuFX.)
>
> Am 20.04.20 um 15:26 schrieb Rony G. Flatscher:
>> On 20.04.2020 15:06, Michael Paus wrote:
>>> This is deviating quite a bit from the original issue of this thread, isn't 
>>> it?
>>>
>>> As a side note: MethodHandles are not supported by GraalVM native image
>>> and so this would probably collide with the attempts to get JavaFX running
>>> on Android/iOS.
>> Would you have some link where there would be a technical overview about how 
>> Java and JavaFX support
>> gets currently realized under Android/iOS? Also, how is reflection supposed 
>> to be carried out on
>> that platform, ie. is java.lang.reflect available?
>>
>> ---rony 

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

[Rony G. Flatscher]

Hi Johan,

On 20.04.2020 15:54, Johan Vos wrote:
> The JavaFX implementation used in Android and iOS is using 100% the same code 
> as the one on desktop.
> JavaFX internally uses reflection, and that is supported indeed (can be used 
> in app-specific code
> as well).
> The best place to get started is at https://github.com/gluonhq/client-samples

thank you very much for both, the link and assuring that reflection is still 
available to apps as well!

---rony

>
> On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> On 20.04.2020 15:06, Michael Paus wrote:
> > This is deviating quite a bit from the original issue of this thread, 
> isn't it?
> >
> > As a side note: MethodHandles are not supported by GraalVM native image
> > and so this would probably collide with the attempts to get JavaFX 
> running
> > on Android/iOS.
> Would you have some link where there would be a technical overview about 
> how Java and JavaFX
> support
> gets currently realized under Android/iOS? Also, how is reflection 
> supposed to be carried out on
> that platform, ie. is java.lang.reflect available?
>
> ---rony
>

A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabe

[Rony G. Flatscher]

There is a new WIP at <https://github.com/openjdk/jfx/pull/192>:

This WIP adds the ability for a fallback in case compilation of scripts 
fails, in which case a
warning gets issued about this fact and evaluation of the script will be 
done without
compilation. Because of the fallback scripts get compiled with this version 
by default. It
extends PR 187 #187.

To further ease spotting scripts that cause a ScriptException a message in 
the form of
"filename: caused ScriptException" gets added to the exception handling in 
either of the three
locations: an error message, a stack trace or a wrap-up into a 
RuntimeException (having three
different kinds of reporting ScriptExceptions may be questioned, however 
none of these tear down
the FXML GUI).

This WIP comes with proper test units as well. As per Kevin's suggestion a 
warning gets logged
whenever a script cannot be compiled and the fallback gets used.

It is suggested to use this WIP as it includes the compilation by default with 
a safe fallback to
evaluate the uncompiled script, if compilation (unexpectedly) fails.

Again, any feedback, discussion welcome!

---rony

P.S.: In the log history there is a commit message "Make message more 
pregnant.", it should have
read "Make messages more terse." instead|.||
|


On 17.04.2020 19:37, Rony G. Flatscher wrote:
> There is a new WIP at <https://github.com/openjdk/jfx/pull/187> which adds a 
> compile PI (process
> instruction) for turning on and off script compilation if the script engine 
> implements the
> Compilable interface.
>
> By default compilation is off (no compilation), such that one needs to add a 
> compile PI
> ("") at the top to activate this feature. Supplying "true" 
> (default) or "false" as the PI
> data turns this feature on and off.
>
> The WIP comes with adapted test units that test "compile on" for an entire 
> fxml file, "compile off",
> alternating using "compile on and off", and alternating using "compile off 
> and on". This will test
> all variants of applying the compile PI for all categories of scripts.
>
> Any feedback appreciated!
>
> ---rony
>
> P.S.: FXML files that contain unknown PIs do not cause a runtime error by 
> FXMLLoader, they just get
> ignored. Therefore one could apply the compile PI to FXML files that are used 
> in older JavaFX runtimes.
>
> P.P.S.: In the next days I will also add Kevin's idea in a separate version 
> that will have a
> fallback solution in case a compilation is (unexpectedly) not successful, 
> reverting to
> (interpretative) evaluation/execution of the script. In that version it is 
> planned to have
> compilation on by default as in the case of a compilation failure there will 
> be a safe backup solution.
>
>
> On 14.04.2020 19:52, Kevin Rushforth wrote:
>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I 
>> would wait a bit to
>> create the CSR until the review is far enough along to know which direction 
>> we intend to go.
>>
>> Unless there is a real concern about possible regressions if scripts are 
>> compiled by default, I
>> think "enabled by default" is the way to go. Your argument that such script 
>> engines are broken
>> seems reasonable, since this only applies to script engines that implement 
>> javax.script.Compilable
>> in the first place. We still might want to add way to turn compilation off 
>> for individual scripts.
>> One other thing to consider is that if compilation fails, it might make 
>> sense to log a warning and
>> fall back to the existing interpreted mode.
>>
>> Does anyone else have any concerns with this?
>>
>> -- Kevin
>>
>>
>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote:
>>> Hi there,
>>>
>>> as there was probably enough time that has passed by I would intend to 
>>> create a CSR in the next days
>>> with the PR as per Kevin's suggestion.
>>>
>>> (For the case that this feature should not be active by default, the CSR 
>>> will suggest to define a
>>> new "compile" PI in the form  (default, if no PI 
>>> data given: true), which
>>> is independent of the existence of a language PI (this way it becomes also 
>>> possible to allow
>>> compilation of external scripts denoted with the script-element, which do 
>>> not need a page language
>>> to be set as the file's extension allows the appropriate script engine to 
>>> be loaded and used for
>>> execution). A compile-PI would allow for turning compilation o

WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"

[Rony G. Flatscher]

There is a new WIP at <https://github.com/openjdk/jfx/pull/187> which adds a 
compile PI (process
instruction) for turning on and off script compilation if the script engine 
implements the
Compilable interface.

By default compilation is off (no compilation), such that one needs to add a 
compile PI
("") at the top to activate this feature. Supplying "true" (default) 
or "false" as the PI
data turns this feature on and off.

The WIP comes with adapted test units that test "compile on" for an entire fxml 
file, "compile off",
alternating using "compile on and off", and alternating using "compile off and 
on". This will test
all variants of applying the compile PI for all categories of scripts.

Any feedback appreciated!

---rony

P.S.: FXML files that contain unknown PIs do not cause a runtime error by 
FXMLLoader, they just get
ignored. Therefore one could apply the compile PI to FXML files that are used 
in older JavaFX runtimes.

P.P.S.: In the next days I will also add Kevin's idea in a separate version 
that will have a
fallback solution in case a compilation is (unexpectedly) not successful, 
reverting to
(interpretative) evaluation/execution of the script. In that version it is 
planned to have
compilation on by default as in the case of a compilation failure there will be 
a safe backup solution.


On 14.04.2020 19:52, Kevin Rushforth wrote:
> Yes, I agree that enough time has gone by. Go ahead with your proposal. I 
> would wait a bit to
> create the CSR until the review is far enough along to know which direction 
> we intend to go.
>
> Unless there is a real concern about possible regressions if scripts are 
> compiled by default, I
> think "enabled by default" is the way to go. Your argument that such script 
> engines are broken
> seems reasonable, since this only applies to script engines that implement 
> javax.script.Compilable
> in the first place. We still might want to add way to turn compilation off 
> for individual scripts.
> One other thing to consider is that if compilation fails, it might make sense 
> to log a warning and
> fall back to the existing interpreted mode.
>
> Does anyone else have any concerns with this?
>
> -- Kevin
>
>
> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote:
>> Hi there,
>>
>> as there was probably enough time that has passed by I would intend to 
>> create a CSR in the next days
>> with the PR as per Kevin's suggestion.
>>
>> (For the case that this feature should not be active by default, the CSR 
>> will suggest to define a
>> new "compile" PI in the form  (default, if no PI 
>> data given: true), which
>> is independent of the existence of a language PI (this way it becomes also 
>> possible to allow
>> compilation of external scripts denoted with the script-element, which do 
>> not need a page language
>> to be set as the file's extension allows the appropriate script engine to be 
>> loaded and used for
>> execution). A compile-PI would allow for turning compilation of scripts on 
>> by just adding the PI
>>  or   to FXML files (and  to 
>> turn off), which seems to
>> be simple and self-documentary. In general employing such compile PIs allows 
>> for setting compilation
>> of scripts on and off throughout an FXML file.)
>>
>> ---rony
>>
>>
>> On 04.04.2020 18:03, Rony G. Flatscher wrote:
>>
>>> Hi Kevin,
>>>
>>> On 03.04.2020 01:21, Kevin Rushforth wrote:
>>>> I see that you updated the PR and sent it for review.
>>>>
>>>> Before we formally review it in the PR, let's finish the discussion as to 
>>>> whether this is a useful
>>>> feature, and if so, what form this feature should take.
>>>>
>>>>  From my point of view, this does seem like a useful feature. Would other 
>>>> users of FXML benefit
>>>> from it?
>>> Script code should be executed faster after compilation, so any FXML page 
>>> that hosts script code
>>> may
>>> benefit.
>>>
>>> The benefits depend on the type of script (and maybe its size and its 
>>> complexity) and also on the
>>> types of event handlers the scripts serve, e.g. move or drag event handlers 
>>> may benefit
>>> significantly. This is because repeated invocation of compiled script event 
>>> handlers do not cause
>>> the reparsing of that script's source and interpreting it on each 
>>> invocation, which may be
>>> expensive
>>> depending on the script engine, but rather allows the immediate 
>>> ev

Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"

[Rony G. Flatscher]

Hi there,

as there was probably enough time that has passed by I would intend to create a 
CSR in the next days
with the PR as per Kevin's suggestion.

(For the case that this feature should not be active by default, the CSR will 
suggest to define a
new "compile" PI in the form  (default, if no PI data 
given: true), which
is independent of the existence of a language PI (this way it becomes also 
possible to allow
compilation of external scripts denoted with the script-element, which do not 
need a page language
to be set as the file's extension allows the appropriate script engine to be 
loaded and used for
execution). A compile-PI would allow for turning compilation of scripts on by 
just adding the PI
 or   to FXML files (and  to turn 
off), which seems to
be simple and self-documentary. In general employing such compile PIs allows 
for setting compilation
of scripts on and off throughout an FXML file.)

---rony


On 04.04.2020 18:03, Rony G. Flatscher wrote:

> Hi Kevin,
>
> On 03.04.2020 01:21, Kevin Rushforth wrote:
>> I see that you updated the PR and sent it for review.
>>
>> Before we formally review it in the PR, let's finish the discussion as to 
>> whether this is a useful
>> feature, and if so, what form this feature should take.
>>
>> From my point of view, this does seem like a useful feature. Would other 
>> users of FXML benefit
>> from it?
> Script code should be executed faster after compilation, so any FXML page 
> that hosts script code may
> benefit.
>
> The benefits depend on the type of script (and maybe its size and its 
> complexity) and also on the
> types of event handlers the scripts serve, e.g. move or drag event handlers 
> may benefit
> significantly. This is because repeated invocation of compiled script event 
> handlers do not cause
> the reparsing of that script's source and interpreting it on each invocation, 
> which may be expensive
> depending on the script engine, but rather allows the immediate 
> evaluation/execution of the compiled
> script by the script engine.
>
>> I'm not certain whether we want it to be implicit, compiling the script if 
>> the script engine in
>> question implements Compilable, or via a new keyword or tag. What are the 
>> pros / cons?
> In principle there are three possibilities:
>
> 1) If a script engine implements javax.script.Compilable, compile the 
> script and execute the
> compiled version. In the case of event handlers compile and buffer the 
> compiled script and
> execute the compiled script each time its registered event fires. 
>
>   o Pro: immediately benefits all existing FXML pages that host scripts
>   o Con: it is theoretically possible (albeit quite unlikely) that there 
> are scripts that fail
> compiling but have been employed successfully in interpreted mode
>
> 2) Introduce some form of an optional attribute (e.g. 
> "compile={true|false}") to the FXML
> language PI that switches on compilation of scripts hosted in FXML 
> definitions if the script
> engine implements the javax.script.Compilable interface. If missing it 
> would default to "false".
> (Alternatively, add a "compile" PI, that if present causes the 
> compilation of scripts, if the
> script engine supports it. It would be an error if the "compile" PI was 
> present, but the
> "language" PI was not.)
>
>   o Pro: compilation of FXML hosted scripts is done only, if the FXML 
> definition of the language
> PI gets changed
>   o Con: benefit not made available automatically to existing FXML pages 
> that host scripts
>
> 3) Another possibility would be to define a boolean attribute/property 
> "compile" for script and
> node elements and only compile the scripts, if the property is set to true
>
>   o Pro: compilation of FXML hosted scripts is done only, if the FXML 
> definition gets changed
> accordingly
>   o Con: potential benefit not made available automatically to existing 
> FXML pages that host scripts
>
> 2 and 3 could be combined, where 2 would define the default compilation 
> behavior that then could be
> overruled individually by 3.
>
> The question would be whether 2 or/and 3 are really necessary as it can be 
> expected that compilation
> of scripts by the script engines would find the same errors as while 
> interpreting the very same
> scripts (if not, the script engine is badly broken and it could be argued 
> that then the
> interpretation part of the script engine might be expected to be broken as 
> well which would be quite
> dangerous from an integrity POV; the same considera

Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"

[Rony G. Flatscher]

Hi Kevin,

On 03.04.2020 01:21, Kevin Rushforth wrote:
> I see that you updated the PR and sent it for review.
>
> Before we formally review it in the PR, let's finish the discussion as to 
> whether this is a useful
> feature, and if so, what form this feature should take.
>
> From my point of view, this does seem like a useful feature. Would other 
> users of FXML benefit
> from it?

Script code should be executed faster after compilation, so any FXML page that 
hosts script code may
benefit.

The benefits depend on the type of script (and maybe its size and its 
complexity) and also on the
types of event handlers the scripts serve, e.g. move or drag event handlers may 
benefit
significantly. This is because repeated invocation of compiled script event 
handlers do not cause
the reparsing of that script's source and interpreting it on each invocation, 
which may be expensive
depending on the script engine, but rather allows the immediate 
evaluation/execution of the compiled
script by the script engine.

> I'm not certain whether we want it to be implicit, compiling the script if 
> the script engine in
> question implements Compilable, or via a new keyword or tag. What are the 
> pros / cons?

In principle there are three possibilities:

1) If a script engine implements javax.script.Compilable, compile the 
script and execute the
compiled version. In the case of event handlers compile and buffer the 
compiled script and
execute the compiled script each time its registered event fires. 

  o Pro: immediately benefits all existing FXML pages that host scripts
  o Con: it is theoretically possible (albeit quite unlikely) that there 
are scripts that fail
compiling but have been employed successfully in interpreted mode

2) Introduce some form of an optional attribute (e.g. 
"compile={true|false}") to the FXML
language PI that switches on compilation of scripts hosted in FXML 
definitions if the script
engine implements the javax.script.Compilable interface. If missing it 
would default to "false".
(Alternatively, add a "compile" PI, that if present causes the compilation 
of scripts, if the
script engine supports it. It would be an error if the "compile" PI was 
present, but the
"language" PI was not.)

  o Pro: compilation of FXML hosted scripts is done only, if the FXML 
definition of the language
PI gets changed
  o Con: benefit not made available automatically to existing FXML pages 
that host scripts

3) Another possibility would be to define a boolean attribute/property 
"compile" for script and
node elements and only compile the scripts, if the property is set to true

  o Pro: compilation of FXML hosted scripts is done only, if the FXML 
definition gets changed
accordingly
  o Con: potential benefit not made available automatically to existing 
FXML pages that host scripts

2 and 3 could be combined, where 2 would define the default compilation 
behavior that then could be
overruled individually by 3.

The question would be whether 2 or/and 3 are really necessary as it can be 
expected that compilation
of scripts by the script engines would find the same errors as while 
interpreting the very same
scripts (if not, the script engine is badly broken and it could be argued that 
then the
interpretation part of the script engine might be expected to be broken as well 
which would be quite
dangerous from an integrity POV; the same consideration applies as well if the 
execution of the
compiled script would behave differently to interpreting the very same script 
by the same script
engine).

The current WIP implements 1 above and includes an appropriate test unit.

> What do others think?



> In either case, we would need to make sure that this doesn't present any 
> security concerns in the
> presence of a security manager. As long as a user-provided class is on the 
> stack, it will be fine,
> but we would need to ensure that.

The compilation of scripts needs to be done by the Java script engines 
(implementing both,
javax.script.Engine and javax.script.Compilable) as well as controlling the 
execution of compiled
scripts ([javax.script.CompiledScript]
(https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)).

---rony



> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote:
>> After merging master, applying some fixes and changing the title to reflect 
>> the change from WIP to a
>> pull request I would kindly request a review of this pull request!
>>
>> Here the URL: <https://github.com/openjdk/jfx/pull/129>, title changed to: 
>> "8238080: FXMLLoader: if
>> script engines implement javax.script.Compilable compile scripts".
>>
>> ---rony
>>
>>
>> On 28.02.2020 19

Re: Seeking help with latest master ...

[Rony G. Flatscher]

On 04.04.2020 03:25, Eric Bresie wrote:

> Are you behind a proxy? I had problems with another application which 
> required registering certificates and related credentials keys to be added 
> for java.

No, no proxy server (my setup has direct access).

---rony


> On April 2, 2020 at 2:20:44 PM CDT, Johan Vos  wrote:
> I have no scientific evidence for this, but I remember issues related to
> SSL with some JDK's as well, which may or may not be related to the cacerts
> file that is bundled.
>
> - Johan
>
> On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher 
> wrote:
>
>>> Being stuck (tried the previous working gradle 5.6.4, could get "gradle
>>> clean", but not further) in
>>> the end I just tried Java 14 and that allowed me to run "gradle"
>>> successfully (currently building
>>> webkit to get going again). Just wanted to let interested readers know.
>>> (Would be great though, if
>>> it worked with the 11 LTS version as well.)
>>>
>>> ---rony
>>>
>>>
>>> On 31.03.2020 20:36, Rony G. Flatscher wrote:
>>>> On 31.03.2020 20:21, Scott Palmer wrote:
>>>>>> Could not resolve all dependencies for configuration ':apps:lucene'.
>>>>>> Multiple build operations failed.
>>>>> java.lang.ExceptionInInitializerError
>>>>> java.lang.NoClassDefFoundError: Could not initialize class
>>>>> sun.security.ssl.SSLContextImpl$TLSContext
>>>>> java.lang.NoClassDefFoundError: Could not initialize class
>>>>> sun.security.ssl.SSLContextImpl$TLSContext
>>>>>> java.lang.ExceptionInInitializerError
>>>>>> java.lang.NoClassDefFoundError: Could not initialize class
>>>>> sun.security.ssl.SSLContextImpl$TLSContext
>>>>>> java.lang.NoClassDefFoundError: Could not initialize class
>>>>> sun.security.ssl.SSLContextImpl$TLSContext
>>>>>
>>>>>
>>>>> This to me looks like it may be failing to make an https connection to
>>> a repository when
>>>>> attempting to download dependencies.
>>>>>
>>>>> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when
>>> running gradle builds, see:
>>>>> https://github.com/gradle/gradle/issues/7842
>>>>>
>>>>> Claims to be fixed, but maybe not?
>>>>>
>>>>> If it is related to Gradle changing java.home while compiling, I wonder
>>> if using --no-parallel
>>>>> might work around it? Of course try with --debug as well to see if it
>>> offers more clues.
>>>> Scott, thank you!
>>>>
>>>> Not having any knowledge about gradle I am unfortunately lost in this
>>> case. However, I used "gradle
>>>> --no-parallel --debug" which did not succeed but created a 1.2 MB text
>>> file which I keep temporarily
>>>> in my DrobBox at: <
>>> https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0
>>>> .
>>>>
>>>> Will have to leave in a few minutes for today so can only try other
>>> things tomorrow.
>>>> ---rony

Re: Seeking help with latest master ...

[Rony G. Flatscher]

On 02.04.2020 21:20, Johan Vos wrote:
> I have no scientific evidence for this, but I remember issues related to SSL 
> with some JDK's as
> well, which may or may not be related to the cacerts file that is bundled.

When hitting this problem the JDK was the same that has worked flawlessly with 
the previous versions
of OpenFX.

It looks as if Java 14 is needed for the latest OpenFX master, at least for my 
installation.

---rony


>
> On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Being stuck (tried the previous working gradle 5.6.4, could get "gradle 
> clean", but not
> further) in
> the end I just tried Java 14 and that allowed me to run "gradle" 
> successfully (currently building
> webkit to get going again). Just wanted to let interested readers know. 
> (Would be great though, if
> it worked with the 11 LTS version as well.)
>
> ---rony
>
>
> On 31.03.2020 20:36, Rony G. Flatscher wrote:
> > On 31.03.2020 20:21, Scott Palmer wrote:
> >>> Could not resolve all dependencies for configuration ':apps:lucene'.
> >>   > Multiple build operations failed.
> >>     java.lang.ExceptionInInitializerError
> >>     java.lang.NoClassDefFoundError: Could not initialize class
> >>    sun.security.ssl.SSLContextImpl$TLSContext
> >>     java.lang.NoClassDefFoundError: Could not initialize class
> >>    sun.security.ssl.SSLContextImpl$TLSContext
> >>  > java.lang.ExceptionInInitializerError
> >>  > java.lang.NoClassDefFoundError: Could not initialize class
> >>    sun.security.ssl.SSLContextImpl$TLSContext
> >>  > java.lang.NoClassDefFoundError: Could not initialize class
> >>    sun.security.ssl.SSLContextImpl$TLSContext
> >>
> >>
> >> This to me looks like it may be failing to make an https connection to 
> a repository when
> >> attempting to download dependencies.
> >>
> >> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when 
> running gradle builds,
> see: 
> >> https://github.com/gradle/gradle/issues/7842
> >>
> >> Claims to be fixed, but maybe not?
> >>
> >> If it is related to Gradle changing java.home while compiling, I 
> wonder if using --no-parallel
> >> might work around it?  Of course try with --debug as well to see if it 
> offers more clues.
> > Scott, thank you!
> >
> > Not having any knowledge about gradle I am unfortunately lost in this 
> case. However, I used 
> "gradle
> > --no-parallel --debug" which did not succeed but created a 1.2 MB text 
> file which I keep
> temporarily
> > in my DrobBox at: 
> <https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0>.
> >
> > Will have to leave in a few minutes for today so can only try other 
> things tomorrow.
> >
> > ---rony
>

Question ad CSR (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"

[Rony G. Flatscher]

Hi Kevin,

thank you for your feedback and actions!

Ad "please create a CSR request and add link to it in JDK-8238080": 
preliminarily researching [CSR
FAQ] (https://wiki.openjdk.java.net/display/csr/CSR+FAQs) the question "Q: How 
do I create a CSR ?"
gets answered with:

> "A: _Do not directly create a CSR from the Create Menu._ JIRA will let you do 
> this right up until
_the moment you try to save it and find your typing was in vain._ Instead you 
should go to the
target bug, select "More", and from the drop down menu select "Create CSR". 
This is required to
properly associate the CSR with the main bug, just as is done for backports.".

Looking at [JDK-8238080] (https://bugs.openjdk.java.net/browse/JDK-8238080) 
there is no possibility
for me to follow the above advice as I have no "More" button/link to select! 
The reason probably
being that I cannot log on.

Once I have the CSR text formulated (may take a little while) what should I do 
with it?

---rony


On 03.04.2020 01:21, Kevin Rushforth wrote:
> Hi Rony,
>
> I see that you updated the PR and sent it for review.
>
> Before we formally review it in the PR, let's finish the discussion as to 
> whether this is a useful
> feature, and if so, what form this feature should take.
>
> From my point of view, this does seem like a useful feature. Would other 
> users of FXML benefit
> from it?
>
> I'm not certain whether we want it to be implicit, compiling the script if 
> the script engine in
> question implements Compilable, or via a new keyword or tag. What are the 
> pros / cons?
>
> What do others think?
>
> In either case, we would need to make sure that this doesn't present any 
> security concerns in the
> presence of a security manager. As long as a user-provided class is on the 
> stack, it will be fine,
> but we would need to ensure that.
>
> -- Kevin
>
>
> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote:
>> After merging master, applying some fixes and changing the title to reflect 
>> the change from WIP to a
>> pull request I would kindly request a review of this pull request!
>>
>> Here the URL: <https://github.com/openjdk/jfx/pull/129>, title changed to: 
>> "8238080: FXMLLoader: if
>> script engines implement javax.script.Compilable compile scripts".
>>
>> ---rony
>>
>>
>> On 28.02.2020 19:22, Rony G. Flatscher wrote:
>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is 
>>> currently in review, and
>>> has an appropriate test unit going with it as well, please review.
>>>
>>> There should be no compatibility issue with this implementation.
>>>
>>> Discussion: another solution could be to not compile by default. Rather 
>>> compile, if some new
>>> information is present with the FXML file which cannot possibly be present 
>>> in existing FXML files.
>>> In this scenario one possible and probably simple solution would be to only 
>>> compile scripts if the
>>> language process instruction (e.g. ) contains an 
>>> appropriate attribute with a
>>> value
>>> indicating that compilation should be carried out (e.g.: compile="true"). 
>>> This way only FXML with
>>> PIs having this attribute set to true would be affected. If desired I could 
>>> try to come up with a
>>> respective solution as well.
>>>
>>> ---rony
>>>
>>> [1] "Implementation and test unit": 
>>> <https://github.com/openjdk/jfx/pull/129>
>>>
>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement 
>>> javax.script.Compilable compile
>>> scripts":
>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>>>
>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with 
>>> FILENAME and ARGV":
>>> <https://github.com/openjdk/jfx/pull/122/commits>
>>>
>>>
>>> On 24.01.2020 16:26, Kevin Rushforth wrote:
>>>
>>>> Thank you for filing this enhancement request. As an enhancement it should 
>>>> be discussed on this
>>>> list before proceeding with a pull request (although a "WIP" or Draft PR 
>>>> can be used to illustrate
>>>> the concept).
>>>>
>>>> For my part, this seems like a reasonable enhancement, as long as there 
>>>> are no compatibility
>>>> issues, but it would be good to hear from application developers who 
>>>> heavily use FXML.
>>

RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Rony G . Flatscher]

TODO: ADD DESCRIPTION OF PROPOSED FIX HERE.

-

Commit messages:
 - Correct error constant.
 - appease the jcheck script, such that that important trailing Whitespace 
error can be resolved (why would jcheck not do it automagically as well as 
expanding tabs?)
 - Merge master, correct ovesights.
 - Merge master
 - JDK-8238080 : FXMLLoader: if script engines implement 
javax.script.Compilable compile scripts
 - corrected wrong test string
 - Removed executable bit from gradlew as this causes an error when
 - Merge branch 'scripttest' into script as requested by reviewer Kevin
 - Incorporating Kevin Rushfort's review comments to this WIP.
 - Incorporating Kevin Rushfort's review comments to this WIP.
 - Removed/replaced white space.
 - Removed/replaced white space.
 - test for  JDK-8234959: 
FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV
 - fix for  JDK-8234959: 
FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

Changes: https://git.openjdk.java.net/jfx/pull/129/files
 Webrev: https://webrevs.openjdk.java.net/jfx/129/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8238080
  Stats: 1003 lines in 17 files changed: 996 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/129.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/129/head:pull/129

PR: https://git.openjdk.java.net/jfx/pull/129

Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"

[Rony G. Flatscher]

After merging master, applying some fixes and changing the title to reflect the 
change from WIP to a
pull request I would kindly request a review of this pull request!

Here the URL: <https://github.com/openjdk/jfx/pull/129>, title changed to: 
"8238080: FXMLLoader: if
script engines implement javax.script.Compilable compile scripts".

---rony


On 28.02.2020 19:22, Rony G. Flatscher wrote:
> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is 
> currently in review, and
> has an appropriate test unit going with it as well, please review.
>
> There should be no compatibility issue with this implementation.
>
> Discussion: another solution could be to not compile by default. Rather 
> compile, if some new
> information is present with the FXML file which cannot possibly be present in 
> existing FXML files.
> In this scenario one possible and probably simple solution would be to only 
> compile scripts if the
> language process instruction (e.g. ) contains an appropriate 
> attribute with a value
> indicating that compilation should be carried out (e.g.: compile="true"). 
> This way only FXML with
> PIs having this attribute set to true would be affected. If desired I could 
> try to come up with a
> respective solution as well.
>
> ---rony
>
> [1] "Implementation and test unit": <https://github.com/openjdk/jfx/pull/129>
>
> [2] "JDK-8238080 : FXMLLoader: if script engines implement 
> javax.script.Compilable compile scripts":
> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>
>
> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with 
> FILENAME and ARGV":
> <https://github.com/openjdk/jfx/pull/122/commits>
>
>
> On 24.01.2020 16:26, Kevin Rushforth wrote:
>
>> Thank you for filing this enhancement request. As an enhancement it should 
>> be discussed on this
>> list before proceeding with a pull request (although a "WIP" or Draft PR can 
>> be used to illustrate
>> the concept).
>>
>> For my part, this seems like a reasonable enhancement, as long as there are 
>> no compatibility
>> issues, but it would be good to hear from application developers who heavily 
>> use FXML.
>>
>> -- Kevin
>>
>>
>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote:
>>> Just filed a RFE with the following information:
>>>
>>>    * Component:
>>>    o JavaFX
>>>
>>>    * Subcomponent:
>>>    o fxml: JavaFX FXML
>>>
>>>    * Synopsis:
>>>    o "FXMLLoader: if script engines implement javax.script.Compilabel 
>>> compile scripts"
>>>
>>>    * Descriptions:
>>>    o "FXMLLoader is able to execute scripts in Java script languages 
>>> (javax.script.ScriptEngine
>>>  implementations) if such a Java script language gets defined as 
>>> the controller language in
>>>  the FXML file.
>>>
>>>  If a script engine implements the javax.script.Compilable 
>>> interface, then such scripts
>>> could
>>>  be compiled and the resulting javax.script.CompiledScript could be 
>>> executed instead using
>>>  its eval() methods.
>>>
>>>  Evaluating the CompiledScript objects may help speed up the 
>>> execution of script
>>> invocations,
>>>  especially for scripts defined for event attributes in FXML 
>>> elements (e.g. like
>>> onMouseMove)
>>>  which may be repetitevly invoked and evaluated."
>>>
>>>    * System /OS/Java Runtime Information:
>>>    o "All systems."
>>>
>>> Received the internal review ID: "9063426"
>>>
>>> ---rony 

Re: Seeking help with latest master ...

[Rony G. Flatscher]

Being stuck (tried the previous working gradle 5.6.4, could get "gradle clean", 
but not further) in
the end I just tried Java 14 and that allowed me to run "gradle" successfully 
(currently building
webkit to get going again). Just wanted to let interested readers know. (Would 
be great though, if
it worked with the 11 LTS version as well.)

---rony


On 31.03.2020 20:36, Rony G. Flatscher wrote:
> On 31.03.2020 20:21, Scott Palmer wrote:
>>> Could not resolve all dependencies for configuration ':apps:lucene'.
>>   > Multiple build operations failed.
>>     java.lang.ExceptionInInitializerError
>>     java.lang.NoClassDefFoundError: Could not initialize class
>>    sun.security.ssl.SSLContextImpl$TLSContext
>>     java.lang.NoClassDefFoundError: Could not initialize class
>>    sun.security.ssl.SSLContextImpl$TLSContext
>>  > java.lang.ExceptionInInitializerError
>>  > java.lang.NoClassDefFoundError: Could not initialize class
>>    sun.security.ssl.SSLContextImpl$TLSContext
>>  > java.lang.NoClassDefFoundError: Could not initialize class
>>    sun.security.ssl.SSLContextImpl$TLSContext
>>
>>
>> This to me looks like it may be failing to make an https connection to a 
>> repository when
>> attempting to download dependencies.
>>
>> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running 
>> gradle builds, see: 
>> https://github.com/gradle/gradle/issues/7842
>>
>> Claims to be fixed, but maybe not?
>>
>> If it is related to Gradle changing java.home while compiling, I wonder if 
>> using --no-parallel
>> might work around it?  Of course try with --debug as well to see if it 
>> offers more clues.
> Scott, thank you!
>
> Not having any knowledge about gradle I am unfortunately lost in this case. 
> However, I used  "gradle
> --no-parallel --debug" which did not succeed but created a 1.2 MB text file 
> which I keep temporarily
> in my DrobBox at: 
> <https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0>.
>
> Will have to leave in a few minutes for today so can only try other things 
> tomorrow.
>
> ---rony

Re: Seeking help with latest master ...

[Rony G. Flatscher]

On 31.03.2020 20:21, Scott Palmer wrote:
>> Could not resolve all dependencies for configuration ':apps:lucene'.
>   > Multiple build operations failed.
>     java.lang.ExceptionInInitializerError
>     java.lang.NoClassDefFoundError: Could not initialize class
>    sun.security.ssl.SSLContextImpl$TLSContext
>     java.lang.NoClassDefFoundError: Could not initialize class
>    sun.security.ssl.SSLContextImpl$TLSContext
>  > java.lang.ExceptionInInitializerError
>  > java.lang.NoClassDefFoundError: Could not initialize class
>    sun.security.ssl.SSLContextImpl$TLSContext
>  > java.lang.NoClassDefFoundError: Could not initialize class
>    sun.security.ssl.SSLContextImpl$TLSContext
>
>
> This to me looks like it may be failing to make an https connection to a 
> repository when
> attempting to download dependencies.
>
> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running 
> gradle builds, see: 
> https://github.com/gradle/gradle/issues/7842
>
> Claims to be fixed, but maybe not?
>
> If it is related to Gradle changing java.home while compiling, I wonder if 
> using --no-parallel
> might work around it?  Of course try with --debug as well to see if it offers 
> more clues.

Scott, thank you!

Not having any knowledge about gradle I am unfortunately lost in this case. 
However, I used  "gradle
--no-parallel --debug" which did not succeed but created a 1.2 MB text file 
which I keep temporarily
in my DrobBox at: 
.

Will have to leave in a few minutes for today so can only try other things 
tomorrow.

---rony

Re: Seeking help with latest master ...

[Rony G. Flatscher]

On 31.03.2020 19:10, Kevin Rushforth wrote:
> That's not the problem. The minimum build number only applies if at the exact 
> minimum JDK version
> in question. You are using 11.0.6 which is > 11 so no problem there.
>
> One last thing to try:
>
> $ rm -rf .gradle buildSrc/.gradle buildSrc/build
>
> In case something is cached there that the newer gradle trips over.

Unfortunately did not resolve the failure:

rony@rony-linux:~/dev/github/openjdk/jfx$ rm -rf build .gradle 
buildSrc/.gradle buildSrc/build
rony@rony-linux:~/dev/github/openjdk/jfx$ gradle --stop
No Gradle daemons are running.
rony@rony-linux:~/dev/github/openjdk/jfx$ gradle clean
Starting a Gradle Daemon, 5 stopped Daemons could not be reused, use 
--status for details

> Configure project :
gradle.gradleVersion: 6.3
OS_NAME: linux
OS_ARCH: amd64
JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64
JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64
java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1
java version: 11.0.6
java build number: 10
jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1
jdk version: 11.0.6
jdk build number: 10
minimum jdk version: 11
minimum jdk build number: 28
GCC version: gcc8.3.0-OL6.4+1.0
cmake version: 3.13.3
ninja version: 1.8.2
ant version: 1.10.5
HAS_JAVAFX_MODULES: false
STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64
CONF: Debug
NUM_COMPILE_THREADS: 8
COMPILE_TARGETS: linux
COMPILE_FLAGS_FILES: buildSrc/linux.gradle
HUDSON_JOB_NAME: not_hudson
HUDSON_BUILD_NUMBER: 
PROMOTED_BUILD_NUMBER: 0
PRODUCT_NAME: OpenJFX
RELEASE_VERSION: 15
RELEASE_SUFFIX: -internal
RELEASE_VERSION_SHORT: 15-internal
RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-191843
RELEASE_VERSION_PADDED: 15.0.0.0
MAVEN_VERSION: 15-internal+0-2020-03-31-191843
UPDATE_STUB_CACHE: false
Building Webkit configuration /Release/ into
/home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux
module: project ':apps' (buildModule=NO)
module: project ':base' (buildModule=YES)
module: project ':controls' (buildModule=YES)
module: project ':fxml' (buildModule=YES)
module: project ':graphics' (buildModule=YES)
module: project ':media' (buildModule=YES)
module: project ':swing' (buildModule=YES)
module: project ':swt' (buildModule=NO)
module: project ':systemTests' (buildModule=NO)
module: project ':web' (buildModule=YES)

FAILURE: Build completed with 2 failures.

1: Task failed with an exception.
---
* Where:
Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176

* What went wrong:
A problem occurred evaluating root project 'jfx'.
> Could not resolve all dependencies for configuration ':apps:lucene'.
   > Multiple build operations failed.
 java.lang.ExceptionInInitializerError
 java.lang.NoClassDefFoundError: Could not initialize class
sun.security.ssl.SSLContextImpl$TLSContext
 java.lang.NoClassDefFoundError: Could not initialize class
sun.security.ssl.SSLContextImpl$TLSContext
  > java.lang.ExceptionInInitializerError
  > java.lang.NoClassDefFoundError: Could not initialize class
sun.security.ssl.SSLContextImpl$TLSContext
  > java.lang.NoClassDefFoundError: Could not initialize class
sun.security.ssl.SSLContextImpl$TLSContext

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or 
--debug option to get
more log output. Run with --scan to get full insights.

==

2: Task failed with an exception.
---
* Where:
Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589

* What went wrong:
A problem occurred configuring root project 'jfx'.
> Failed to notify project evaluation listener.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 

Re: Seeking help with latest master ...

[Rony G. Flatscher]

Hmm, noticed a JDK  "minimum jdk build number: 28" minimum build number. 
Currently using the latest
AdoptOpenJDK 11 LTS.

If that is the problem which JDK would you suggest to use instead?

---rony


On 31.03.2020 18:51, Rony G. Flatscher wrote:
> On 31.03.2020 18:20, Kevin Rushforth wrote:
>> Check your JDK version and gradle version:
>>
>> $ java -version
>> $ gradle -version
>>
>> If they look OK, you might try:
>>
>> $ rm -rf build
>> $ gradle clean
>>
>> and then do a build.
> Thank you, Kevin, unfortunately, it does not work out (it fails at "gradle 
> clean"), using
> adoptOpenjdk 11.0.6 release 10 and gradle 6.3.
>
> Do I need a JDK > 11 to build ?
>
> Here the log of the commands as suggested:
>
> rony@rony-linux:~/dev/github/openjdk/jfx$ java -version
> openjdk version "11.0.6" 2020-01-14
> OpenJDK Runtime Environment (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1)
> OpenJDK 64-Bit Server VM (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1, 
> mixed mode, sharing)
> rony@rony-linux:~/dev/github/openjdk/jfx$ javac -version
> javac 11.0.6
> rony@rony-linux:~/dev/github/openjdk/jfx$ rm -rf build
> rony@rony-linux:~/dev/github/openjdk/jfx$ gradle --stop
> Stopping Daemon(s)
> 1 Daemon stopped
> rony@rony-linux:~/dev/github/openjdk/jfx$ gradle clean
> Starting a Gradle Daemon, 2 stopped Daemons could not be reused, use 
> --status for details
>
> > Configure project :
> gradle.gradleVersion: 6.3
> OS_NAME: linux
> OS_ARCH: amd64
> JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64
> JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64
> java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1
> java version: 11.0.6
> java build number: 10
> jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1
> jdk version: 11.0.6
> jdk build number: 10
> minimum jdk version: 11
> minimum jdk build number: 28
> GCC version: gcc8.3.0-OL6.4+1.0
> cmake version: 3.13.3
> ninja version: 1.8.2
> ant version: 1.10.5
> HAS_JAVAFX_MODULES: false
> STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64
> CONF: Debug
> NUM_COMPILE_THREADS: 8
> COMPILE_TARGETS: linux
> COMPILE_FLAGS_FILES: buildSrc/linux.gradle
> HUDSON_JOB_NAME: not_hudson
> HUDSON_BUILD_NUMBER: 
> PROMOTED_BUILD_NUMBER: 0
> PRODUCT_NAME: OpenJFX
> RELEASE_VERSION: 15
> RELEASE_SUFFIX: -internal
> RELEASE_VERSION_SHORT: 15-internal
> RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-184608
> RELEASE_VERSION_PADDED: 15.0.0.0
> MAVEN_VERSION: 15-internal+0-2020-03-31-184608
> UPDATE_STUB_CACHE: false
> Building Webkit configuration /Release/ into
> /home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux
> module: project ':apps' (buildModule=NO)
> module: project ':base' (buildModule=YES)
> module: project ':controls' (buildModule=YES)
> module: project ':fxml' (buildModule=YES)
> module: project ':graphics' (buildModule=YES)
> module: project ':media' (buildModule=YES)
> module: project ':swing' (buildModule=YES)
> module: project ':swt' (buildModule=NO)
> module: project ':systemTests' (buildModule=NO)
> module: project ':web' (buildModule=YES)
>
> FAILURE: Build completed with 2 failures.
>
> 1: Task failed with an exception.
> ---
> * Where:
> Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176
>
> * What went wrong:
> A problem occurred evaluating root project 'jfx'.
> > Could not resolve all dependencies for configuration ':apps:lucene'.
>    > Multiple build operations failed.
>  java.lang.ExceptionInInitializerError
>  java.lang.NoClassDefFoundError: Could not initialize class
> sun.security.ssl.SSLContextImpl$TLSContext
>  java.lang.NoClassDefFoundError: Could not initialize class
> sun.security.ssl.SSLContextImpl$TLSContext
>   > java.lang.ExceptionInInitializerError
>   > java.lang.NoClassDefFoundError: Could not initialize class
> sun.security.ssl.SSLContextImpl$TLSContext
>   > java.lang.NoClassDefFoundError: Could not initialize class
> sun.security.ssl.SSLContextImpl$TLSContext
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get
> more log output. Run with --scan to get full insights.
> 
> ==
>
> 2: Task failed

Re: Seeking help with latest master ...

[Rony G. Flatscher]

On 31.03.2020 18:20, Kevin Rushforth wrote:
> Check your JDK version and gradle version:
>
> $ java -version
> $ gradle -version
>
> If they look OK, you might try:
>
> $ rm -rf build
> $ gradle clean
>
> and then do a build.

Thank you, Kevin, unfortunately, it does not work out (it fails at "gradle 
clean"), using
adoptOpenjdk 11.0.6 release 10 and gradle 6.3.

Do I need a JDK > 11 to build ?

Here the log of the commands as suggested:

rony@rony-linux:~/dev/github/openjdk/jfx$ java -version
openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1)
OpenJDK 64-Bit Server VM (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1, 
mixed mode, sharing)
rony@rony-linux:~/dev/github/openjdk/jfx$ javac -version
javac 11.0.6
rony@rony-linux:~/dev/github/openjdk/jfx$ rm -rf build
rony@rony-linux:~/dev/github/openjdk/jfx$ gradle --stop
Stopping Daemon(s)
1 Daemon stopped
rony@rony-linux:~/dev/github/openjdk/jfx$ gradle clean
Starting a Gradle Daemon, 2 stopped Daemons could not be reused, use 
--status for details

> Configure project :
gradle.gradleVersion: 6.3
OS_NAME: linux
OS_ARCH: amd64
JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64
JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64
java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1
java version: 11.0.6
java build number: 10
jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1
jdk version: 11.0.6
jdk build number: 10
minimum jdk version: 11
minimum jdk build number: 28
GCC version: gcc8.3.0-OL6.4+1.0
cmake version: 3.13.3
ninja version: 1.8.2
ant version: 1.10.5
HAS_JAVAFX_MODULES: false
STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64
CONF: Debug
NUM_COMPILE_THREADS: 8
COMPILE_TARGETS: linux
COMPILE_FLAGS_FILES: buildSrc/linux.gradle
HUDSON_JOB_NAME: not_hudson
HUDSON_BUILD_NUMBER: 
PROMOTED_BUILD_NUMBER: 0
PRODUCT_NAME: OpenJFX
RELEASE_VERSION: 15
RELEASE_SUFFIX: -internal
RELEASE_VERSION_SHORT: 15-internal
RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-184608
RELEASE_VERSION_PADDED: 15.0.0.0
MAVEN_VERSION: 15-internal+0-2020-03-31-184608
UPDATE_STUB_CACHE: false
Building Webkit configuration /Release/ into
/home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux
module: project ':apps' (buildModule=NO)
module: project ':base' (buildModule=YES)
module: project ':controls' (buildModule=YES)
module: project ':fxml' (buildModule=YES)
module: project ':graphics' (buildModule=YES)
module: project ':media' (buildModule=YES)
module: project ':swing' (buildModule=YES)
module: project ':swt' (buildModule=NO)
module: project ':systemTests' (buildModule=NO)
module: project ':web' (buildModule=YES)

FAILURE: Build completed with 2 failures.

1: Task failed with an exception.
---
* Where:
Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176

* What went wrong:
A problem occurred evaluating root project 'jfx'.
> Could not resolve all dependencies for configuration ':apps:lucene'.
   > Multiple build operations failed.
 java.lang.ExceptionInInitializerError
 java.lang.NoClassDefFoundError: Could not initialize class
sun.security.ssl.SSLContextImpl$TLSContext
 java.lang.NoClassDefFoundError: Could not initialize class
sun.security.ssl.SSLContextImpl$TLSContext
  > java.lang.ExceptionInInitializerError
  > java.lang.NoClassDefFoundError: Could not initialize class
sun.security.ssl.SSLContextImpl$TLSContext
  > java.lang.NoClassDefFoundError: Could not initialize class
sun.security.ssl.SSLContextImpl$TLSContext

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or 
--debug option to get
more log output. Run with --scan to get full insights.

==

2: Task failed with an exception.
---
* Where:
Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589

* What went wrong:
A problem occurred configuring root project 'jfx'.
> Failed to notify project evaluation listener.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get unknown property 'moduleEmptyPublicationJarLinux' for 
task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.
   > Could not get 

Re: [Rev 04] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

Rony G. Flatscher has updated the pull request incrementally with one 
additional commit since the last revision:

  Remove jcheck whitespace error.

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/122/files
  - new: https://git.openjdk.java.net/jfx/pull/122/files/7d867ab8..58c8ce59

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/122/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/122/webrev.03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/122.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/122/head:pull/122

PR: https://git.openjdk.java.net/jfx/pull/122

Re: [Rev 03] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

Rony G. Flatscher has updated the pull request incrementally with one 
additional commit since the last revision:

  Applying the changes according to the review.

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/122/files
  - new: https://git.openjdk.java.net/jfx/pull/122/files/a42fed5c..7d867ab8

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/122/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/122/webrev.02-03

  Stats: 18 lines in 7 files changed: 1 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jfx/pull/122.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/122/head:pull/122

PR: https://git.openjdk.java.net/jfx/pull/122

Re: [Rev 02] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G. Flatscher]

Kevin and Ajit,

thank you very much for your reviews!

Will apply the changes (including changing CRLF to LF) ASAP.

---rony


On 23.03.2020 22:45, Kevin Rushforth wrote:
> On Sat, 21 Mar 2020 19:19:18 GMT, Kevin Rushforth  wrote:
>
>>> Rony G. Flatscher has updated the pull request incrementally with one 
>>> additional commit since the last revision:
>>>
>>>   corrected wrong test string
>> The fix looks good. I left a few comments on the test. One of them is 
>> substantive, the rest are formatting. Once you
>> make those changes, I'll approve it.
> One more minor observation. I noticed the following have DOS line endings:
>
> tests/system/src/testscriptapp1/resources/mymod/META-INF/services/javax.script.ScriptEngineFactory:
>  ASCII text, with
> CRLF line terminators
> tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_bottomscript.rpsl:
>ASCII text, with
> CRLF line terminators
> tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_middlescript.rpsl:
>ASCII text, with
> CRLF line terminators
> tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_topscript.rpsl:
>   ASCII text, with
> CRLF line terminators
>
> Since they aren't source code files, `git jcheck` won't complain, but as long 
> as you are fixing the other issues, would
> you mind fixing these too?
>
> -
>
> PR: https://git.openjdk.java.net/jfx/pull/122

Re: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

On Mon, 2 Mar 2020 16:49:45 GMT, Kevin Rushforth  wrote:

>> Removed executable bits from gradlew (which I manually have added to become 
>> able to run ./gradlew) and pushed it,
>> however the commit has not appeared. Not wanting to add more noise, I stop 
>> until advised differently.
>
> Btw, I recommend to run `sh gradlew ...` so you don't have to change the 
> permission locally.

Is there anything I can do to keep the ball rolling ?

-

PR: https://git.openjdk.java.net/jfx/pull/122

Re: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G. Flatscher]

Hi Kevin,

On 02.03.2020 17:51, Kevin Rushforth wrote:
> On Thu, 27 Feb 2020 14:36:17 GMT, Rony G. Flatscher 
>  wrote:
>
>>> Overall this looks good to me. As I mentioned in PR #123 you should fold 
>>> that the unit test into this PR.
>> Removed executable bits from gradlew (which I manually have added to become 
>> able to run ./gradlew) and pushed it, however the commit has not appeared. 
>> Not wanting to add more noise, I stop until advised differently.
> Btw, I recommend to run `sh gradlew ...` so you don't have to change the 
> permission locally.
>
> -
>
> PR: https://git.openjdk.java.net/jfx/pull/122

thank you very much for this hint!

As you can probably tell I have never really worked with git (other than 
pulling open source
projects for inspection, experiments) I learn my lessons step by step (svn 
would be another story).
Just trying to not bother experts like yourself and others, but then, not 
everything can be
accounted for by a git-rookie! :) When learning that the executable bit caused 
a problem on the
push, I felt quite embarrassed to have caused noise and stopped doing a "chmod 
+x gradlew" (did that
out of pure laziness in the first place to forgo the 'sh' command) and 
restarted doing the 'sh
gradlew ...' (needless to say now that I have never worked with gradle 
beforehand, but being  *very*
impressed about it, making the creation of such complex libraries like JavaFX 
or webkit on Linux a
breeze, wow).

BTW, mistakingly (pressed "Reply" instead of "Reply-to-all") sent my answer to 
your e-mail address
only, resending it via the list now, because currently there seems to be a 
problem with
:

The original message was received at Mon, 2 Mar 2020 17:50:57 GMT
from aserp3030.oracle.com [127.0.0.1]

   - The following addresses had permanent fatal errors -

    (reason: 550 5.1.1 : Recipient address rejected: 
User unknown in local
recipient table)

   - Transcript of session follows -
... while talking to [137.254.59.6]:
>>> DATA
<<< 550 5.1.1 : Recipient address rejected: User 
unknown in local
recipient table
550 5.1.1 ... User unknown
<<< 554 5.5.1 Error: no valid recipients

Best regards

---rony

A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"

[Rony G. Flatscher]

Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is 
currently in review, and
has an appropriate test unit going with it as well, please review.

There should be no compatibility issue with this implementation.

Discussion: another solution could be to not compile by default. Rather 
compile, if some new
information is present with the FXML file which cannot possibly be present in 
existing FXML files.
In this scenario one possible and probably simple solution would be to only 
compile scripts if the
language process instruction (e.g. ) contains an appropriate 
attribute with a value
indicating that compilation should be carried out (e.g.: compile="true"). This 
way only FXML with
PIs having this attribute set to true would be affected. If desired I could try 
to come up with a
respective solution as well.

---rony

[1] "Implementation and test unit": <https://github.com/openjdk/jfx/pull/129>

[2] "JDK-8238080 : FXMLLoader: if script engines implement 
javax.script.Compilable compile scripts":
<https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8238080>

[3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME 
and ARGV":
<https://github.com/openjdk/jfx/pull/122/commits>


On 24.01.2020 16:26, Kevin Rushforth wrote:

> Thank you for filing this enhancement request. As an enhancement it should be 
> discussed on this
> list before proceeding with a pull request (although a "WIP" or Draft PR can 
> be used to illustrate
> the concept).
>
> For my part, this seems like a reasonable enhancement, as long as there are 
> no compatibility
> issues, but it would be good to hear from application developers who heavily 
> use FXML.
>
> -- Kevin
>
>
> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote:
>> Just filed a RFE with the following information:
>>
>>    * Component:
>>    o JavaFX
>>
>>    * Subcomponent:
>>    o fxml: JavaFX FXML
>>
>>    * Synopsis:
>>    o "FXMLLoader: if script engines implement javax.script.Compilabel 
>> compile scripts"
>>
>>    * Descriptions:
>>    o "FXMLLoader is able to execute scripts in Java script languages 
>> (javax.script.ScriptEngine
>>  implementations) if such a Java script language gets defined as the 
>> controller language in
>>  the FXML file.
>>
>>  If a script engine implements the javax.script.Compilable 
>> interface, then such scripts
>> could
>>  be compiled and the resulting javax.script.CompiledScript could be 
>> executed instead using
>>  its eval() methods.
>>
>>  Evaluating the CompiledScript objects may help speed up the 
>> execution of script
>> invocations,
>>  especially for scripts defined for event attributes in FXML 
>> elements (e.g. like
>> onMouseMove)
>>  which may be repetitevly invoked and evaluated."
>>
>>    * System /OS/Java Runtime Information:
>>    o "All systems."
>>
>> Received the internal review ID: "9063426"
>>
>> ---rony 

Re: [Rev 02] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

The pull request has been updated with 1 additional commit.

-

Added commits:
 - a42fed5c: corrected wrong test string

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/122/files
  - new: https://git.openjdk.java.net/jfx/pull/122/files/8821d25a..a42fed5c

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/122/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/122/webrev.01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/122.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/122/head:pull/122

PR: https://git.openjdk.java.net/jfx/pull/122

Re: [Rev 01] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

The pull request has been updated with 6 additional commits.

-

Added commits:
 - 8821d25a: Removed executable bit from gradlew as this causes an error when
 - 799a8148: Merge branch 'scripttest' into script as requested by reviewer 
Kevin
 - 2db31713: Incorporating Kevin Rushfort's review comments to this WIP.
 - 8cf0a6ec: Incorporating Kevin Rushfort's review comments to this WIP.
 - 6e4df77d: Removed/replaced white space.
 - e2519967: test for  
JDK-8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME 
and ARGV

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/122/files
  - new: https://git.openjdk.java.net/jfx/pull/122/files/30539592..8821d25a

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/122/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/122/webrev.00-01

  Stats: 899 lines in 14 files changed: 896 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/122.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/122/head:pull/122

PR: https://git.openjdk.java.net/jfx/pull/122

Re: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

On Wed, 26 Feb 2020 23:37:11 GMT, Kevin Rushforth  wrote:

>> @aghaisas can you also review this?
>
> Overall this looks good to me. As I mentioned in PR #123 you should fold that 
> the unit test into this PR.

Removed executable bits from gradlew (which I manually have added to become 
able to run ./gradlew) and pushed it, however the commit has not appeared. Not 
wanting to add more noise, I stop until advised differently.

-

PR: https://git.openjdk.java.net/jfx/pull/122

Re: Ad suggested test unit for "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV"

[Rony G. Flatscher]

After studying [1], not sure whether one is supposed to announce a WIP here or 
not, so in doubt also
announcing the URL for the suggested test unit (part of the systemTests) for 
those interested in
checking it out: <https://github.com/openjdk/jfx/pull/123>.  To run the 
systemTests tests only one
can issue:

|    ./gradlew -PFULL_TEST=true :systemTests:test --tests ModuleLauncherTest|

This will include the suggested WIP test unit "testscriptapp1".

---rony

[1] "Contributing to OpenJFX": 
<https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md>


On 18.02.2020 14:25, Rony G. Flatscher wrote:
> For creating a test unit to test whether [1] is present or not, it is 
> necessary to have a Java
> script engine to test again. As discussed in a different thread it is not 
> advisable to use any
> concrete, existing Java script engine that is not part of the JDK. Therefore 
> it becomes necessary to
> come up with a proper implementation of javax.script.ScriptEngine and
> javax.script.ScriptEngineFactory to serve for the sole purpose of testing.
>
> I have come up with such a "pseudo script engine" which will log each script 
> invocation together
> with the script code, a copy of the ScriptContext in effect (for later 
> inspection) and the time of
> invocation.
>
> For a test unit it is necessary to have this pseudo script engine loaded via 
> the SPI to be able to
> use from a test application. For this one can define a
> "META-INF/services/javax.script.ScriptEngineFactory" file and/or a 
> "module-info.java" file. In order
> to be as flexible as possible both approaches were chosen (also in mind that 
> others may have a need
> for such a pseudo script engine for testing purposes). This implementation 
> creates a module that
> contains a test application where the ideas and structures are modelled after 
> the "systemTests"
> modules (many thanks to Keving Rushforts for pointing at that!).
>
> The test application will create a JavaFX application that processes some 
> fxml file "demo_01.fxml"
> which defines the pseudo script engine to be used for executing all of the 
> scripts defined in that
> file. The "start" method will fire the Button using  "btn.fire()", 
> "btn.fireEvent( new ActionEvent()
> )", and "btn.fireEvent( new MouseEvent( ... ) )" to have the event scripts 
> executed. As mentioned
> the pseudo script engine will log each invocation.
>
> Upon return of the "start" method the test application's main method will 
> fetch the log of
> invocations from the pseudo script engine and then assert that the sequence 
> of invocations, the
> scripts and the ScriptContext Bindings are correct with respect to some 
> "demo_01.fxml". This not
> only asserts the proper existence of the entries "javax.script.filename" 
> (also the proper values of
> the file names) and "javax.script.argv" in the engine Bindings, but also 
> whether the global Bindings
> are correctly defined and their values (and types) are correct. These 
> assertion tests are dependent
> on a) how FXMLLoader populates the ScriptContext Bindings and b) how the test 
> case in form of the
> fxml-file and the supplied pseudo scripts is formulated.
>
> The test unit uses assertion methods of its own (like the other module based 
> tests) and if it ends
> with an exit code of 0 it has passed. In the case of assertion errors (or 
> unexpected errors) an
> appropriate error message with a stack trace is given and a non-zero exit 
> code is returned via
> "System.exit()" (again modeled after/copied from the other module tests).
>
> To make this test unit as simple as possible the module includes the pseudo 
> script engine (it is not
> a separate module). It needs to be run on its own JVM (as is the case with 
> the other module tests).
>
> Any comments, questions, suggestions?
>
> ---rony
>
> [1] "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with 
> FILENAME and ARGV":
> <https://bugs.openjdk.java.net/browse/JI-9062887>
>

Re: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

On Sun, 23 Feb 2020 14:54:32 GMT, Rony G. Flatscher 
 wrote:

>> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV
> 
> OK, forgot to submit an explanatory text related to this fix. Posted [1] 
> which explains the problem and the suggested solution for discussion. 
> 
> - This pull request relates to: 
> <https://bugs.openjdk.java.net/browse/JDK-8234959>
> 
> - Brief background: the controller code for a FXML file can be written in
>   any of the Java script languages that implement the javax.script framework
>   introduced with Java 6
> 
> There are three possible types of script code definitions possible in fxml 
> files:
> 
> 1. in an empty script element where the source attribute denotes an external 
> file
>that contains the code, e.g.:
> 
>  
> 
>This pull request uses the source attribute value as the filename.
> 
>There are no arguments to be supplied.
> 
> 2. text of a script element, e.g.:
> 
>   say 'code executed at:' .dateTime~new 
> 
>or:
> 
>   
> 
>This pull request uses the fxml-filename appended with the string
>"-script_starting_at_line_" and the starting line number of the code.
> 
>There are no arguments to be supplied.
> 
>Reasonings:
> 
> - in the case that multiple fxml files employ script code it is 
> important
>   to learn the name of the fxml file that hosts the code that gets 
> executed
> 
> - the dash after the fxml filename is meant to ease parsing
> 
> - in the case that there are multiple fx:script elements in a fxml 
> file
>   with inline code it is important to learn in which line the code 
> starts
>   that gets executed
> 
> - the decorated filename thereby becomes self documentary and 
> unambiguous to
>   the script code developer when debugging
> 
> 
> 3. PCDATA text in an event attribute which by convention starts with "on", 
> e.g. "onAction":
> 
>
> 
>This pull request uses the fxml-filename appended with a dash "-", 
> appended with the
>name of the event attribute, the string 
> "_attribute_in_element_ending_at_line_" and
>the ending line number of the element.
> 
>In the ScriptEventHandler constructor the decorated filename gets stored 
> in addition
>to the script and the scriptEngine.
> 
>Each time the event fires the event object argument will be stored in a 
> copy of the
>engineBindings with the index EVENT_KEY as well as with a single capacity 
> Object array
>stored with the index ScriptEngine.ARGV and the filename with the index
>ScriptEngine.FILENAME. The script's evaluation will get this 
> engineBindings as
>its ENGINE_SCOPE Bindings supplied.
> 
>Reasonings:
> 
> - in the case that multiple fxml files employ script code it is 
> important
>   to learn the name of the fxml file that hosts the event code that 
> gets
>   executed
> 
> - the dash after the fxml filename is meant to ease parsing
> 
> - in the case that there are multiple event attributes in elements
>   in a fxml file it is important to learn which event attribute in 
> which
>   element hosts the event script code that gets executed
> 
> - the decorated filename thereby becomes self documentary and 
> unambiguous to
>   the script code developer when debugging
> 
> - the structural change to the constructor (adding the decorated 
> filename as
>   a third argument) of the private static ScriptEventHandler class is 
> confined
>   to the FXMLLoader class and has no side effects
> 
> [1] "Ad suggested test unit for 'JDK-8234959 FXMLLoader does not populate 
> ENGINE_SCOPE Bindings with FILENAME and ARGV'": 
> <https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-February/025104.html>

Sorry, mixed up the link with the test unit WIP! :(

This is the correct link with the explanatory text related to this suggested 
fix. Posted [1] which explains the problem and the suggested solution for 
discussion. 
[1] 'Ad suggested fix for "JDK-8234959 FXMLLoader does not populate 
ENGINE_SCOPE Bindings with FILENAME and ARGV"': 
<https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-February/025102.html>

-

PR: https://git.openjdk.java.net/jfx/pull/122

Re: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

On Sat, 22 Feb 2020 15:39:35 GMT, Rony G. Flatscher 
 wrote:

> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

OK, forgot to submit an explanatory text related to this fix. Posted [1] which 
explains the problem and the suggested solution for discussion. 

- This pull request relates to: 
<https://bugs.openjdk.java.net/browse/JDK-8234959>

- Brief background: the controller code for a FXML file can be written in
  any of the Java script languages that implement the javax.script framework
  introduced with Java 6

There are three possible types of script code definitions possible in fxml 
files:

1. in an empty script element where the source attribute denotes an external 
file
   that contains the code, e.g.:

 

   This pull request uses the source attribute value as the filename.

   There are no arguments to be supplied.

2. text of a script element, e.g.:

  say 'code executed at:' .dateTime~new 

   or:

  

   This pull request uses the fxml-filename appended with the string
   "-script_starting_at_line_" and the starting line number of the code.

   There are no arguments to be supplied.

   Reasonings:

- in the case that multiple fxml files employ script code it is 
important
  to learn the name of the fxml file that hosts the code that gets 
executed

- the dash after the fxml filename is meant to ease parsing

- in the case that there are multiple fx:script elements in a fxml file
  with inline code it is important to learn in which line the code 
starts
  that gets executed

- the decorated filename thereby becomes self documentary and 
unambiguous to
  the script code developer when debugging


3. PCDATA text in an event attribute which by convention starts with "on", e.g. 
"onAction":

   

   This pull request uses the fxml-filename appended with a dash "-", appended 
with the
   name of the event attribute, the string 
"_attribute_in_element_ending_at_line_" and
   the ending line number of the element.

   In the ScriptEventHandler constructor the decorated filename gets stored in 
addition
   to the script and the scriptEngine.

   Each time the event fires the event object argument will be stored in a copy 
of the
   engineBindings with the index EVENT_KEY as well as with a single capacity 
Object array
   stored with the index ScriptEngine.ARGV and the filename with the index
   ScriptEngine.FILENAME. The script's evaluation will get this engineBindings 
as
   its ENGINE_SCOPE Bindings supplied.

   Reasonings:

- in the case that multiple fxml files employ script code it is 
important
  to learn the name of the fxml file that hosts the event code that gets
  executed

- the dash after the fxml filename is meant to ease parsing

- in the case that there are multiple event attributes in elements
  in a fxml file it is important to learn which event attribute in which
  element hosts the event script code that gets executed

- the decorated filename thereby becomes self documentary and 
unambiguous to
  the script code developer when debugging

- the structural change to the constructor (adding the decorated 
filename as
  a third argument) of the private static ScriptEventHandler class is 
confined
  to the FXMLLoader class and has no side effects

[1] "Ad suggested test unit for 'JDK-8234959 FXMLLoader does not populate 
ENGINE_SCOPE Bindings with FILENAME and ARGV'": 
<https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-February/025104.html>

-

PR: https://git.openjdk.java.net/jfx/pull/122

RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

[Rony G . Flatscher]

…9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV

-

Commits:
 - 30539592: Removed/replaced white space.
 - 5c33d590: fix for  
JDK-8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME 
and ARGV

Changes: https://git.openjdk.java.net/jfx/pull/122/files
 Webrev: https://webrevs.openjdk.java.net/jfx/122/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234959
  Stats: 18 lines in 1 file changed: 8 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/122.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/122/head:pull/122

PR: https://git.openjdk.java.net/jfx/pull/122

Re: Request for adding my github userid ..

[Rony G. Flatscher]

On 22.02.2020 17:33, Philip Race wrote:
> What openjdk ID would this be associated with ?

8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and 
ARGV #122

One PR is the fix another one is dubbed as WIP and has the test unit for this 
bug (such that one can
apply it before and after the fix).

> I don't see a Rony Flatscher in the census : https://openjdk.java.net/census
>
> Rony, Have you made contributions and been granted author status ?
No, this is the first time I try to contribute code.
> If yes, where is it on that page ? If not, then you need to make contributions
> (not just sign the OCA) before you get author status and until then there is 
> nothing
> with which to associate your github id.

Hmm, how should I then submit a fix/a pull request?

The OCA was processed in 2017-03-01 (reported by Dalibor Topic), as suggested I 
introduced myself in
[1]. However, for various reasons I got side tracked and only came back this 
last November.

@Kevin: thank you for your advice, did comment on both PR

---rony

[1] "Introduction": 
<https://mail.openjdk.java.net/pipermail/discuss/2017-March/004160.html>



>
> On 2/22/20, 8:27 AM, Kevin Rushforth wrote:
>> What you need to do is this:
>>
>> > Once you have signed the OCA, please let us know by writing `/signed` in a 
>> > comment in this pull
>> request.
>>
>> Omit the quotes in the command.
>>
>> This will alert the Skara maintainers to check your OCA status and make the 
>> association.
>>
>> -- Kevin
>>
>>
>> On 2/22/2020 8:20 AM, Rony G. Flatscher wrote:
>>> Trying to place my first pull requests via github and received the 
>>> following e-mail:
>>>
>>> --- cut ---
>>>
>>> Hi ronyfla, welcome to this OpenJDK project and thanks for contributing!
>>>
>>> We do not recognize you as Contributor 
>>> <https://openjdk.java.net/bylaws#contributor> and need to
>>> ensure you have signed the Oracle Contributor Agreement (OCA). If you have 
>>> not signed the OCA,
>>> please follow the instructions 
>>> <https://www.oracle.com/technetwork/community/oca-486395.html>.
>>> Please fill in your GitHub username in the "Username" field of the 
>>> application. Once you have
>>> signed
>>> the OCA, please let us know by writing |/signed| in a comment in this pull 
>>> request.
>>>
>>> If you already are an OpenJDK Author 
>>> <https://openjdk.java.net/bylaws#author>, Committer
>>> <https://openjdk.java.net/bylaws#committer> or Reviewer 
>>> <https://openjdk.java.net/bylaws#reviewer>,
>>> please click here 
>>> <https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300=1>
>>>  to
>>> open a new issue so that we can record that fact. Please use "Add GitHub 
>>> user ronyfla" as summary
>>> for the issue.
>>>
>>> If you are contributing this work on behalf of your employer and your 
>>> employer has signed the OCA,
>>> please let us know by writing |/covered| in a comment in this pull request.
>>>
>>> --- cut ---
>>>
>>> So I am kindly requesting to associate my github user id 'ronyfla' with my 
>>> signed OCA form such
>>> that
>>> the pull requests can go forward.
>>>
>>> TIA
>>>
>>> ---rony
>>>
>>> P.S.: In the meantime I have changed the github e-mail address for 
>>> 'ronyfla' to the one in the OCA
>>> if that makes a difference.

Request for adding my github userid ..

[Rony G. Flatscher]

Trying to place my first pull requests via github and received the following 
e-mail:

--- cut ---

Hi ronyfla, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor 
 and need to
ensure you have signed the Oracle Contributor Agreement (OCA). If you have not 
signed the OCA,
please follow the instructions 
.
Please fill in your GitHub username in the "Username" field of the application. 
Once you have signed
the OCA, please let us know by writing |/signed| in a comment in this pull 
request.

If you already are an OpenJDK Author , 
Committer
 or Reviewer 
,
please click here 
 to
open a new issue so that we can record that fact. Please use "Add GitHub user 
ronyfla" as summary
for the issue.

If you are contributing this work on behalf of your employer and your employer 
has signed the OCA,
please let us know by writing |/covered| in a comment in this pull request.

--- cut ---

So I am kindly requesting to associate my github user id 'ronyfla' with my 
signed OCA form such that
the pull requests can go forward.

TIA

---rony

P.S.: In the meantime I have changed the github e-mail address for 'ronyfla' to 
the one in the OCA
if that makes a difference.

Re: Question ad running the "systemTests" module tests ...

[Rony G. Flatscher]

Hi Kevin,

On 20.02.2020 14:03, Kevin Rushforth wrote:
> None of the apps underneath testapp* are "tests", but are rather auxiliary 
> applications that are
> run as apps in a separate process by a test. The test itself must be 
> somewhere under
> tests/system/src/test/java.
>
> For example, the test class ModuleLauncherTest is in 
> tests/system/src/test/java/test/launchertest.
> You probably need to do something similar.

thanks to your information I was able to succeed!

The new modular app needs to be added to
"tests/system/src/test/java/test/launchertest/ModuleLauncherTest.java". To do 
so, one needs (in this
example the modular app is "testapp7" which includes a package named "myapp7" 
which contains the
test "FXMLScriptTest" class):

  * to add (copy and adjust) a private field (a String) in this case named 
"modulePath7" which value
gets fetched from a System property "launchertest.testapp7.module.path" 
which gets used in the
test method that needs to be added as well (see next item)

  * then at the end add a new Test method:

@Test (timeout = 15000)
private void testModuleFXMLScriptTest() throws Exception {
   doTestLaunchModule(modulePath7, "myapp7.FXMLScriptTest");
}

To run the modular tests only, one can issue therefore:

    ./gradlew  -PFULL_TEST=true :systemTests:test --tests ModuleLauncherTest

---rony


> On 2/20/2020 1:31 AM, Rony G. Flatscher wrote:
>> Kevin,
>>
>> thank you very much for your information!
>>
>> On 19.02.2020 20:44, Kevin Rushforth wrote:
>>> First, make sure that your test class name ends with exactly the string 
>>> "Test".
>> Renamed the class such that it ends in "Test" ("FXMLScriptTest"), however 
>> this does not cause the
>> class to be loaded from the modular app and its main() method to be run 
>> using "./gradlew
>> -PFULL_TEST=true :systemTests:test".
>>
>> All the "systemTests" modular applications (cf. 
>> "jfx/tests/system/src/testapp{1..6}") do not contain
>> any classes that end in the string "Test"! Rather all the classes that carry 
>> out assertions possess
>> a main() method that controls the execution and the assertions (usually they 
>> extend Application and
>> implement the start() method, in which the test methods get triggered).
>>
>> So that led me to believe that in the case of these system tests the test 
>> runner inspects all
>> classes and if they contain a main() method just executes it and upon return 
>> the launcher inspects
>> the return code to determine whether the system test run of that class was 
>> successful or not.
>>
>> When trying to run test classes individually in the system tests, the 
>> "--tests" filter comes up with
>> an error, e.g. for
>>
>>     ./gradlew -PFULL_TEST=true :systemTests:test --tests FXMLScriptTest
>>
>> or for any other of the already existing system tests, e.g.:
>>
>>     ./gradlew -PFULL_TEST=true :systemTests:test --tests AppFXMLOpened
>>
>> [The above system test class "AppFXMLOpened" is part of the "testapp6" 
>> modular test and located in
>> the package "myapp6". Note, the class name does not end in "Test".]
>>
>> So maybe there is another way to run/launch these system test modular apps 
>> (maybe also
>> individually)?
>>
>> ---rony
>>
>>

Re: Question ad running the "systemTests" module tests ...

[Rony G. Flatscher]

Kevin,

thank you very much for your information!

On 19.02.2020 20:44, Kevin Rushforth wrote:
> First, make sure that your test class name ends with exactly the string 
> "Test".

Renamed the class such that it ends in "Test" ("FXMLScriptTest"), however this 
does not cause the
class to be loaded from the modular app and its main() method to be run using 
"./gradlew
-PFULL_TEST=true :systemTests:test".

All the "systemTests" modular applications (cf. 
"jfx/tests/system/src/testapp{1..6}") do not contain
any classes that end in the string "Test"! Rather all the classes that carry 
out assertions possess
a main() method that controls the execution and the assertions (usually they 
extend Application and
implement the start() method, in which the test methods get triggered).

So that led me to believe that in the case of these system tests the test 
runner inspects all
classes and if they contain a main() method just executes it and upon return 
the launcher inspects
the return code to determine whether the system test run of that class was 
successful or not.

When trying to run test classes individually in the system tests, the "--tests" 
filter comes up with
an error, e.g. for

   ./gradlew -PFULL_TEST=true :systemTests:test --tests FXMLScriptTest

or for any other of the already existing system tests, e.g.:

   ./gradlew -PFULL_TEST=true :systemTests:test --tests AppFXMLOpened

[The above system test class "AppFXMLOpened" is part of the "testapp6" modular 
test and located in
the package "myapp6". Note, the class name does not end in "Test".]

So maybe there is another way to run/launch these system test modular apps 
(maybe also individually)?

---rony

Question ad running the "systemTests" module tests ...

[Rony G. Flatscher]

"build.gradle" contains the project ":systemTests" which defines tests that 
each run on a separate
JVM and use their own Assert methods defined in respective Util.java. They 
signal success according
to the values defined in "Constants.java".

The module test "testapp7" that I wrote mimickries the existing "testapp6" 
module in its layout.
"testapp7" has been successfully added to the list of test modules and got 
compiled successfully,
such that it is possible to run the "testapp7" module from the command line and 
it behaves as
expected given the data and assertions carried out.

However, when running "./gradlew systemTests test" that module test "testapp7" 
does not get executed
(and perhaps none of the other module tests) it seems, although "FULL_TEST" was 
set to "true" in
"build.gradle" such that the module tests should get "enabled" therefore.

Is there something else to take into account or is there some other task that I 
need to use?

Any help, pointer highly appreciated!

---rony

Ad suggested test unit for "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV"

[Rony G. Flatscher]

For creating a test unit to test whether [1] is present or not, it is necessary 
to have a Java
script engine to test again. As discussed in a different thread it is not 
advisable to use any
concrete, existing Java script engine that is not part of the JDK. Therefore it 
becomes necessary to
come up with a proper implementation of javax.script.ScriptEngine and
javax.script.ScriptEngineFactory to serve for the sole purpose of testing.

I have come up with such a "pseudo script engine" which will log each script 
invocation together
with the script code, a copy of the ScriptContext in effect (for later 
inspection) and the time of
invocation.

For a test unit it is necessary to have this pseudo script engine loaded via 
the SPI to be able to
use from a test application. For this one can define a
"META-INF/services/javax.script.ScriptEngineFactory" file and/or a 
"module-info.java" file. In order
to be as flexible as possible both approaches were chosen (also in mind that 
others may have a need
for such a pseudo script engine for testing purposes). This implementation 
creates a module that
contains a test application where the ideas and structures are modelled after 
the "systemTests"
modules (many thanks to Keving Rushforts for pointing at that!).

The test application will create a JavaFX application that processes some fxml 
file "demo_01.fxml"
which defines the pseudo script engine to be used for executing all of the 
scripts defined in that
file. The "start" method will fire the Button using  "btn.fire()", 
"btn.fireEvent( new ActionEvent()
)", and "btn.fireEvent( new MouseEvent( ... ) )" to have the event scripts 
executed. As mentioned
the pseudo script engine will log each invocation.

Upon return of the "start" method the test application's main method will fetch 
the log of
invocations from the pseudo script engine and then assert that the sequence of 
invocations, the
scripts and the ScriptContext Bindings are correct with respect to some 
"demo_01.fxml". This not
only asserts the proper existence of the entries "javax.script.filename" (also 
the proper values of
the file names) and "javax.script.argv" in the engine Bindings, but also 
whether the global Bindings
are correctly defined and their values (and types) are correct. These assertion 
tests are dependent
on a) how FXMLLoader populates the ScriptContext Bindings and b) how the test 
case in form of the
fxml-file and the supplied pseudo scripts is formulated.

The test unit uses assertion methods of its own (like the other module based 
tests) and if it ends
with an exit code of 0 it has passed. In the case of assertion errors (or 
unexpected errors) an
appropriate error message with a stack trace is given and a non-zero exit code 
is returned via
"System.exit()" (again modeled after/copied from the other module tests).

To make this test unit as simple as possible the module includes the pseudo 
script engine (it is not
a separate module). It needs to be run on its own JVM (as is the case with the 
other module tests).

Any comments, questions, suggestions?

---rony

[1] "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with 
FILENAME and ARGV":

Re: Question ad creating a testcase that needs a jar on class- or module path

[Rony G. Flatscher]

Over the weekend I was finally able to finalize the test unit in form of a 
module. Kept it as simple
as possible (but it includes a pseudo script engine).

May I just ask a few questions, before proceeding with submitting one or two 
PRs:

  * Every new program needs the Oracle license header at the top?

  * Would it be o.k. to dual license (AL 2.0 for the pseudo scripting engine)?

  o If not (it probably would introduce noise and problems) it would not be 
a real problem as I
always can create a separate package using only the code that was 
authored by myself.

  * Where shall I explain/document how the test unit works, here in the mailing 
list or with the PR?

  o If the latter, then it would probably be a good idea to submit the test 
unit separately from
the PR for fixing the bug as that will have its own set of 
explanations/documentations
(briefly discussing the three scenarious how a script controller may 
define scripts and why
the filenames were picked the way they are).

  * Maybe the explanations/documentations for the bug fix should be posted here 
upfront for discussion?

---rony


On 03.02.2020 15:04, Rony G. Flatscher wrote:

> Hi Kevin,
>
> On 31.01.2020 16:38, Kevin Rushforth wrote:
>> And if you need a modular jar, you might look at ModuleLauncherTest instead.
> thank you very much for this important hint as well!
>
> Having no knowledge about gradle it will take me a while to research and 
> digest, but this definitely
> helps me to jump start to the section where tests get carried out with 
> separately configured JVMs.
>
> Would it be o.k. to first submit a pull request for JDK-8234959
> <https://bugs.openjdk.java.net/browse/JDK-8234959> and later, when an 
> appropriate test unit using
> the SPI dependent pseudo script engine is available submitting the test app 
> with different pull
> request? Or would it be better to submit both with the same pull request?
>
> ---rony

Re: Question ad creating a testcase that needs a jar on class- or module path

[Rony G. Flatscher]

Hi Kevin,

On 31.01.2020 16:38, Kevin Rushforth wrote:
> And if you need a modular jar, you might look at ModuleLauncherTest instead.

thank you very much for this important hint as well!

Having no knowledge about gradle it will take me a while to research and 
digest, but this definitely
helps me to jump start to the section where tests get carried out with 
separately configured JVMs.

Would it be o.k. to first submit a pull request for JDK-8234959
 and later, when an 
appropriate test unit using
the SPI dependent pseudo script engine is available submitting the test app 
with different pull
request? Or would it be better to submit both with the same pull request?

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

Question ad creating a testcase that needs a jar on class- or module path

[Rony G. Flatscher]

How would one go about creating a testcase that needs a jar-file either on the 
class- or module path?

Are there any test units that would demonstrate how to do it? If not, what 
approach would you
suggest (and if so, are there any samples already somewhere to study)?

---

Background: for creating a testcase using a pseudo script engine 
("RgfPseudoScriptEngine") that logs
its invocations with the script context Bindings for each invocation and which 
then will be analyzed
and used for the test assertions, there is a need to have the pseudo script 
engine made available
via the Java scripting framework.

There is a jar-file (that includes the sources as well) with the necessary 
definitions:

  * via class path: "META-INF/services/javax.script.ScriptEngineFactory" entry:

rgf.scriptEngine.RgfPseudoScriptEngineFactory

  * via module path which will use the information in "module-info.java":

module rgf.scriptEngine {
requires java.scripting;
provides javax.script.ScriptEngineFactory with 
rgf.scriptEngine.RgfPseudoScriptEngineFactory;
exports rgf.scriptEngine;   
}

TIA,

---rony

Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"

[Rony G. Flatscher]

On 24.01.2020 16:26, Kevin Rushforth wrote:
> Thank you for filing this enhancement request. As an enhancement it should be 
> discussed on this
> list before proceeding with a pull request (although a "WIP" or Draft PR can 
> be used to illustrate
> the concept).
Sure, will do after creating an appropriate PR for adding the ARGV and FILENAME 
entries to the
engine scope bindings [1] (may take a little while).
> For my part, this seems like a reasonable enhancement, as long as there are 
> no compatibility
> issues, but it would be good to hear from application developers who heavily 
> use FXML.

+1

---rony


[1] https://bugs.openjdk.java.net/browse/JDK-8234959

>
>
> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote:
>> Just filed a RFE with the following information:
>>
>>    * Component:
>>    o JavaFX
>>
>>    * Subcomponent:
>>    o fxml: JavaFX FXML
>>
>>    * Synopsis:
>>    o "FXMLLoader: if script engines implement javax.script.Compilabel 
>> compile scripts"
>>
>>    * Descriptions:
>>    o "FXMLLoader is able to execute scripts in Java script languages 
>> (javax.script.ScriptEngine
>>  implementations) if such a Java script language gets defined as the 
>> controller language in
>>  the FXML file.
>>
>>  If a script engine implements the javax.script.Compilable 
>> interface, then such scripts
>> could
>>  be compiled and the resulting javax.script.CompiledScript could be 
>> executed instead using
>>  its eval() methods.
>>
>>  Evaluating the CompiledScript objects may help speed up the 
>> execution of script
>> invocations,
>>  especially for scripts defined for event attributes in FXML 
>> elements (e.g. like
>> onMouseMove)
>>  which may be repetitevly invoked and evaluated."
>>
>>    * System /OS/Java Runtime Information:
>>    o "All systems."
>>
>> Received the internal review ID: "9063426"
>>
>> ---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
>>> <https://bugs.openjdk.java.net/browse/JDK-8234959>
>>>
>>> [2] https://bugs.openjdk.java.net/browse/JI-9062887
>>> <https://bugs.openjdk.java.net/browse/JI-9062887>
>>>
>>> [3] https://github.com/openjdk/jfx <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

"Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts"

[Rony G. Flatscher]

Just filed a RFE with the following information:

  * Component:
  o JavaFX

  * Subcomponent:
  o fxml: JavaFX FXML

  * Synopsis:
  o "FXMLLoader: if script engines implement javax.script.Compilabel 
compile scripts"

  * Descriptions:
  o "FXMLLoader is able to execute scripts in Java script languages 
(javax.script.ScriptEngine
implementations) if such a Java script language gets defined as the 
controller language in
the FXML file.

If a script engine implements the javax.script.Compilable interface, 
then such scripts could
be compiled and the resulting javax.script.CompiledScript could be 
executed instead using
its eval() methods.

Evaluating the CompiledScript objects may help speed up the execution 
of script invocations,
especially for scripts defined for event attributes in FXML elements 
(e.g. like onMouseMove)
which may be repetitevly invoked and evaluated."

  * System /OS/Java Runtime Information:
  o "All systems."

Received the internal review ID: "9063426"

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

[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

[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
> <https://www.dropbox.com/s/l4uesrwm0iw5vb9/testcaseFXMLLoaderScriptEngines.zip?dl=0>.
>
> ---rony
>
> On 21.11.2019 15:29, Rony G. Flatscher wrote:
>> On 15.11.2019 16:08, Rony G. Flatscher wrote:
>>> On 14.11.2019 22:57, Kevin Rushforth wrote:
>>>> On 11/14/2019 10:12 AM, Rony G. Flatscher wrote:
>>>>> On 14.11.2019 16:34, Rony G. Flatscher wrote:
>>>>>> On 13.11.2019 19:50, Kevin Rushforth wrote:
>>>>>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote:
>>>>> ... cut ...
>>>>>>>> To reproduce the testcase one would need ooRexx and the Java bridge 
>>>>>>>> BSF4ooRexx (all
>>>>>>>> opensource) for
>>>>>>>> which I could come up with a zip-archive (assuming binaries within 
>>>>>>>> should be 64-bit) and a
>>>>>>>> script to
>>>>>>>> set up the environment either for Windows, Linux or MacOS, whatever 
>>>>>>>> you advise. Would that be
>>>>>>>> o.k.?
>>>>>>> We prefer not to rely on third-party libraries for test cases. In any 
>>>>>>> case we would not be able to
>>>>>>> use that for a regression test / unit test.
>>>>> If test units really seem to be important in this particular case, one 
>>>>> possibility would be to
>>>>> create a minimalistic ScriptEngine implementation in pure Java just for 
>>>>> the sole purpose to allow
>>>>> the creation of a test unit that is able to assert that FXMLLoader puts 
>>>>> the ScriptEngine.ARGV and
>>>>> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having 
>>>>> the ScriptEngine's eval()
>>>>> methods return the ScriptContext at invocation time in order to allow 
>>>>> inspection of the Bindings.
>>>>> This way it would become also possible to write in addition test units 
>>>>> that also check whether all
>>>>> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE 
>>>>> Bindings.
>>>> Something like that seems reasonable, and would avoid a dependence on 
>>>> Nashorn, which in addition
>>>> to having all the problems you mentioned, is deprecated for removal.
>>>>
>>>>> However,
>>>> Did you have something more to add?
>>> No, sorry for that. Rewrote my e-mail and had sent it too early by mistake 
>>> and without noticing.
>>>
>>> Will study all the procedures and create a testcase to be submitted at 
>>> <https://bugreport.java.com/>
>>> as per your advice (and will report back under this thread once submitted). 
>>> The testcase would use
>>> an artificial ScriptEngine implementation that could be used for testunit 
>>> testing as well. This
>>> might take a while due to other obligations that I will have to meet during 
>>> the next few days.
>>>
>>> ---rony
>> O.K., so came up with a test case that contains an artificial script engine 
>> implementation for
>> logging the eval() invocations together with the scripts to execute and the 
>> ScriptContext
>> ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is 
>> meant to be also usable
>> for creating script engine related test units for Java script hosts.)
>>
>> Packaged the source and binaries of that script engine as jar file that one 
>> merely needs to put on
>> the CLASSPATH or add as a module.
>>
>> An updated FXMLLoader patch suggesting a fix is included as well. This 
>> version appends the line
>> number to the file name if the script to be evaluated is embedded in the 
>> fxml-file, such that in
>> case of an error it becomes possible to quickly find it in larger fxml files.
>>
>> With the zip-archive done I went to the Oracle Java Bug Database and just 
>> entered a bug report at
>> <https://bugreport.java.

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
<https://www.dropbox.com/s/l4uesrwm0iw5vb9/testcaseFXMLLoaderScriptEngines.zip?dl=0>.

---rony

On 21.11.2019 15:29, Rony G. Flatscher wrote:
> On 15.11.2019 16:08, Rony G. Flatscher wrote:
>> On 14.11.2019 22:57, Kevin Rushforth wrote:
>>> On 11/14/2019 10:12 AM, Rony G. Flatscher wrote:
>>>> On 14.11.2019 16:34, Rony G. Flatscher wrote:
>>>>> On 13.11.2019 19:50, Kevin Rushforth wrote:
>>>>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote:
>>>> ... cut ...
>>>>>>> To reproduce the testcase one would need ooRexx and the Java bridge 
>>>>>>> BSF4ooRexx (all
>>>>>>> opensource) for
>>>>>>> which I could come up with a zip-archive (assuming binaries within 
>>>>>>> should be 64-bit) and a
>>>>>>> script to
>>>>>>> set up the environment either for Windows, Linux or MacOS, whatever you 
>>>>>>> advise. Would that be
>>>>>>> o.k.?
>>>>>> We prefer not to rely on third-party libraries for test cases. In any 
>>>>>> case we would not be able to
>>>>>> use that for a regression test / unit test.
>>>> If test units really seem to be important in this particular case, one 
>>>> possibility would be to
>>>> create a minimalistic ScriptEngine implementation in pure Java just for 
>>>> the sole purpose to allow
>>>> the creation of a test unit that is able to assert that FXMLLoader puts 
>>>> the ScriptEngine.ARGV and
>>>> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having 
>>>> the ScriptEngine's eval()
>>>> methods return the ScriptContext at invocation time in order to allow 
>>>> inspection of the Bindings.
>>>> This way it would become also possible to write in addition test units 
>>>> that also check whether all
>>>> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE 
>>>> Bindings.
>>> Something like that seems reasonable, and would avoid a dependence on 
>>> Nashorn, which in addition
>>> to having all the problems you mentioned, is deprecated for removal.
>>>
>>>> However,
>>> Did you have something more to add?
>> No, sorry for that. Rewrote my e-mail and had sent it too early by mistake 
>> and without noticing.
>>
>> Will study all the procedures and create a testcase to be submitted at 
>> <https://bugreport.java.com/>
>> as per your advice (and will report back under this thread once submitted). 
>> The testcase would use
>> an artificial ScriptEngine implementation that could be used for testunit 
>> testing as well. This
>> might take a while due to other obligations that I will have to meet during 
>> the next few days.
>>
>> ---rony
> O.K., so came up with a test case that contains an artificial script engine 
> implementation for
> logging the eval() invocations together with the scripts to execute and the 
> ScriptContext
> ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is 
> meant to be also usable
> for creating script engine related test units for Java script hosts.)
>
> Packaged the source and binaries of that script engine as jar file that one 
> merely needs to put on
> the CLASSPATH or add as a module.
>
> An updated FXMLLoader patch suggesting a fix is included as well. This 
> version appends the line
> number to the file name if the script to be evaluated is embedded in the 
> fxml-file, such that in
> case of an error it becomes possible to quickly find it in larger fxml files.
>
> With the zip-archive done I went to the Oracle Java Bug Database and just 
> entered a bug report at
> <https://bugreport.java.com/bugreport/submit_start.do> got the internal "ID : 
> 9062887".
>
> As it was not possible to attach/upload the zip-archive at this point, I will 
> attach the zip-archive
> (contains all sources and binaries) to this e-mail. The contained 
>  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:
>
>   - Un

"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 
> <https://bugreport.java.com/>
> as per your advice (and will report back under this thread once submitted). 
> The testcase would use
> an artificial ScriptEngine implementation that could be used for testunit 
> testing as well. This
> might take a while due to other obligations that I will have to meet during 
> the next few days.
>
> ---rony

O.K., so came up with a test case that contains an artificial script engine 
implementation for
logging the eval() invocations together with the scripts to execute and the 
ScriptContext
ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is 
meant to be also usable
for creating script engine related test units for Java script hosts.)

Packaged the source and binaries of that script engine as jar file that one 
merely needs to put on
the CLASSPATH or add as a module.

An updated FXMLLoader patch suggesting a fix is included as well. This version 
appends the line
number to the file name if the script to be evaluated is embedded in the 
fxml-file, such that in
case of an error it becomes possible to quickly find it in larger fxml files.

With the zip-archive done I went to the Oracle Java Bug Database and just 
entered a bug report at
<https://bugreport.java.com/bugreport/submit_start.do> got the internal "ID : 
9062887".

As it was not possible to attach/upload the zip-archive at this point, I will 
attach the zip-archive
(contains all sources and binaries) to this e-mail. The contained  
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 t

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

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 B

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 

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

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

RFE: Allow any javax.script language to be used for script code in HTML event attributes and script elements processed by WebView/WebEngine

[Rony G. Flatscher]

Currently it is possible to create one own's browser using WebView where the 
WebEngine processes
script code written in JavaScript for event attributes or for script elements.

WebEngine is currently implemented such that only JavaScript gets supported for 
scripts in HTML (in
event attributes or script elements). This request for a feature enhancement is 
therefore asking to
enhance WebEngine such that it allows any of the javax.script languages to be 
used for writing
scripts in HTML, very much like FXML controllers can be implemented in any of 
the Java script languages.

The javax.script language (e.g. groovy, jruby, jython, rexx, ...) to be used 
could be determined
with the "type" attribute (expecting a mime-type) or like in MS 
InternetExplorer with the (in the
meantime deprecated) "language" attribute (expecting the language name).

As one of the results this would allow one to use WebView as the presentation 
(and print) layer for
(stand-alone) applications written in any javax.script language.

A comparable solution has been available (and quite heavily exploited in some 
companies) with MS
InternetExplorer and MS IIS allowing any ActiveX script language (JScript, 
VBScript, etc.) on
Windows to be used in client HTML text and ASP for server side (this exists for 
twenty+ years on
that platform). However, this solution has been restricted to MS Windows and MS 
InternetExplorer and
not supported by any other competing browsers.

Although HTML allows for denoting the name/mime-type of a script language used 
for script code, it
seems that only MS has honored that in the past.

Using WebView/WebEngine with any javax.script language would make a comparable 
solution totally
platform independent and truly portable (and independent of any other 
third-party Web browser like
Chrome, Safari, Firefox and the like). It is assumed that adding this feature 
would be quite
attractive for private use, but also for small to medium sized companies.

Any ideas how complex it would be to change WebEngine accordingly? Would there 
be related classes
that need to be changed as well? What pitfalls would one have to think about?

---rony

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

Re: Table Input

[Rony G. Flatscher]

José & Daniel,

thank you very much for the information and links!

---rony


On 20.06.2018 19:45, José Pereda wrote:
> As Daniel points out, the TableView2 control is a Gluon contribution that has 
> been merged recently
> to ControlsFX, but it hasn't been released yet. Actually there is a pending 
> PR to rename the new
> control to FixableTableView.
>
> Regarding commit on focus, it has been implemented in two new table cell 
> factories, for TextField
> and ComboBox cells [2].
>
> You can use the snapshot to test it, and of course, you can clone the 
> repository, there are two
> samples [1] available.
>
> Jose
>
>
> [1]
> https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx-samples/src/main/java/org/controlsfx/samples/tableview2
> [2] 
> https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx/src/main/java/org/controlsfx/control/tableview2/cell/TextField2TableCell.java
>
>
> On Wed, Jun 20, 2018 at 7:06 PM, Daniel Peintner  > wrote:
>
> Hi,
>
> > I believe the last time I looked at the TableView2 contribution at
> > > ControlsFX (which can be used as a TableView replacement), commit on
> > focus
> > > lost was implemented/supported.
> > Do you have a link?
> >
>
> The PR has been merged but the contribution is not yet available as
> ControlsFX release.
> Note: I think the credits go to Jose Pereda (Gluon?)
>
> The easist way to test it is using jpro demo [1] where you can find a
> TableView2 section.
>
> Having said that, I don't actually know how it is implemented. I just
> noticed commit on focus lost support while playing with this demo.
>
> -- Daniel
>
> [1] https://demos.jpro.one/controlsfx.html 
> 
>
>
>
> >  > seems to not
> have it.
> >
> > ---rony
> >
> > > Jonathan Giles  > schrieb am
> Mi., 20. Juni
> > 2018,
> > > 10:28:
> > >
> > >> Yup,
> > >>
> > >> A great regret. I wish it were supported, but it isn't due to 
> historical
> > >> legacy. There are some small ways you can make some progress, e.g. 
> add
> > >> focus listeners on the editor node, but they are half solutions at 
> best.
> > >>
> > >> -- Jonathan
> > >> (Tapped on a touch device)
> > >>
> > >> On Wed, 20 Jun 2018, 10:25 AM ,  > wrote:
> > >>
> > >>> Zitat von Tom Eugelink mailto:t...@tbee.org>>:
> > >>>
> >  This is a well known and already deeply discussed issue. I'm still
> >  not sure where we are with it, but Jonathan knows I believe.
> > 
> > 
> > >>> https://bugs.openjdk.java.net/browse/JDK-8089514
> 
> > >>>
> > >>> tbd_major ... since nearly 7 years :(( actually, it took 4 years to
> > >>> get the necessity accepted, then another 2 years playing with
> > >>> incomplete suggested fixes and then ...
> > >>>
> > >>> It's a complex problem, requires
> > >>>
> > >>> a) additional commit/cancel api on the virtual controls to allow
> > >>> collaborators to cleanly terminate ongoing edits - this part has 
> still
> > >>> been debated
> > >>> b) a major cleanup of cell implementations - this part was under way
> > >>> (and evolving into the good direction) until Jonathan left
> > >>>
> > >>>
> > >>> CU, Jeanette
> > >>>
> >  On 19-6-2018 20:53, Ty Young wrote:
> > > On 06/19/2018 10:51 AM, omnip...@gmail.com 
>  wrote:
> > >
> > >> A minor issue in the Table component existed in previous 
> versions of
> > >>> JavaFX
> > >> when editing in a cell was turned on. Only if the Return key was
> > >> pressed was
> > >> the data entered into the backing bean. Leaving the cell with 
> Tab or
> > >> by
> > >> mouse did not register the change. I thought just when a cell 
> looses
> > >>> focus
> > >> it should trigger updating the bean. I have not looked at the 
> recent
> > >>> builds
> > >> but I thought I'd ask if it has come up on anyone's radar. I
> > >> noticed it when
> > >> I moved from teaching Swing to FX.
> > >>
> > >>
> > >> Ken Fogel
> > >>
> > >>
> > >>
> > > IIRC, this isn't specific to Table. A spinner with editing enabled
> > > also does this and it breaks events(onKeyTyped does nothing).
> >
> >
>
>
>
>
> -- 
>

Re: Table Input

[Rony G. Flatscher]

On 20.06.2018 15:33, Daniel Peintner wrote:
> I believe the last time I looked at the TableView2 contribution at
> ControlsFX (which can be used as a TableView replacement), commit on focus
> lost was implemented/supported.
Do you have a link?

 seems to not have it.

---rony

> Jonathan Giles  schrieb am Mi., 20. Juni 2018,
> 10:28:
>
>> Yup,
>>
>> A great regret. I wish it were supported, but it isn't due to historical
>> legacy. There are some small ways you can make some progress, e.g. add
>> focus listeners on the editor node, but they are half solutions at best.
>>
>> -- Jonathan
>> (Tapped on a touch device)
>>
>> On Wed, 20 Jun 2018, 10:25 AM ,  wrote:
>>
>>> Zitat von Tom Eugelink :
>>>
 This is a well known and already deeply discussed issue. I'm still
 not sure where we are with it, but Jonathan knows I believe.


>>> https://bugs.openjdk.java.net/browse/JDK-8089514
>>>
>>> tbd_major ... since nearly 7 years :(( actually, it took 4 years to
>>> get the necessity accepted, then another 2 years playing with
>>> incomplete suggested fixes and then ...
>>>
>>> It's a complex problem, requires
>>>
>>> a) additional commit/cancel api on the virtual controls to allow
>>> collaborators to cleanly terminate ongoing edits - this part has still
>>> been debated
>>> b) a major cleanup of cell implementations - this part was under way
>>> (and evolving into the good direction) until Jonathan left
>>>
>>>
>>> CU, Jeanette
>>>
 On 19-6-2018 20:53, Ty Young wrote:
> On 06/19/2018 10:51 AM, omnip...@gmail.com wrote:
>
>> A minor issue in the Table component existed in previous versions of
>>> JavaFX
>> when editing in a cell was turned on. Only if the Return key was
>> pressed was
>> the data entered into the backing bean. Leaving the cell with Tab or
>> by
>> mouse did not register the change. I thought just when a cell looses
>>> focus
>> it should trigger updating the bean. I have not looked at the recent
>>> builds
>> but I thought I'd ask if it has come up on anyone's radar. I
>> noticed it when
>> I moved from teaching Swing to FX.
>>
>>
>> Ken Fogel
>>
>>
>>
> IIRC, this isn't specific to Table. A spinner with editing enabled
> also does this and it breaks events(onKeyTyped does nothing).

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Rony G. Flatscher]

On 31.05.2018 02:11, Kevin Rushforth wrote:
> I just sent an email to the core-libs-dev alias [1] proposing a new Packaging 
> Tool as a
> replacement for javapackager. If you are interested in this JEP, you can 
> follow and participate in
> the discussion there.
>
> -- Kevin
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html
>

One feature that might not be on the radar for pure Java solution providers is 
having an option to
start up a JavaFX application from any javax.script (aka JSR-223) scripting 
language. In this case
it should be possible to supply the script's file name.

---rony

t e / s t

[Rony G. Flatscher]

In case this e-mail makes it to the openjfx-dev-list, please ignore it. (I have 
been trying for
months to post a message without success.)

---rony

Re: What is the process ?

[Rony G. Flatscher]

Hi Kevin,

that is great, thank you *very* much!

There is enough food to digest and set actions, from OCA to a preliminary 
sketch of a JEP or two!

If that is o.k. I would come up with questions over this list, should any arise.

Best regards,

---rony



On 20.12.2016 16:57, Kevin Rushforth wrote:
> Hi Rony,
>
> See the "How to contribute" page [1] on the OpenJDK site. The first step is 
> to sign the Oracle
> Contribute Agreement (OCA) [2]. All code that you contribute must be your own 
> work and free of IP
> encumbrances. It becomes joint property of Oracle, with you retaining your 
> copyright. Code that is
> eventually checked into the OpenJFX project is done so under the GPL v2 
> license with the
> "Classpath" exception [3]. Oracle may also choose to license it under other 
> terms (e.g., when
> producing the Oracle JDK).
>
> To contribute a bug fix, you would indicate your interest in contributing a 
> patch to a bug, and
> then work with a Committer in the Project to sponsor your fix.
>
> The process for getting an enhancement in is a bit more involved, and 
> requires additional approval
> since we want to carefully control the API. You can start by filing an RFE at 
> bugs.java.com [4].
> You should also become familiar with the Java Enhancement Proposal (JEP) 
> [5][6] process, since any
> significant new features require a JEP. We require comprehensive tests as 
> part of any new feature.
> It is strongly recommended to discuss your idea on this list first to get 
> some feedback as to
> whether it is a feature / API we would consider accepting before you go off 
> and spend much time
> prototyping your ideas.
>
> Let me know if there are any questions on any of this.
>
> -- Kevin
>
>
> [1] http://openjdk.java.net/contribute/
> [2] http://www.oracle.com/technetwork/community/oca-486395.html
> [3] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/tip/LICENSE
> [4] http://bugs.java.com/
> [5] http://openjdk.java.net/jeps/1
> [6] http://openjdk.java.net/jeps/2
>
>
>
> Rony G. Flatscher wrote:
>> Hi there,
>>
>> what is the proper process, if one wishes to contribute. Is there some web 
>> site describing it? Where
>> to get the official source from? What kind of license has one to use for 
>> patches (AL ;) , GPL, LGPL,
>> etc.)? How about (and where) creating issues for RFEs, how to decide whether 
>> an RFE is acceptable?
>> How and where to submit patches?
>>
>> The intent/aim/motivation for possible contributions would be initially 
>> JavaFX RFEs that are
>> javax.script related.
>>
>> ---rony
>>
>>
>>   

What is the process ?

[Rony G. Flatscher]

Hi there,

what is the proper process, if one wishes to contribute. Is there some web site 
describing it? Where
to get the official source from? What kind of license has one to use for 
patches (AL ;) , GPL, LGPL,
etc.)? How about (and where) creating issues for RFEs, how to decide whether an 
RFE is acceptable?
How and where to submit patches?

The intent/aim/motivation for possible contributions would be initially JavaFX 
RFEs that are
javax.script related.

---rony

Re: Planning for JavaFX.next

[Rony G. Flatscher]

As no one else has asked for it, here it goes: improve javax.script support 
beyond the e-mail in
this list from 2016-12-07, entitled "RFE/Suggestions to improve JavaFX 
deployment of javax.script
(part of Java) engines and script code" by:

  * introudcing the possibility to define javax.script controllers,
  * employing javax.script.Invocable.getInterface(...) to become able to use 
javax.script code
(objects) to implement the methods/functionality of any Java interface 
class, especially those
that in the context of JavaFX are of paramount interest: any action, change 
handlers and the
like (i.e. having script code employed for implementing 
javafx.event.EventHandler,
javafx.beans.value.ChangeListener, javafx.util.Callback, ...)
  * enhance SceneBuilder such that it can be used for defining these new 
javax.script features
(defining javax.script controllers, code, determining which script object 
is to be uesed for
Listeners etc.) , maybe allow configurable plugins for javax.script related 
editors to ease coding
  * enhance javafxpackager to allow standalone jars to be created that use a 
javax.script as the
main class/program to be run, such that no Java sourcecode would be needed 
to create full-blown
JavaFX applications in javax.script languages
  * and ceterum censeo: allow any mix of javax.script code in FXML and HTML 
documents (FXMLLoader,
WebEngine, and the like), where specific languages get identified by a 
"type" attribute and
supply FILENAME and ARGV in the local ScriptContext, cf. other e-mail.

Again, please do not underestimate the importance of scripting languages for 
other programmers than
yourself (you all would probably solve any problem in this area with Java right 
away, which is fine;
but do not forget that not everyone is a Java-savvy programmer, but excellent 
in one of the many
available javax.script languages). Adding these javax.script related features 
is feasible and
actually not that difficult or effortful, yet you would really open up a huge 
stage ;) for script
programmers ...

---rony


On 08.12.2016 00:45, Jonathan Giles wrote:
> Hi folks,
>
> Development on JDK 9 is slowly starting to ramp down, and we are starting to 
> turn our attention to
> the goals for JavaFX in JDK 10 and beyond. We are starting to compile our 
> list of what we think is
> important, but we really want to hear from the community about what their 
> highest priorities are
> to them. As always, it's important to keep in mind what JavaFX is (e.g. it 
> isn't aiming to be a
> high-performance game engine), but even still there are bound to be a number 
> of places where
> people might want to weigh in, for example:
>
>  * New layout containers (e.g. Flexbox)
>  * Public APIs for UI control behaviors
>  * Marlin renderer enabled by default
>  * Support for CSS animations
>  * CSS performance improvements
>  * TableView improvements (cell spanning, row / column freezing, etc)
>  * TableView performance
>  * Focus traversal API
>  * WebGL support in WebView
>  * Improved image I/O support
>  * A JavaFX equivalent of the AWT Desktop APIs
>  * Multi-res image API
>  * NIO-backed writable images
>
> If there are other areas of interest that aren't listed here, please start 
> discussing them and we
> can work together to determine priorities. If all you want to do is add a +1 
> for one of more of
> the items above, even that will be very useful.
>
> Thanks,
> -- Jonathan

RFE/Suggestions to improve JavaFX deployment of javax.script (part of Java) engines and script code

[Rony G. Flatscher]

For scripting languages that possess javax.script (part of Java since Java 
1.6/6!) implementations
the JavaFX infrastructure is of a great attractivity.

JavaFX would allow script programmers for creating platform independent GUIs to 
take fully advantage
for their own purposes, i.e. "surfing on Java" to get at a modern, maintained, 
up-to-date GUIs in an
open manner!

Of course, scripting support in form of Nashorn/ECMAScript/Javascript is on 
board of modern Java
distributions, however there are many more javax.script scripting languages 
available. (In my case I
am very interested in ooRexx, the opensource version of IBM's Open Object Rexx, 
which is a very easy
to learn, yet powerful OO language, and am the author of the JSR-223 
implementation of ooRexx, which
will be included in the next distribution of BSF4ooRexx which is a bridge 
between ooRexx and Java.)

While evaluating the possibilities (for non-informatic students) of taking 
advantage of the JavaFX
infrastructure, I have been experimenting and exploring the JavaFX 
infrastructure. Being acquainted
with the details of javax.script/JSR223 it has been very interesting to learn 
how javax.script is
being deployed on JavaFX. Basically, using SceneBuilder and then manually 
editing the FXML file it
becomes possible to run any scripting programs from (I assume FXMLLoader), 
given that there is a
processing instruction like e.g.



or



which causes FXMLLoader to load the denoted scripting language by name. As a 
result all script code,
be it defined in fx:script elements with a source attribute pointing to the 
file containing the
script code or any code supplied in attributes like "onAction" will be executed 
with this denoted
scripting engine.

This is it. Nothing else is currently available. Not even employing 
javax.script programming
languages in the context of a WebView/WebEngine, although HTML defines a "type" 
attribute for the
"script" element!

E.g, it is not possible to employ more than one script language for the same 
document, although this
is plain easy! Or, it is not possible to have script controllers defined (only 
Java controllers) in
SceneBuilder. Or it is not possible to use javafxpackager to create a jar-file 
with pure
javax.script code and JavaFX resources, as there is no support to denote a 
script to be used as the
"main class".

---

As this is the JavaFX developer list, I would like to propose in this e-mail 
very few and (really!
:) ) easy to implement enhancements that immediately would increase the 
usability and the
attractiveness of JavaFX for script writers. If there is an official tracker 
infrastructure where I
could post at least the simple enhancements, please advise!

---

 1. Suggestion # 1: wherever script code can be denoted, allow a "type" 
attribute with the mime type
value of the javax.script engine to be used to execute the script code. 
Whenever such a "type"
attribute is found, one can load the respective javax.script engine by 
merely using
javafx.script.ScriptManager.getEngineByMimeType(mimeType) and then have it 
execute the script code.

FXML candidates are the fx:script element itself as well as all attributes 
(like "onAction")
that allow to denote script code. But also in HTML 5 (WebView/WebEngine) 
the script element and
its "type" attribute (cf. ).

  * Examples in FXML-documents:

 

  * Example in any fx-elements that have attributes that allow code:



 2. Suggestion # 2: whenever (probably FXMLLoader, WebEngine) execute 
javax.script code, then please
add the following entries to javax.script.ScriptContext.LOCAL_SCOPE 
javax.script.Bindings:

 1. if the "source" attribute (script-element in HTML 5, fx:script-element 
in FXML) denotes a
file name, then use the key javax.script.Engine.FILENAME and store the 
value of "source" in
the LOCAL_SCOPE Bindings. The scripting engine implementation is then 
able to supply that
name to the script program (e.g. in the case of a runtime error, or for 
debugging purposes),
which currently is not possible.

 2. if arguments are to be passed to the script code, then create a Java 
array object with the
arguments, use the key javax.script.Engine.ARGV and store the Java 
array with it. The
scripting engine implementation is supposed to pass on these arguments 
in the scripting
language's format, which currently is not possible.

As you can see, these are very few suggestions, but for javax.script language 
programmers (no matter
which languages they use and mix) they immediately improve the usability of 
JavaFX tremendeously!

It would be great, if someone would be able and willing to implement these 
little suggestions
(probably in the FXMLLoader and WebEngine classes). If there is anything I 
could do to help, please
let me know (also, if anyone can point me to a formal way of 

Re: Hmm, another attempt to get information on deploying javax.script (via FXMLLoader) and SceneBuilder and javax.script languages ...

[Rony G. Flatscher]

On 28.11.2016 14:18, Rony G. Flatscher wrote:
> Dalibor,
>
> thank you very much for this link, just posted a comparable question there.
>
> Poking around the questions (many unanswered) posted there, my hopes are not 
> very high to get an
> answer (maybe I am too pessimistic here)...
>
> Again, thank you!
>
> ---rony
As feared/anticipated, there have been no real answers on the pointed out 
Oracle community.

Short of any alternatives, I think that this group is probably the most 
appropriate to discuss
javax.script (part of Java!!) implementation issues and ideas with JavaFX. If 
nothing else, *the*
JavaFX developers hang out here!

Therefore I will try to post a few little things that would tremendeously 
improve JavaFX (FXMLoader
and WebEngine) for any script engine, though the implementation complexity 
would be *quite* simple.

---rony



> On 28.11.2016 13:43, dalibor topic wrote:
>>
>> On 28.11.2016 12:55, Rony G. Flatscher wrote:
>>> So I am wondering whether there is another mailing group (other than this 
>>> one) where questions like
>>> this can be asked
>> There is a JavaFX forum at
>> https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later
>>  within the Oracle
>> Community.
>>
>> cheers,
>> dalibor topic

Re: Hmm, another attempt to get information on deploying javax.script (via FXMLLoader) and SceneBuilder and javax.script languages ...

[Rony G. Flatscher]

Dalibor,

thank you very much for this link, just posted a comparable question there.

Poking around the questions (many unanswered) posted there, my hopes are not 
very high to get an
answer (maybe I am too pessimistic here)...

Again, thank you!

---rony


On 28.11.2016 13:43, dalibor topic wrote:
>
>
> On 28.11.2016 12:55, Rony G. Flatscher wrote:
>> So I am wondering whether there is another mailing group (other than this 
>> one) where questions like
>> this can be asked
>
> There is a JavaFX forum at
> https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later 
> within the Oracle
> Community.
>
> cheers,
> dalibor topic

Hmm, another attempt to get information on deploying javax.script (via FXMLLoader) and SceneBuilder and javax.script languages ...

[Rony G. Flatscher]

Quite a while ago I asked about javax.script deployments in JavaFX (i.e. when 
instrumentating
javax.script languages when FXMLLoader processes FXML files) without getting 
any answer or pointer
so far.

So I am wondering whether there is another mailing group (other than this one) 
where questions like
this can be asked *and* answers can be expected! ;)

The same question goes with SceneBuilder, for which I have not found more 
appropriate e-mail lists.

The background for both of these questions is simple: JavaFX is a great 
infrastructure. All
javax.script languages could take much better advantage of it, if there was 
more specific support
for them. (E.g. allowing different javax.script languages to be deployed off 
the same FXML document,
enhancing SceneBuilder support for javax.script languages like jython, ooRexx, 
even Nashorn, etc.)

---rony

Re: Problem editing FXML documents with latest SceneBuilder 8.2.0 with a"${attrname}" text property

[Rony G. Flatscher]

On 22.11.2016 10:34, Rony G. Flatscher wrote:
> Not sure whether this is the correct list, if not, please advise where to 
> post such observations.
>
> The latest SceneBuilder 8.2.0 (in this case the 64-bit Windows-Version) seems 
> to not be able to
> process 'text="${attrname}"' definitions, e.g. for a Label. Such an entry 
> will not be displayed in
> the Properties section (the attribute "Text" is empty), the Label cannot be 
> interactively resized or
> moved and is flagged with a superimposed warning icon in the Document 
> Hierarchy. When saving a
> manually created FXML document after editing in the ScreenBuilder the entire 
> text-attribute
> definition gets removed!
>
> How is one supposed to communicate such a bug in SceneBuilder?
>
> ---rony
Actually the text-attribute that has a "$attrname" (without curly braces) gets 
removed when saving
the FXML document.

Everything else is still as reported if the text attribute has a "${attrname}" 
value (and eventually
gets removed upon saving it, cannot recreate it as of yet, but observed that 
behaviour).

---rony

Problem editing FXML documents with latest SceneBuilder 8.2.0 with a"${attrname}" text property

[Rony G. Flatscher]

Not sure whether this is the correct list, if not, please advise where to post 
such observations.

The latest SceneBuilder 8.2.0 (in this case the 64-bit Windows-Version) seems 
to not be able to
process 'text="${attrname}"' definitions, e.g. for a Label. Such an entry will 
not be displayed in
the Properties section (the attribute "Text" is empty), the Label cannot be 
interactively resized or
moved and is flagged with a superimposed warning icon in the Document 
Hierarchy. When saving a
manually created FXML document after editing in the ScreenBuilder the entire 
text-attribute
definition gets removed!

How is one supposed to communicate such a bug in SceneBuilder?

---rony

Question ad javax.script deployment scenarios ...

[Rony G. Flatscher]

Not having found a documentation or references as how javax.script scripting 
languages get employed
in JavaFX, I was wondering whether there is an up-to-date, current 
documentation of that support, if
any at all?

E.g. it seems that it is not possible to have different scripting engines 
execute event handlers for
the same document (there seems to be no type-attribute or language-attribute 
available that denotes
the scripting language to use to execute the code supplied in an 
event-attribute like onAction).

Or, at least in JavaFX 8, the filename is not supplied for external files, 
although it could be
supplied (and would be important for debugging) like the name the 
source-attribute of a fx:script
element (e.g. ). [One would merely 
have to add an attribute
to the ScriptContext.ENGINE_SCOPE Bindings under the key ScriptEngine.FILENAME, 
ie.
"javax.script.filename".]

There would be more, maybe interesting features that javax.script defines that 
could be taken
advantage of (like defining arguments to supply in certain situations which 
would merely need to
employ the key ScriptEngine.ARGV, ie. "javax.script.argv" for the Object array 
to store in the
ScriptContext.ENGINE_SCOPE Bindings.

---rony