Update SpreadsheetView code to JavaFX 17

[Groostav]

This PR is a continuation of #1376,

all I have done here is:

1. merge (not rebase) master in so I can get the work done in Use Gradle 7+ #1460 (namely 7d8cb99)
2. change a couple of gradle-dep-versions to run-on and build-against javafx 17

I have run the sampler with samples, and it looks OK. I'll put some notes in comments, no show stoppers that I've found (see comment)

I've also run gradle test: 29 passed 3 ignored 0 failed.

When I looked at this it it contained:

if this could be merged but I doubt it since I still have some usages of internal classes.

edit: what i was about to say was wrong, looking into this...

99% of the work here comes from @Maxoudela with small ~build system tweaks from myself and @abhinayagarwal.

some questions:

1. Do you guys want a rebase -i before merge?
2. @Maxoudela (the author of most of the work here) worries about importing from
3. this work is not compatible with javafx 13, I believe the only reason for this is TableColumnHeader.resizeColumnToFitContent, and so I'm wondering if this code could be re-written to use reflection so that it can run on both javafx 13 (and presumably javafx 11) and javafx 17.

[lgtm-com]

This pull request introduces 2 alerts when merging 8c0ac3c into 1a81f33 - view on LGTM.com

new alerts:

• 2 for Container contents are never accessed

[abhinayagarwal]

I prefer to close #1376 in favour of this PR and then rename the PR to something meaningful.

[Maxoudela]

I'll take a moment this week end to analyse the code. I believe it can be difficult to make this backward compatible with JDK 11.
Some implementations details have changed a lot between 11 and 17. The SpreadsheetView could be built (using reflection like you suggest) but I wonder what will happen when running it.

[Groostav]

Regarding some functional testing notes:

@Maxoudela you wrote

        //For SpreadsheetView
        "--add-exports=javafx.controls/com.sun.javafx.scene.control.behavior.TableViewBehavior=org.controlsfx.controls",
        //For SpreadsheetView
        "--add-exports=javafx.base/com.sun.javafx.event.EventHandlerManager=org.controlsfx.controls"

but thats not riught syntactically and its redundant to the add-exports that are a few lines above, so I'm just going to change the comments on the existing lines.

---

Using the GlyphFont sample there's a skin problem:

Exception in thread "JavaFX Application Thread" java.lang.StringIndexOutOfBoundsException: begin 14, end 15, length 14
	at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4601)
	at java.base/java.lang.String.substring(String.java:2704)
	at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.layoutLabelInArea(LabeledSkinBase.java:590)
	at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.layoutLabelInArea(LabeledSkinBase.java:461)

This code has containsMnemonic = true but its character width appears to be zero, might be a setMnemonic("").

---

adding my custom build to my own project went off without a hitch; I'd still rather pull a binary from you guys though.

[Groostav]

I prefer to close #1376 in favour of this PR and then rename the PR to something meaningful.

I'm not a contributor! apologies, this was the easiest way to do it?

[Maxoudela]

I had this ticket : https://bugs.openjdk.org/browse/JDK-8207957
that prevented to resize the columns properly and this has been fixed in OpenJFX 14. From that point, I believe everything should good.

But running the SpreadsheetView with JDK 11 seems risky to me. If you manage to make it compile with reflection, it's worth the try. I've never done it because we (and my company) completely migrated to OpenJFX 17.

No worry for the gradle --add-exports, I was building the whole PR with Maven at the and so I'm not surprise if it's not accurate.

[Maxoudela]

I this PR is compatible with JDK 13/11, this code needs to be checked because I don't know if that behavior was specific to JDK 17 or not.

[Groostav]

I compiled the library with java 17 targeting java 11, and than ran it under java 11. I opened the speadsheet view, edited some cells, used the enter and tab keys.

Given:
this method is called through the KeyMapping's specified in TableViewBehaviorBase

enterKeyActivateMapping = new KeyMapping(ENTER, this::activate),
new KeyMapping(SPACE, this::activate),
new KeyMapping(F2, this::activate),

two test paths:

• activate key event:
  1. select an editable cell (without beginning an edit and triggering the creation of a custom editable control. To do this i clicked on an uneditable column title and used the arrow keys to select control's FX's employee count)
  2. press f2
     • on java 11: event is passed to super; text is highlighted
     • on java 17: exact same behaviour
• filtered key event:
  1. double click an editable cell, type new value
  2. hit enter
     • on java 11: event is filtered from super; value is committed and subseuent column cell is selected
     • on java 17: exact same behaviour

[Groostav]

I am hoping to spend some time testing this today or tomorrow.

[Groostav]

some notes that I would presume are not related to java11 -> java 17.

• HelloHyperlinkLabel's label.onAction callback is called twice on click; once with eventTarget instanceOf Hyperlink, then again with eventTarget instanceOf HyperlinkLabel; which crashes the handler. I presume this is incorrect, but I don't know enough about events to assert that (something to do with event tails?)
• HelloHyperLink also crashes looking for a style.css stylesheet that I cant find anywhere. I've removed it locally, I'm thinking I should push this change to master? Are stylesheets generated and copied to outputs somewhere?
• HelloGlyphFont fails while trying to parse a nmeonic on ARROW_CIRCLE_O_UP. Reproduce simply by loading the example.

edit: its clear I'm missing something in fx sampllers treatment of css; all of the examples fail to find their CSS. Perhalps the build system is meant to copy a named css file into some kind of generic "style.css" class to be loaded by the sampler app? Need to look into this.