Upgrade Scene Builder Java compiler version to Java 17

[Oliver-Loeffler]

Hi,
I think upgrading the Scene Builder Java compiler options in POM.xml can be helpful for future work.
First, Java-17 is the new LTS version and it brings a number of enhancements and language features.
Therefore, I thing upgrading Java compiler version in POM.xml from 11 to 17 is a good idea.

How do you think about @abhinayagarwal & @jperedadnr ?

Expected Behavior

Project uses Java-17 language features.

    <properties>
        <javafx.version>17</javafx.version>
        <maven.compiler.release>17</maven.compiler.release>
    </properties>

Current Behavior

Project uses Java-11 language features.

    <properties>
        <javafx.version>17</javafx.version>
        <maven.compiler.release>11</maven.compiler.release>
    </properties>

Context

Java-17 is the new LTS version of Java. As Scene Builder is shipped with a Java-17 runtime, it could also be helpful to build it using Java-17 language features such as records, text blocks or better pattern matching.

[AlmasB]

This sounds like a good idea to move to latest LTS, but not sure about the implications of that. Can you think of possible issues with this for developers or users?

[Oliver-Loeffler]

I am not sure where and how Scene Builder is used outside. For IDEs, the most common case I've seen was so far that an external Scene Builder was linked and started using the executable. One possible downside would be the compatibility of the JAR with IDEs running on older JVMs.

But here I think, @johanvos has probably a better picture of how and where Scene Builder is used as an embedded component.

[johanvos]

For OpenJFX, we keep the Java version on 11 unless we have a very good reason to increase it, as it would have major implication for developers using JavaFX that can't easily move beyond 11.
The typical users of Scene Builder are not embedding SB, and even if they do, they can still use existing versions.
While I wouldn't just use new features for the sake of the features, I am ok with increasing the base JDK version here.

[Oliver-Loeffler]

After rethinking this I've limited the scope of the change as proposed in PR #432 to the app module.
This will help to evolve the app further but keep the kit working in Java-11 environments.

[abhinayagarwal]

@Oliver-Loeffler I still think there is not much to gain from this transition atm. It would be better to keep this for the future and move to Java 17 when both kit and app can move together.

@AlmasB @jperedadnr Thoughts on this?

[AlmasB]

Based on @johanvos comment above, it seems there are no significant issues with upgrading both modules to 17. The next LTS won't arrive for some time and there isn't really an obvious cut-off point for when the switch should take place. If that's the case, we might as well switch both now.

[Oliver-Loeffler]

Well, I've used records & switch expressions in PR #396 but eventually those records can be classes and the switches can be reverted to old style. It's technically not needed but makes life easier.

The purpose of this issue was (for me) to make this change visible and decouple it from PR #396. It's up to you - I personally think that JDK 17 brings very helpful instruments and capabilities but indeed, it's technically not needed. But I see several points where newer JDK capabilities can help.

Indeed, technically, pushing both modules to 17 is more favorable than only pushing app to 17.

[johanvos]

+1 for moving both kit + app now to Java 17

[Oliver-Loeffler]

I'll rework the PR to have app and kit going with Java-17.