[Bug]: Can't run MapTool via the JAR file due to log4j errors

[kwvanderlinde]

Describe the Bug

When running the MapTool JAR from the command line, MapTool hangs on the splash screen and shows an error from log4j: No class provided, and an appropriate one cannot be found.

To Reproduce

1. Download the MapTool 1.10.4 JAR file: https://github.com/RPTools/maptool/releases/tag/1.10.4
2. Install a 16.0.2 JDK
   • I used Azul Zulu specifically to avoid issues with OpenJFX, but other installs likely show the same issue
3. Run the JAR file:

   java -jar MapTool-1.10.4.jar
   

4. Observe this error output:

   Exception in thread "main" java.lang.ExceptionInInitializerError
   	at net.rptools.lib.swing.ImageBorder.<init>(ImageBorder.java:46)
   	at net.rptools.lib.swing.ImageBorder.<clinit>(ImageBorder.java:26)
   	at net.rptools.maptool.client.AppConstants.<clinit>(AppConstants.java:41)
   	at net.rptools.maptool.client.AppSetup.installDefaultUIThemes(AppSetup.java:107)
   	at net.rptools.maptool.client.AppUtil.getUIThemeNames(AppUtil.java:419)
   	at net.rptools.maptool.client.AppUtil.getThemeFile(AppUtil.java:468)
   	at net.rptools.maptool.client.MapTool.loadTheme(MapTool.java:1803)
   	at net.rptools.maptool.client.MapTool.main(MapTool.java:1737)
   	at net.rptools.maptool.client.LaunchInstructions.main(LaunchInstructions.java:51)
   Caused by: java.lang.UnsupportedOperationException: No class provided, and an appropriate one cannot be found.
   	at org.apache.logging.log4j.LogManager.callerClass(LogManager.java:576)
   	at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:601)
   	at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:588)
   	at net.rptools.lib.image.ImageUtil.<clinit>(ImageUtil.java:47)
   	... 9 more
   

Expected Behaviour

It should be possible to run the MapTool via the JAR file without stalling due to errors.

Screenshots

No response

MapTool Info

1.10.4, JAR

Desktop

Linux Mint 20.2

Additional Context

No response

[kwvanderlinde]

I did some Google research and there was some indication that log4j fails when included in JARs that are not multi-release. This idea seems to have some merit, as I was able to run the JAR after hacking the line Multi-Release: true into the JAR's MANIFEST.MF. I don't know if there are any drawbacks to this (I know nothing about MR-JARs), but it would be straightforward to add to our build.gradle.

I also found out that we have this fun little note in our build.gradle introduced in #1127 / #1128:

    // Jamz: Do NOT update log4j libs without testing with uberjar build, 2.13.0 currently does not work
    // See open issue: https://issues.apache.org/jira/browse/LOG4J2-673
    implementation group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.13.0'
    implementation group: 'org.apache.logging.log4j', name: 'log4j-api', version: '2.13.0'
    implementation group: 'org.apache.logging.log4j', name: 'log4j-1.2-api', version: '2.13.0'	// Bridges v1 to v2 for other code in other libs

Not sure how related that note is, but it's pretty suspicious that we're on 2.13.0 now and that comment still exists...

[Phergus]

If I remember correctly the issue was because we were still on an older Java version (or was it older Gradle version?). Not sure. At the time however logging completely broke if we moved up to 2.13+.

Seems to be working now.

[Phergus]

Tested under Windows. Launches without issue now.