Update FCS to fix a rare crash.

[tommyettinger]

At least one Ubuntu 20.04.3 LTS machine was unable to open an otherwise valid JAR using autumn's fast classpath scanner, and I tracked it down to the older version of FCS that gdx-lml still uses. I had updated it previously, which had fixed it for me, until I switched my dependencies all to the crashinvaders fork. That brought FCS down to version 2.0.4 when it has been 2.21 before, and started the crashes for the Ubuntu machine. The crashes happened every time at startup, regardless of what classpath scanner was used.

This is not a complex fix (one line of Gradle), so it doesn't really need an issue reported -- we should just try to be up-to-date with dependencies as long as they maintain compatibility.

[metaphore]

A very nice find, thanks! I've got a few reports about similar issue for my projects that are based on LML, never dig into it though. I reckon it deserves a hotfix release.

[metaphore]

I'm not very familiar with the FCS library, but quick googling revealed that there's another project replacing the old one - ClassGraph.

I took a step forward and put it in place of FCS for desktop class scanner implementation. Seems to work fine for some of my Autumn based projects I tested it with. They have a bit disturbing section covering the issues with JRE16+. Not sure if annotation only class lookup is affected, but I guess FCS falls short for it too and it would do as is for a while.

@tommyettinger I'd appreciate it if you could grab the latest snapshot (1.10.1.10.0-SNAPSHOT) and see if it's stable with gdx-liftoff?

[tommyettinger]

On it! Sorry for the late reply.

[tommyettinger]

So I have to go through an intermediate layer (Beatrix, the only person whose machine has had issues with FCS 2.0.4) to test this. I just heard back from Beatrix that something is failing in the classpath scanning stage with the latest 1.11.1.10.0-SNAPSHOT:

Exception in thread "main" com.badlogic.gdx.utils.GdxRuntimeException: Unable to scan classpath.
    at com.github.czyzby.autumn.nongwt.scanner.FallbackDesktopClassScanner.findClassesAnnotatedWith(FallbackDesktopClassScanner.java:58)
    at com.github.czyzby.autumn.context.ContextInitializer.initiateMetaComponents(ContextInitializer.java:361)
    at com.github.czyzby.autumn.context.ContextInitializer.initiate(ContextInitializer.java:291)
    at com.github.czyzby.autumn.mvc.application.AutumnApplication.initiateContext(AutumnApplication.java:78)
    at com.github.czyzby.autumn.mvc.application.AutumnApplication.create(AutumnApplication.java:65)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.initializeListener(Lwjgl3Window.java:405)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update(Lwjgl3Window.java:355)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop(Lwjgl3Application.java:142)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:116)
    at gdx.liftoff.MainKt.main(main.kt:132)
    at gdx.liftoff.MainKt.main(main.kt)
Caused by: java.lang.NullPointerException
    at com.github.czyzby.autumn.nongwt.scanner.FallbackDesktopClassScanner.getJarFilesToProcess(FallbackDesktopClassScanner.java:135)
    at com.github.czyzby.autumn.nongwt.scanner.FallbackDesktopClassScanner.extractFromJar(FallbackDesktopClassScanner.java:121)
    at com.github.czyzby.autumn.nongwt.scanner.FallbackDesktopClassScanner.findClassesAnnotatedWith(FallbackDesktopClassScanner.java:53)
    ... 10 more

The current snapshot of gdx-liftoff only goes to the FallbackDesktopClassScanner if a GdxRuntimeException was already thrown and not caught while creating an AutumnApplication with a DesktopClassScanner. The only line in Liftoff mentioned there is this one.

I didn't try 1.10.1.10.0-SNAPSHOT because it looked like either I had misconfigured the S01 Sonatype repo or that release wasn't valid. I did later get the S01 repo working.

[tommyettinger]

...Is it just me, or was there an Issues tab a few days ago, and it isn't there now?

[metaphore]

Sorry, been pretty busy this week. And thanks for checking on it.

It was actually my fault. I accidently bumped up the version to 1.11, published the snapshot and then rolled back to 1.10... But I believe they artifacts were identical so all good.

All in all quite strange. I wonder if it has anything to do with the latest JDK/JRE 15+ security limitation. It might help to try to reproduce it in the similar environment. Could you please ask about the configuration details of the machine where it's failing? Or maybe invite the person to this thread on GitHub?

[tommyettinger]

Unfortunately, it's the holidays, 🎄 and they're out of town. I am pretty sure the machine that has problems runs Ubuntu, but I don't know specifics. I know JDK 17 has some pretty severe limits on reflection as it affects the JDK core libraries. I think we may have to wait a week or so before they get back and can test. New Year's Liftoff release, probably.

[metaphore]

No worries, there's no rush.

I'll play around with some recent JDKs and post here if there are any related issues.

[tommyettinger]

OK, this is way too late to mention this, but I've been using gdx-lml version 1.9.1.10.0 with a specified dependency on io.github.lukehutch:fast-classpath-scanner:2.21 because gdx-lml version 1.10.1.11.0 seems to fail to find anything on the classpath once compiled into a JAR. I pretty much have been avoiding touching this code because it is so fragile. The error I get only happens when I try to run the compiled JAR (gdx-liftoff) that uses 1.10.1.11.0 and its ClassGraph classpath scanning:

C:\d\jvm\jdk8-hotspot\bin\java -jar gdx-liftoff-1.11.0.1-SNAPSHOT.jar
Exception in thread "main" com.badlogic.gdx.utils.GdxRuntimeException: Unable to scan classpath.
        at com.github.czyzby.autumn.nongwt.scanner.FallbackDesktopClassScanner.findClassesAnnotatedWith(FallbackDesktopClassScanner.java:58)
        at com.github.czyzby.autumn.context.ContextInitializer.initiateMetaComponents(ContextInitializer.java:361)
        at com.github.czyzby.autumn.context.ContextInitializer.initiate(ContextInitializer.java:291)
        at com.github.czyzby.autumn.mvc.application.AutumnApplication.initiateContext(AutumnApplication.java:78)
        at com.github.czyzby.autumn.mvc.application.AutumnApplication.create(AutumnApplication.java:65)
        at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.initializeListener(Lwjgl3Window.java:416)
        at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update(Lwjgl3Window.java:366)
        at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop(Lwjgl3Application.java:192)
        at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:166)
        at gdx.liftoff.MainKt.main(main.kt:132)
        at gdx.liftoff.MainKt.main(main.kt)
Caused by: java.lang.NullPointerException
        at com.github.czyzby.autumn.nongwt.scanner.FallbackDesktopClassScanner.getJarFilesToProcess(FallbackDesktopClassScanner.java:135)
        at com.github.czyzby.autumn.nongwt.scanner.FallbackDesktopClassScanner.extractFromJar(FallbackDesktopClassScanner.java:121)
        at com.github.czyzby.autumn.nongwt.scanner.FallbackDesktopClassScanner.findClassesAnnotatedWith(FallbackDesktopClassScanner.java:53)
        ... 10 more

The issue might be related to the FallbackDesktopClassScanner it's using.

[metaphore]

Thanks for the update Tommy! Well at least it successfully fails on JDK 8, which in my case works flawlessly. A good thing to know that it's not simply the latest JDK issues... I will keep researching on it.

[tommyettinger]

A possible update; this line will always fail on Windows: https://github.com/crashinvaders/gdx-lml/blob/master/autumn/src/main/java/com/github/czyzby/autumn/nongwt/scanner/FallbackDesktopClassScanner.java#L103

It tries to split on a regex, but on Windows OSes, that regex pattern is "\", which is not valid. I'm still avoiding updating past 1.9.1.10.0 because of this, over a year later...