Set GdxSetup source level to java 8

[obigu]

Since Java 21 (LTS) is the default version when downloading java, many users (specially new libGDX users) are complaining new projects don't work. Even if libGDX iOS backend doesn't fully support Java 8 language features (see #5487) at this point I think, until we decide on the approach to move forward, we should change Gdx Setup source level to 8 on all modules.

[Tom-Ski]

Probably some kind of warning would be good. This is giving people the impression that those language features are going to be ok to use. And it's not just language features, but lots of the 'JDK' is not available. If people spend a lot of time creating their game/app with these features without incrementally testing the ios version (which is standard flow), it would be a pain to fix all issues.

[obigu]

Probably some kind of warning would be good. This is giving people the impression that those language features are going to be ok to use. And it's not just language features, but lots of the 'JDK' is not available. If people spend a lot of time creating their game/app with these features without incrementally testing the ios version (which is standard flow), it would be a pain to fix all issues.

True, warning added

[Frosty-J]

This is especially true of GWT. Even really old Java methods such as String.format() are absent from it, and there's no indication that it won't work until you try to build (or sometimes it fails at runtime - even worse).

A separate discussion, but I don't think iOS and others should be enabled by default (especially on Windows and Linux where there is no Xcode). Most users who are starting out leave the boxes checked, increasing download time and the risk of things going wrong (e.g. the ZipFile error if both Android and iOS modules are enabled, requiring manual Tools installation). I have. I've also seen users think the Android SDK is required when they don't even want to build for Android.

[Tom-Ski]

I think that is fair enough. I would say for the purpose of easily adding these subprojects back in down the line, it would be better if all the scripts are there already, but probably just commented out in the settings.gradle as inclusions of sub projects. Otherwise it would be very challenging for people not familiar with Gradle to add back in a platform that they now want to target.

This would require changing the main generated script to remove all dependencies and configurations to their respective sub project build.gradle though. But in my experience this is better anyway due to plugin conflicts, and android gradle plugin being notoriously horrible when it comes to these cross platform projects, especially in their IDE integration.

This does make the dependencies a little harder to manage for the user if not familiar with Gradle as they all would be split (This is why it was done the way it is, to make having to learn gradle as minimal as possible for user, all deps and config just in one file), but maybe that is a sacrifice that would be overall beneficial.

[obigu]

Sure, that would be a separate PR though. @Tom-Ski are we happy with the changes?