streamline Java versions

timobaumann commented 1 year ago

Java is way too agile but there we are. There are, at present a number of LTS versions of Java, Java 7 through 2022 Java 8 through at least 2030 Java 11 through at least 2032 Java 17 through at least 2029 Java 21 through at least 2031 I propose that we ditch Java 7 -- it seems we already state source compatibility of 1.8 in at least one build.gradle I've updated the dependency to grgit (which depends on jgit) so that we can again compile against Java 8 (see f7f4bbb1)

Now, Java 11 deprecated writing (via reflection) to Charset.defaultCharset and Java 16 started to fail with us writing there (see #208). We do this in order to ensure UTF-8 as default Charset all across the board. It is only with Java 18 that UTF-8 will be default. So, we're stuck inbetween.

Java 11+ can be instructed to allow reflective access to Charset.defaultCharset via a commandline switch. Now, what's annoying is that Java 8 doesn't know about this commandline switch and complains about it.

I propose that we:

stick with Java 8 source compatibility for the moment (and always compile Java 8 for distributions),
get rid of the reflective access to defaultCharset and have people set the defaultCharset before starting the JVM,
add -Dfile.encoding=UTF8 when calling gradlew run and to to the sh/zsh/bat-files that are generated by JInstaller
gradually start dealing with the deprecation messages that appear when one compiles with Java 17/21 to pave a way beyond 2030.

timobaumann commented 1 year ago

charset issues solved in issue 220

timobaumann commented 1 month ago

timobaumann commented 2 weeks ago

I've added some notes to the wiki about our history with Java versions and close this now.

dialogos-project / dialogos

streamline Java versions #219