Unable to run application on Linux with Java 11+

[czyzby]

java -jar yields the following error logs:

WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.lwjgl.LWJGLUtil$3 (file:/home/mj/Downloads/gdx-liftoff-1.9.10.5.jar) to method java.lang.ClassLoader.findLibrary(java.lang.String) WARNING: Please consider reporting this to the maintainers of org.lwjgl.LWJGLUtil$3 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!

It seems that you should use LWJGL3 (if you are not already) or update to a newer version of LWJGL.

[tommyettinger]

Ah yes, this issue. You should come to the libGDX Discord! This issue has resurfaced among many different apps, all of which it resolved down to being a buggy JDK, typically Corretto or an older Ubuntu distro JDK. AdoptOpenJDK has never thrown these ld.so bugs, and I probably link to AdoptOpenJDK on average 5 times a week. I'd go back to LWJGL3 but I'd like to still keep the pack command, which uses gdx-tools, which uses LWJGL2, and having both LWJGL 2 and 3 as dependencies causes a different frequent crash, and because gdx-tools becomes a dependency for the user project, that's not so good either. If you could try an earlier version from the releases that uses LWJGL3 (I think 1.9.10.4 probably uses it), you can verify if the problem is independent of LWJGL.

[czyzby]

1.9.10.4 does run on my JVM. 1.9.10.5 fails on the reflective access operation.

[tommyettinger]

It's not the reflective access operation, that's a warning. It happens because Java versions starting with 9 are more strict about certain operations, like using sun.misc.Unsafe. I am surprised that 1.9.10.4 runs, but it's definitely possible that the ld.so bug is LWJGL 2 only (while still being JVM-dependent). I'll probably go back to LWJGL3 then, and remove any dependency on gdx-tools/LWJGL2 (and so remove the pack task). I think I may just forward people to Skin Composer and Raymond Buckley's skins, so they can choose from lots of existing ones or make their own visually, instead of packing a default skin... Maybe I'll pick one as a default.

I'll leave this open until I release a new version that goes back to LWJGL3. You should still change your JVM because games that use LWJGL2 will probably give the same crash, including any testing you do with an LWJGL2 target. https://adoptopenjdk.net/ has good VMs.

[tommyettinger]

I believe this is resolved as of the latest release, which goes back to LWJGL3, removes gdx-tools from the app, and replaces the pack task with just copying in a dummy skin (uneditable, but it can be unpacked if needed). This does also speed up initial project generation when using a GUI.

[czyzby]

You can execute pack via Gradle and don't use gdx-tools directly. I believe this is what was done initially by the forked gdx-setup.

[tommyettinger]

Yeah, but it still led to a confusing setup where gdx-tools was a buildscript dependency but couldn't be an app dependency. Running pack also added to project gen time, and the lightning-fast generation is definitely a nice feature of gdx-setup and so also gdx-liftoff. I think that most users either want a default skin as fast as possible or will make their own skin (and so would only need a skin to run early on); customizing the default skin probably isn't the most common use-case, but it can still be done by unpacking the skin's atlas.

Also, thanks for gdx-setup! I thought you had left libGDX.

[czyzby]

I focus on KTX entirely these days, my old Java libraries are difficult to maintain - I was inexperienced when I started these projects and it shows. Lacks of unit tests makes them tedious to fix.

[tommyettinger]

You're right, this old Java Kotlin library application is a challenge to maintain. It's still miles better than the official setup to work with. I've had a few headaches with LML here and there, and upgrading everything to use libGDX 1.9.10 (maybe soon 1.9.11) was a minor ordeal. But it works, most of the time, and your fairly large codebase was organized well when I started here.

Also, a helpful user on the libGDX Discord has found your Autumn library and I think is using it now, since he's also recommending it. If it's been superseded by another library (he does use GWT, so Kotlin is out for now), it would be great to know.

[czyzby]

this old ~Java~ Kotlin ~library~ application is a challenge to maintain

Touché. ;) In my defense, it was around the same time I was still developing LML/Autumn. gdx-setup was my first major Kotlin project and I don't think KTX even existed at the time (I started it around May, 2016, and KTX around July, 2016). I believe that's what initially inspired me to start KTX in the first place, and this time doing it the right way - with full unit test suites of each feature.

If it's been superseded by another library (he does use GWT, so Kotlin is out for now), it would be great to know.

I don't think so. I'm not aware of any library that provides Spring-like dependency injection for all LibGDX platforms like Autumn, or anything that comes close to LML in terms of UI building - maybe with the exception of ktx-scene2d DSL. @metaphore maintains an application using Autumn MVC and he considered maintaining a fork of my libraries, but I'm not sure if it got far.

The thing is - these projects are fine... when they work. Autumn simplifies application setup at the cost of some hidden framework complexity and non-intuitive behavior (automatic component scanning and so on). LML approach of "views as assets" speeds up prototyping, eases modding, and makes hot UI reload trivial to implement. However, when you run into a bug or a weird parser behavior, you're stuck with workarounds or parts of the UI implemented in Java.

I still think the ideas behind them are valid, it's just that I don't have the time for a complete rewrite and would rather focus on KTX at this point.