Feature Upgrade Java version from 1.8 for building / running Mafia

[gausie]

If we move to Java 9, we get libraries for interfacing with the System Tray / Dock, potentially obviating apple.dts.samplecode.osxadapter and lib.com.jeans.trayicon.

I was going to bring this up separately, but I think we could afford to upgrade the required Java version this month. The 17 (LTS) comes out this month. I really would like to move towards keeping us pinned to the latest LTS, but as a stop gap we could upgrade to the previous LTS, which would be 11.

 

[fronobulax]

I was going to bring this up separately, but I think we could afford to upgrade the required Java version this month. The 17 (LTS) comes out this month. I really would like to move towards keeping us pinned to the latest LTS, but as a stop gap we could upgrade to the previous LTS, which would be 11.

The resistance I recall to upgrading the Java standard has two components. One is that hola, Our Founder, insisted on being able to develop on an Apple system that could not be upgraded. The second was that it was believed that there were users in a similar situation. Unless there is an active dev willing to admit the are running on ancient Apple hardware the first reason is no longer valid. Since, AFAIK, we can generate bytecode for an early version we can now deal with the latter case if any such users identify themselves.

So, let's upgrade. I could argue that early adoption has a price that perhaps we don't want to pay but if others think we should jump to 17 when it comes out, I'm OK with that.

 

[gausie]

@fronobulax that's all I needed to hear

 

[heeheehee]

r20916 simplifies the process of upgrading our java version to editing a single value in default.properties (thereby updating both our Ant and Gradle builds), rather than having to hunt down a dozen places where we set it manually.

 

[MCroft]

@fronobulax that's all I needed to hear

I'm in favor as well, but I recall some code that we ran into with Java 15 that were reporting future deprecations that looked time-consuming to resolve.

The resistance I recall to upgrading the Java standard has two components. One is that hola, Our Founder, insisted on being able to develop on an Apple system that could not be upgraded. The second was that it was believed that there were users in a similar situation. Unless there is an active dev willing to admit the are running on ancient Apple hardware the first reason is no longer valid. Since, AFAIK, we can generate bytecode for an early version we can now deal with the latter case if any such users identify themselves.

Heh. I wonder when he went Mac? In the long-ago when I was Darwinlet, he was pretty Mac-illiterate and I reported a lot of mac-specific bugs.

So, let's upgrade. I could argue that early adoption has a price that perhaps we don't want to pay but if others think we should jump to 17 when it comes out, I'm OK with that.

From 8 to 17 would be a big jump, and there's at least a few features we currently use that are deprecated, but probably less "fix it" work than 6 to 8 was.

IIRC, I had a working compile with just a few changes in Java 14 last year. So unless they took a big leap, we might be in good shape.

@gausie, could excavator (or something excavator-like) capture the Java major version to see what's in-use in the field, for at least part of the field?

 

[heeheehee]

java.release=16 compiles today, with 3 deprecation warnings in src/, and many unchecked warnings because we're using generic types in an unsafe manner. The deprecation warnings in src/ are resolved in r20917.

As for deprecation warnings in lib/: there are many more. A number go away by switching swingx to the jar (at the expense of some binary bloat; r20918), and the rest seem to be fairly straightforward fixes (although I would prefer to remove obsolete dependencies rather than fix them).

 

[heeheehee]

(I split this into a separate thread so it's clearer what the discussion is about.)

It looks like BareBonesBrowserLaunch primarily handles launching a non-default browser, at this point. It doesn't seem like java.awt.Desktop allows for this to be configured at all, so if we want to keep this feature, we'll want to keep something like it around. (Not to say we can't clean up the logic -- we no longer need reflection for java.awt.Desktop.browse, and once we move to Java 9, we should remove the Mac-specific reflection, too.)

A thread from last year regarding OSXAdapter: https://kolmafia.us/threads/java-14-no-longer-compatible-with-current-osxadapter.25285/

When we move to Java 9+, we should remove those instances of reflection, and use java.awt.Desktop directly at the callsites.

java.awt.SystemTray (and TrayIcon, and PopupMenu) has existed since 1.6, according to Oracle's docs. @fronobulax or someone else on Windows, if I post a patch to rip out the com.jeans.trayicon dependency, do you mind taking it for a spin? (I could try it out myself, but it'll require copying the jar to another computer.)

 

[fronobulax]

Heh. I wonder when he went Mac? In the long-ago when I was Darwinlet, he was pretty Mac-illiterate and I reported a lot of mac-specific bugs.

I could be misremembering things or just using incorrect terminology. I used a Xerox Alto and an Apple II professionally but pretty much nothing else in the Apple hardware line so I won't get the vocabulary right. I have a friend who lived in the Apple ecosystem who was full of stories about how Apple would do something that made the older hardware incompatible or obsolete. He finally retired his Lisa early in this century.

In any event my recollection is that Hola had multiple machines that were various generations of Apple hardware. He wanted to be able to run KoLmafia on any of them and one of them was old enough that the Java version was 1.3 (or maybe 1.5) and could not get upgraded because Apple chose not to provide an upgrade. The pi$$ing contests involving Sun/Oracle and Apple may also have been a factor.

@gausie, could excavator (or something excavator-like) capture the Java major version to see what's in-use in the field, for at least part of the field?

I love the idea. At the moment excavator is opt in and event triggered so we would have to figure out how to encourage adoption. We would also need a user or code to aggregate the information.

(After pushing back on the number of steps required for installation I finally embraced excavator and am collecting beaten up incidents in hopes I can find the data or logic problems I suspect exist in SimpleSmack or BatBrain).

 

[fredg1]

and many unchecked warnings because we're using generic types in an unsafe manner.

Tried to help

https://kolmafia.us/search/103991/

 

[heeheehee]

Tried to help
https://kolmafia.us/search/103991/

I'll take a look if you update the patches with tests and bump the threads (@ me or whatever)

 

[fredg1]

I'll take a look if you update the patches with tests and bump the threads (@ me or whatever)

For the patches that come with logic changes, sure, but is it also necessary for those that only add generics? Type erasure and all that.

 

[heeheehee]

The point of tests for refactors is to make sure existing input/output behavior is unchanged, and, it helps the next person who wants to come in and touch that code.

If the only change is adding types to variable declarations, that's likely safer. But that first patch you point at also adds some additional code around deduplicating logic and reducing reuse of mainList. It looks safe, but I've seen my share of outages from changes that looked safe.

 

[heeheehee]

Apparently the current version of OpenClover refuses to instrument targets greater than Java 9. So if we wanted to upgrade today, we wouldn't be able to go very far without breaking our coverage reporting.

There are other coverage libraries like JaCoCo which purport to support more modern versions of Java.

 

[heeheehee]

Also, note that Gradle doesn't support Java 17 yet, but they're... less behind (Gradle 7.0, which we're using, supports Java 16).

Supposedly 7.2 does (sort of), but we had to downgrade to 7.0 because 7.2 was weirdly flaky for us.