Bug - Fixed r25726 crashes on launch due to unchecked use of new Taskbar APIs

Magus_Prime

Well-known member
Sorry I can't provide any more detail. On a Windows 10 computer with Java 1.8.0_301 installed r25726 crashes on launch. I see it start in task manager and then it dies.

r25718 works as expected.
 

heeheehee

Developer
Staff member
Hi! I'd like to point you to this stickied bug and recent announcement. In short, Java 8 is no longer sufficient for running Mafia. You'll need to download a newer version (at least Java 9, but preferably Java 17, which was marked for general availability in the past few weeks).

Make sure you also uninstall Java 8 after doing so.
 

Magus_Prime

Well-known member
Huh. I could have sworn I had a more recent version of the JDK installed.

Edit: I do. KoLmafia was just "finding" Java 1.8 first. Uninstalled. Sorry for the confusion.
 

heeheehee

Developer
Staff member
It's especially confusing because Java 8 is still nominally supported (update 301 came out in August), and if you go to java.com, it'll point you to Java 8. But it doesn't contain any of the latest features / libraries.
 

Magus_Prime

Well-known member
What was "really" annoying (as an act by Oracle) is that I have the Java 17 JDK installed but because Java 8 was also installed 17 was ignored. Sigh.
 

AlbinoRhino

Active member
I am confirming the same behavior with Windows 10 Pro and a local build. Reverting the last commit (leaving the gradle cache commit in place), allows everything to work again.

Same behavior. javaw.exe task opens and then almost immediately closes.
 

Magus_Prime

Well-known member
Okay...I'm now even more confused. r25718 supposedly requires Java > 8 and it ran just fine before removing Java 8. My bad that I didn't restart KoLmafia and test under just the JDK.

Edit: And AlbinoRhino just explained what is happening. Thank you.

So I guess this "is" a bug after all. :)
 

fronobulax

Developer
Staff member
What was "really" annoying (as an act by Oracle) is that I have the Java 17 JDK installed but because Java 8 was also installed 17 was ignored. Sigh.
My pet peeve in one professional environment was the requirement to keep multiple versions of Java on my system as well as 32 and 64 bit versions. Predicting which version would get used was a PITA since browsers, command line tools and OS level file associations did not find things in the same order without tweaking configurations.

My recommended practice is to only have one instance and of it is the JDK track down and disable any hidden JREs.
 

MCroft

Developer
Staff member
hehe...

Code:
$ archlinux-java status
Available Java environments:
  java-11-openjdk
  java-16-openjdk
  java-17-jdk (default)
  java-8-jre/jre
  java-8-openjdk
This is my "cleaned, just a year or so ago" status:
Code:
Michaels-MBP:licenses mcroft$ /usr/libexec/java_home -V

Matching Java Virtual Machines (8):
    17 (x86_64) "Eclipse Temurin" - "Eclipse Temurin 17" /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
    17 (x86_64) "Azul Systems, Inc." - "Zulu 17.28.13" /Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home
    16.0.1 (x86_64) "Azul Systems, Inc." - "Zulu 16.30.15" /Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home
    15.0.1 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 15" /Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home
    15 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK (OpenJ9) 15" /Library/Java/JavaVirtualMachines/adoptopenjdk-15-openj9.jdk/Contents/Home
    13.0.2 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK (OpenJ9) 13" /Library/Java/JavaVirtualMachines/adoptopenjdk-13-openj9.jdk/Contents/Home
    10.0.1 (x86_64) "Oracle Corporation" - "Java SE 10.0.1" /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
    1.8.0_201 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home

This nice thing is I can put export JAVA_HOME=`/usr/libexec/java_home -v17` in a script and it will set JAVA_HOME to the newest JDK for Java 17...
 

Veracity

Developer
Staff member
Code:
[bash-3.2$ /usr/libexec/java_home -V

Matching Java Virtual Machines (13):
    17 (arm64) "Eclipse Temurin" - "Eclipse Temurin 17" /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
    16.0.2 (arm64) "Azul Systems, Inc." - "Zulu 16.32.15" /Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home
    14.0.2 (x86_64) "Oracle Corporation" - "OpenJDK 14.0.2" /Library/Java/JavaVirtualMachines/jdk-14.0.2.jdk/Contents/Home
    1.8.281.09 (x86_64) "Oracle Corporation" - "Java" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
    1.8.0_172 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
    1.8.0_131 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home
    1.8.0_121 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home
    1.8.0_40 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home
    1.7.0_67 (x86_64) "Oracle Corporation" - "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home
    1.7.0_65 (x86_64) "Oracle Corporation" - "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_65.jdk/Contents/Home
    1.7.0_55 (x86_64) "Oracle Corporation" - "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home
    1.7.0_51 (x86_64) "Oracle Corporation" - "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home
    1.7.0_05 (x86_64) "Oracle Corporation" - "Java SE 7" /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home
Yeesh. I should clean up!
 

fronobulax

Developer
Staff member
My recommended practice is to only have one instance and if it is the JDK track down and disable any hidden JREs.
Tongue was somewhat in cheek but it is true that I am at a place where I can dictate what version of Java is on the machine I use for KoLmafia as opposed to using KoLmafia on a machine where other apps and policies determined what versions had to be present.

The technology exists to build a jar and package it with a jre and run the jar with the packaged jre regardless of what is installed on the system. When we get a breather and stop working so hard on things required because we deprecated Ant and SourceForge and cool things we can now do easily with Gradle then maybe can can look at ways to bundle.
 

MCroft

Developer
Staff member
The technology exists to build a jar and package it with a jre and run the jar with the packaged jre regardless of what is installed on the system. When we get a breather and stop working so hard on things required because we deprecated Ant and SourceForge and cool things we can now do easily with Gradle then maybe can can look at ways to bundle.

It's in Java 16, so after we take the next charge along the rain-slicked precipice of modernization and start using Java 17, we can look into that enhancement.

I think I recall it requires modularization to be useful/effective, but that might've been the incubator version.
 

heeheehee

Developer
Staff member

It's in Java 16, so after we take the next charge along the rain-slicked precipice of modernization and start using Java 17, we can look into that enhancement.

I think I recall it requires modularization to be useful/effective, but that might've been the incubator version.
Do we need to target Java 16+, or is it sufficient to build with Java 16+? If the latter, we could probably do this today.
 
Top