SettingsPanel's Java Version handling (when iOS platform included) is unintuitive

[raagnair]

Issue
Confusing UI behavior when trying to change to Java version.
All inputs seem to be ignored.

Repro steps
Select iOS as part of the game platforms.
Try to change Java version to anything.

Investigation
Relevant source file:
https://github.com/libgdx/gdx-liftoff/blob/master/src/main/java/gdx/liftoff/ui/panels/SettingsPanel.java

if(UserData.platforms.contains("ios") && !"7".equals(UserData.javaVersion))
    UserData.javaVersion = "8";

The intention here seems to be that only Java 7 and Java 8 are supported for games published to iOS. However the if-statement above would disallow the user from changing between 7 and 8, because it would require an invalid intermediary step.

More detailed explanation:
(Please skip, if the above paragraph already makes sense to you)

Let's say UserData.javaVersion is currently "8". To turn that value to "7", I might choose to hit backspace to remove the "8", before I type "7". But this creates an intermediary state when UserData.javaVersion is "", which triggers the above if-statement, causing it to be set to "8" again. If I try to switch the order of operations, and add "7" first before deleting the "8", this also creates an invalid intermediary state of "87" (or "78") that triggers the above if-statement.

As a total novice game developer, I didn't know iOS was limited to Java 7/8, and so this hidden foot-gun seemed like a bug to me.

I don't know if the maintainers want issues to come tagged with proposed solutions.
If you'd like my suggestions, please let me know.

[tommyettinger]

I'm not quite sure what to do here because an empty string isn't a valid version either... I don't think a dropdown makes sense because new Java versions come out twice a year now. Then again, Gradle defaults to being broken on a new Java version. Hmmm.

Honestly, there isn't any reason to stick to 7, in my mind. There are many APIs missing in RoboVM from Java 8, but others are always missing for any Java version, such as AWT packages. Not to mention newer JDKs can't actually keep compatibility with Java 7 JVMs, and even Java 8 will eventually be unsupported. With RoboVM, you can actually make good use of a fair amount of nice things added in Java 8 -- not Stream APIs, since those use new classes, but lambdas and method references work, functional interfaces can be declared (they don't need the FunctionalInterface annotation, oddly enough), default implementations can be added to interfaces, etc. That needs that field to be 8 to work. I think setting compatibility to 7 is a mistake even if it makes some IDE suggestions more accurate for RoboVM. I don't know what JDK is the most recent that can still target Java 7, but I know the most recent long-term supported release (Java 21) can't target 7. It can target 8.

[raagnair]

I think the choice of whether Java 7 should or should not be offered in the event of an iOS platform game is ancillary to the issue brought up here.

This issue is highlighting the UX confusion of having an editable field that appears editable, but reverts back to the default value on every key-press, without letting the user know why it's happening. So in the future, if Java 9 starts being supported for iOS deployments, we'd still have this issue where values 8 <-> 9 cannot be switched, because both require an invalid intermediary state.

@tommyettinger how do you feel about doing validation for all fields at once, on focus-loss of any input (clicking away from text field) or on clicking the generate button? This way our validation isn't actively sabotaging the user's effort to edit a text field, but we still give ample opportunity for all validation to run?

[tommyettinger]

I like the idea of validation on focus loss (and also when clicking things that don't acquire focus)! I have no idea how to do it right now, since much of the scene2d.ui code was whipped up by @raeleus and most of the fancier UI features are well beyond my knowledge. Hopefully Lord Buckley of GUIville can take a look at this issue and maybe give some pointers on where to look for this sort of validation?

There are of course deeper issues running through this, like what to do if TeaVM and RoboVM are both selected, with incompatible version requirements. Or, if we can somehow switch to the RoboVM beta release that supports some of Java 11...

[raeleus]

I'll take a look at it some time. I have a feeling that this came up in testing or something. I don't remember.

[tommyettinger]

This didn't make it into 1.13.1.1, but I think there's a good chance it will be in the next version.

[raeleus]

This will be resolved with PR #218