github workflow should use the various java versions to test,
which permits to test especially 2d rendering differences.
the javac release flag is set to produce java8 binaries in
any case. not perfect, but we only loose a warning that
applets are to be removed after java17, trivial to display
by adding the javac release property, when using java17:
mvn --batch-mode compile -Dmaven.compiler.release=17
gradle clean build -x javaDoc -PjavacRelease=17
better would be to separate build and test, as suggested
by https://github.com/matthew16550, here:
https://github.com/plantuml/plantuml/pull/904
activate javac --release only on higher java versions. it allows to compile
with java11+, but permits afterwards running tests with java8 to make sure
rendering errors can be catched.
parmit the syntax of the source to include java17, and tell the user about
it instead of just failing the compilation.
it runs on all platforms with java-17, but the javac release flag
is set to 8, 11, and 17 respectively. artifact upload happens
from latest ubuntu LTS, 20.04, java-8.
for gradle now one could do:
gradle clean build -x test -x javaDoc -PjavacRelease=17
for maven something like this works to build a different target binary:
mvn clean package -Dmaven.test.skip=true -Dmaven.javadoc.skip=true -Dmaven.compiler.release=17
javac since java9 has a new flat --release to build a binary which can be run
with an older java. the public API of that older release must be followed as
well.
the flags used before, -source, -target do not do this. therefor it got
unnoticed that plantuml did not compile and run in java7 any more, despite
beeing compiled for for java7.
https://github.com/plantuml/plantuml/issues/898
i placed a christmas wish request that intellij changes its default to respect an
empty .editorconfig but chances seem to be slim they'd really do it:
https://youtrack.jetbrains.com/issue/IDEA-287505.
give in and use an intellij property to stop it reformatting SVG on global reformat.
