Future of Java

[tduva]

I'm opening this issue for further discussion and documentation of how the nearing changes in Java (mainly the Oracle version of it) affect Chatty. This is partly a continuation of this comment.

Things to investigate:

• Test building/running Chatty with different OpenJDK variants.
  • Ideally it should run on all variants, but of course there will be one that it's build in and mainly tested with.
  • I've tried OpenJDK 11 (specifically this download) and I didn't notice any issues (although I haven't tested very thoroughly), except for JTattoo using illegal reflection which apparently will break things in future versions.
• Javapackager (JavaFX) seems to be removed from the Java 11 JDK. I'm not sure if it is still going to be usable separately somehow.
  • Find out how JLink works and if it could be a viable replacement for Javapackager. It doesn't appear to create an executable like Javapackager, but can create custom image with a smaller size using the new module system.
  • A bundled JRE should definitely still be offered, especially if installing Java might become more confusing in the future. Either way it makes sure that the bundled JRE has been tested and people won't use versions that contain known bugs or are just really old (I've had error reports from people using JREs from years ago), at least as long as they update Chatty in the first place.
• Not sure what 32bit JDKs are still going to be available, but nothing in Chatty except for JIntellitype should be dependant on 32/64bit. I'm currently shipping the 32bit JRE with the Standalone merely because it uses a bit less RAM. I'm guessing pretty much everyone who would be using Chatty is on 64bit systems nowadays anyway.

Additional links that seemed interesting:

• https://blog.joda.org/2018/08/java-is-still-available-at-zero-cost.html
• https://blog.joda.org/2018/09/time-to-look-beyond-oracles-jdk.html

[lewisje]

It seems as if the big issue is with the generated Chatty.exe for the Windows standalone builds: A 32/64-bit version of that .exe expects a 32/64-bit JRE respectively.

[Dessa]

• the last time i checked the release plan from oracle, they expect you to bundle a JRE, oracle stopped offering a JRE download after java 10 (and thats EOL).
• #202 is sadly still a thing (well, was with 10, i am using non-hotkey builds ever since i started using a 11 build so i don't know the current status)
• if JLink is not a suitable replacement, consider using https://openjfx.io/ which is the split-out version of JavaFX edit: i have spoke to soon, javapackager is gone from 11 see JDK-8203379
• JDK8 is the only (non-EOL) 32bit option you have, 9 and higher dropped 32 bit support.

[Nerothos]

I'm not sure if it's relevant here but I've just saw a news about Amazon creating similar thing to openjdk https://aws.amazon.com/blogs/opensource/amazon-corretto-no-cost-distribution-openjdk-long-term-support/

[dehesselle]

FYI, in regards to packaging, JDK 13 is supposed to come with a replacement called jpackage.

[dehesselle]

I have just moved to OpenJDK 14. Chatty runs fine and jpackage (which didn't make it into JDK 13 and is still marked as being in incubation stage) does its job as well. It produces a slightly different application bundle layout on macOS (maybe on Windows as well?) but still painless.

[tduva]

I did some experimenting with AdoptOpenJDK 14.0.1 and building a windows bundle using jpackage.exe. It seems to run, although I haven't done extensive testing.

Here's a few issues I noticed though:

• Starting Chatty with the generated Chatty.exe no longer sets the working directory to the app directory, but rather the one the Chatty.exe is in. This makes some sense, but unfortunately it's a change from javapackager so it will break things without adding workarounds to programs run with it. Could probably add a launch parameter that tells Chatty to change working directory.
• The library used for global hotkeys (JIntellitype) doesn't appear to support newer Java versions, so there would have to be a replacement for that.
  • https://github.com/java-native-access/jna
    • https://github.com/tulskiy/jkeymaster
    • Example
    • Example/Explanation
  • https://github.com/kwhat/jnativehook
  • https://github.com/kristian/system-hook
• I managed to build a modular application bundle using jdeps on the Chatty.jar and compiling/adding the module-info to the jar manually. It runs, however for some reason any HTTPS requests other than Twitch API seem to fail with an SSLHandshakeException. I'm not sure why that would happen, since it's running the same Java version, just bundled differently. Ideas as to why Twitch API requests work: Different code that handles it, different HTTP version or certificate? The advantage of the modular application bundle is mainly that it's smaller, so it wouldn't be too bad to not use it at first.
• The runtime/lib/fonts/fallback directory seems no longer documented for this Java version, and I haven't really been able to add a fallback font some other way. The directory still seems to work, although I'm not sure if that is intended or how long it will keep working.

[tduva]

I have moved to JKeyMaster/JNA for global hotkeys, which hopefully works well for future versions. This also has the advantage that global hotkeys could also work on Linux/Mac and separate 32/64 bit packages are not required since the native libraries are extracted from the jar as necessary (this increases the jar size some more, but I guess that's ok).