streamline Java versions

[timobaumann]

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 2026 Java 17 through at least 2029 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 to pave a way beyond 2030.

[timobaumann]

charset issues solved in issue 220