Release 1.10.0.8!

Guide.md

@@ -6,10 +6,10 @@ initially configured your project, and it is very far behind the times on its de
 The official setup may transition to a web-based tool soon, but any user of the Internet can recall times when
 formerly-reliable services went offline or had outages. This project provides another alternative setup tool based on
 [SquidSetup](https://github.com/tommyettinger/SquidSetup), but removing the close ties to the SquidLib libraries to make it more general-use. Using SquidSetup's
-code, which is built on czyzby's code, gives us working projects that use Gradle 7.2, ahead of 6.7.1 for the official setup and 4.0.2 for czyzby's gdx-setup.
-The current Gradle version is 7.2 at the time of writing, and since gdx-liftoff 1.10.0.5, new projects use that 7.2 version.
-This allows new projects to "just work" on machines where Java 16 is the default, and the relatively small amount of configuration
-changes needed for Gradle 7.2 are all handled by gdx-liftoff. Thanks to the Gretty plugin's latest release, Gradle 7.x
+code, which is built on czyzby's code, gives us working projects that use Gradle 7.3, ahead of 6.7.1 for the official setup and 4.0.2 for czyzby's gdx-setup.
+The current Gradle version is 7.3 at the time of writing, and since gdx-liftoff 1.10.0.8, new projects use that 7.3 version.
+This allows new projects to "just work" on machines where Java 8 through 17 could be the default, and the moderate amount of configuration
+changes needed for Gradle 7.x are all handled by gdx-liftoff. Thanks to the Gretty plugin's latest release, Gradle 7.x
 now works well with the HTML platform, without additional quirky configuration (earlier versions of Liftoff needed that).
 Currently, gdx-liftoff projects depend on libGDX 1.10.0 by default, and allow using snapshots as well.
 The current version of libGDX is 1.10.0, which had a longer release cycle because there was an emphasis on fixing bugs
@@ -62,11 +62,11 @@ for new projects generated by gdx-liftoff.
                   encounter this, switch to AdoptOpenJDK (bundling it with releases) or LWJGL3.
                 - The warnings on startup when using (legacy) desktop are somewhat important to note; even though they say
                   the application won't be allowed to start on future JDK versions, LWJGL 2 and 3 both will adapt to any
-                  inability to use certain internal APIs, and both should run perfectly fine on Java 16, even though it
-                  defaults to blocking what the warnings mention. Actually, Java 16 shouldn't emit these warnings at all.
-                    - Even if you didn't build a JAR with Java 16, you can still run the generated JAR
-                      with Java 16, and this may be a good idea for distribution because of some speed and stability
-                      improvements in that JVM release.
+                  inability to use certain internal APIs, and both should run perfectly fine on Java 16 and 17, even though those
+                  default to blocking what the warnings mention. Actually, Java 16 and 17 shouldn't emit these warnings at all.
+                    - Even if you didn't build a JAR with Java 17, you can still run the generated JAR
+                      with Java 17, and this may be a good idea for distribution because of some speed and stability
+                      improvements in that JVM release. 17 is also an LTS release, and those tend to get more adoption.
         - iOS should probably *not* be checked if you aren't running MacOS and don't intend to later build an iOS
           app on a Mac. It needs some large dependencies to be downloaded when you first import the project.
             - If you have a Mac that is set up for iOS development, please try to generate any project and see if it gets
@@ -81,11 +81,11 @@ for new projects generated by gdx-liftoff.
               libGDX 1.10.0 to improve behavior on iOS, and gdx-liftoff may need to apply some changes to template code
               for iOS projects to work more cleanly with libGDX 1.10.0 .
         - Android should only be checked if you've set up your computer for Android development. Since gdx-liftoff uses
-          Gradle 7.2, having an Android project present shouldn't interfere with other platforms or IDE integration, as
-          long as your IDE supports Gradle 7.2 (Android Studio probably does in its most recent versions, but IntelliJ
+          Gradle 7.3, having an Android project present shouldn't interfere with other platforms or IDE integration, as
+          long as your IDE supports Gradle 7.3 (Android Studio might in its most recent versions, but IntelliJ
           IDEA (and Eclipse with Buildship, though it doesn't support Android development well) should automatically).
             - **You must set your project's JDK to a version lower than 16** to use Android, due to current limitations
-              of the Android support in IDEA and Android Studio. JDK 8 and 11 are both good options. JDK 16 is expected to
+              of the Android support in IDEA and Android Studio. JDK 8 and 11 are both good options. JDK 16 and 17 are expected to
               work at some point in the future, and will probably need a brand-new version for IDEA or Android Studio.
             - Having an Android module in a larger project changes some of IDEA's features, including disabling hot-swap.
               Some libGDX developers take the approach of having a separate Android-only project, keeping desktop platforms
@@ -122,10 +122,8 @@ for new projects generated by gdx-liftoff.
         - Kotlin should work well on Android, LWJGL2 and LWJGL3, and will probably work well on iOS.
             - You can see some extra ways to use Kotlin as the Gradle build language in Quillraven's
               [Dark-Matter](https://github.com/Quillraven/Dark-Matter) repo; it also uses Kotlin launchers.
-            - Kotlin launchers should be used cautiously; on iOS in particular there have been cases where they caused
-              mysterious, hair-pulling issues despite working on Android and desktop. You usually edit launchers rarely,
-              so if they're working in Java, you generally don't need to change them to Kotlin.
-            - Some third-party extensions only work with Kotlin, lke the KTX libraries.
+            - You can select Kotlin templates on the templates tab, if Kotlin is selected as a language.
+            - Some third-party extensions only work with Kotlin, like the KTX libraries.
         - Scala and Groovy should definitely work on LWJGL2 and LWJGL3, and may work on Android and iOS.
         - Clojure may technically work on Android but is usually incredibly slow without extra steps for Android
           compatibility; it's doubtful if it would work on iOS. You probably shouldn't use Gradle to build Clojure
@@ -138,12 +136,14 @@ for new projects generated by gdx-liftoff.
       various other versions, including the default Java compatibility. Typically, `Java version` is the minimum across
       all platforms, and should be 7 or more (8 is generally safe). You can set `Desktop Java version` to any version at
       least equal to `Java version`, and similarly for `Server Java version`; these only affect the LWJGL2/LWJGL3 and
-      Server modules, respectively. You can set `Java version` to as high as 16 if you have Java 16 installed, or
-      similarly for Java 11, 12, 13, 14, or 15, but it will require users to also have Java of that version, or for you
+      Server modules, respectively. You can set `Java version` to as high as 17 if you have Java 17 installed, or
+      similarly for Java 11, 12, 13, 14, 15, or 16, but it will require users to also have Java of that version, or for you
       to distribute a JRE of the appropriate version with your game.
-        - Distributing Java 14, 15, or 16 is much easier now thanks to Beryx'
+        - Distributing Java 14, 15, 16, or 17 is much easier now thanks to Beryx'
           "[Badass Runtime Plugin](https://github.com/raeleus/skin-composer/wiki/Deploying-libGDX-with-jpackage-and-Badass-Runtime),"
           which may be included in future versions to help ease the process of releasing a game.
+        - HTML projects this generates always use language level 8, even if the JDK is newer. A comment in
+          `html/build.gradle` provides some instructions for how to use an alternate backend and use as new as Java 11. 
 - Click generate, and very soon a window should pop up with instructions for what to do.
     - Generation is very fast here, relative to gdx-setup, because it doesn't run Gradle tasks at this point. When you
       see `SETUP COMPLETE` in green, the build is done; at the time you import the generated `build.gradle` project
@@ -173,7 +173,7 @@ see [libGDX's documentation](https://libgdx.badlogicgames.com/documentation/gett
 - If you had the GWT option checked in the setup and have a non-empty template,
   you can go through the slightly slow, but simple, build for GWT, probably using the `superDev`
   task for the `gwt` module, or also possibly the `dist` task in that module.
-    - GWT builds have gotten much faster with Gradle 7.2 (since Gradle 6, really) and some adjustments to
+    - GWT builds have gotten much faster with Gradle 7.3 (since Gradle 6, really) and some adjustments to
       configuration, so if you were avoiding GWT builds because of slow compile times, you might want to try again.
 - If you had the iOS option checked in the setup, you're running Mac OS X,
   and you have followed all the steps for iOS development with libGDX, maybe you can run
@@ -193,17 +193,19 @@ see [libGDX's documentation](https://libgdx.badlogicgames.com/documentation/gett
 Gradle has some quirks. Here's some notes on things you might encounter during upgrades from
 other projects or older versions.
 
-- All builds currently use Gradle 7.2 with the "api/implementation/compile fiasco" resolved. Adding dependencies
+ - All builds currently use Gradle 7.3 with the "api/implementation/compile fiasco" resolved. Adding dependencies
   will use the `api` keyword instead of the `compile` keyword it used in earlier versions. All modules use the
   `java-library` plugin, which enables the `api` keyword for dependencies.
-- You may need to refresh the Gradle project after the initial import if some dependencies timed-out;
+   - You can use the `implementation` keyword for dependencies in any module except `core`; this is supposed to
+   have some benefits, but I'm honestly not sure what they are.
+ - You may need to refresh the Gradle project after the initial import if some dependencies timed-out;
   JitPack dependencies in particular may take up to 15 minutes to become available if you're using any of those,
   like gdx-gltf. In IntelliJ IDEA, the `Reimport all Gradle projects` button is a pair of circling arrows in the
   Gradle tool window, which can be opened with `View -> Tool Windows -> Gradle`.
-- Like the official gdx-setup, the soon-to-be-shut-down `jcenter()` repo will not be used in new projects.
-    - In earlier versions, jcenter() was last in the list because of a different flaw it had that allowed impersonation.
-      You may have guessed that I am not sad to see it shut down in favor of better alternatives.
-      It's still annoying to have to deal with it closing on short notice, though.
+ - Like the official gdx-setup, the soon-to-be-shut-down `jcenter()` repo will not be used in new projects.
+   - In earlier versions, jcenter() was last in the list because of a different flaw it had that allowed impersonation. 
+   You may have guessed that I am not sad to see it shut down in favor of better alternatives.
+   It's still annoying to have to deal with it closing on short notice, though.
 
 ## Known Issues
 

README.md

@@ -35,6 +35,8 @@ you generate a project.
 - **Optional Gradle runner.** You can optionally execute Gradle tasks after project generation.
 - **Supports all libGDX backends.** Do you need the LWJGL2, LWJGL3, and/or Headless backends? Liftoff
 provides simple checkboxes to add any and all official platforms, plus some special other modules.
+- **Up-to-date.** This project prides itself on updating quickly when major external components update, such
+as Gradle or libGDX itself.
 
 What's more, there are no major *structural differences* between any generated projects, regardless of the platforms
 you initially used. The official `gdx-setup` previously put assets in the `android` module, or the `core` module if Android is

build.gradle

@@ -15,7 +15,7 @@ buildscript {
     }
 }
 
-version = "1.10.0.8-SNAPSHOT"
+version = "1.10.0.8"
 mainClassName = 'gdx.liftoff.MainKt'
 sourceCompatibility = JavaVersion.VERSION_1_8
 

src/main/kotlin/gdx/liftoff/config/Configuration.kt

@@ -39,7 +39,7 @@ import gdx.liftoff.views.widgets.ScrollableTextArea
 @Suppress("unused") // Fields accessed via reflection.
 class Configuration {
     companion object {
-        const val VERSION = "1.10.0.8-SNAPSHOT"
+        const val VERSION = "1.10.0.8"
         const val WIDTH = 600
         const val HEIGHT = 700
         const val PREFERENCES_PATH = "gdx-liftoff-prefs"

src/main/resources/templates/tabs/advanced.lml

@@ -8,15 +8,15 @@
         @version
         <textField id="version" tooltip="@versionTip" row="true">0.0.1</textField>
         @javaVersion
-        <floatSpinner id="javaVersion" min="7" max="18" value="8" step="1" precision="1"
+        <floatSpinner id="javaVersion" min="7" max="19" value="8" step="1" precision="1"
                       tooltip="@javaVersionTip"/>
         @serverJavaVersion
-        <floatSpinner id="serverJavaVersion" min="7" max="18" value="8" step="1" precision="1" row="true"
+        <floatSpinner id="serverJavaVersion" min="7" max="19" value="8" step="1" precision="1" row="true"
                       tooltip="@serverJavaVersionTip"/>
         @androidPluginVersion
         <textField id="androidPluginVersion" tooltip="@androidPluginVersionTip">4.2.0</textField>
         @desktopJavaVersion
-        <floatSpinner id="desktopJavaVersion" min="7" max="18" value="8" step="1" precision="1" row="true"
+        <floatSpinner id="desktopJavaVersion" min="7" max="19" value="8" step="1" precision="1" row="true"
                       tooltip="@desktopJavaVersionTip"/>
         @sdkVersion
         <intSpinner id="sdkVersion" min="9" max="31" value="$getSdkVersion" onChange="setSdkVersion" step="1"

version.txt

@@ -1 +1 @@
-1.10.0.7
+1.10.0.8