Java 9, like every release, has caused a load of code to stop building. This page attempts to capture some of the solutions.
The -source and -target arguments no longer accept values below 1.6.
Maven and ant have been patched to automatically move things to at least 1.6. Everything else needs to the build system fixing.
Note that it's rumoured that 1.6 will be dropped in "Java 10", so if you can move things to 1.7 or 1.9 immediately, then that will be fine.
However, the 1.6 source level introduces stricter encoding and generics checks: things that may previously have been warnings on javac -source 1.5, are errors on javac -source 1.6. Most of these things are easy, but annoying, to fix.
Note that many builds will succeed without the -source/-target arguments provided; if they are not present, then Java defaults to using the latest versions.
_ may not be used as a keyword
For things not specifying -source, the default source level has changed to 9, which prevents _ being used as an identifier. This breaks gettext users. The easiest solution is to change to -source 1.8.
javax.xml.bind / javax.activation
These packages have been removed from the JDK, but are still available as modules.
> I've discovered yesterday that the package hasn't been actually removed, it's still there but not in the default classpath. It's still accessible with javac -source/target or -release <= 8, and when targeting Java 9 the "-add-module java.activation" must be specified
Some write-up here:
> At runtime the --add-modules option is also required, but Java 8 rejects it. It's impossible to have a single command line to start an application that works with both Java 8 and Java 9.
There are implementations on Maven, which used to be in Debian but have been removed. It's not known if these will actually work on Java 9.
Someone needs to decide what Debian is doing about this.
swing / *ComboBox
There have been some, ... mistakes in the addition of generics to some ComboBox and TreeNode related classes. We don't really have a solution to this at the moment, beyond hoping that one of the upstreams wants to make their codebase much worse to work around it.
Some complaining, with references: https://lists.debian.org/debian-java/2017/08/msg00093.html
Failed to find JDK / tools.jar
The path of everything inside $JAVA_HOME has changed, and the java -version / java.version values have changed in ways that break terrible build scripts.
java.version is now "9", not "1.9", as many were expecting (e.g. https://ssl.icu-project.org/trac/attachment/ticket/13330/icu4j.diff).
java.home does not end in /jre, so it must not be stripped off. (e.g. https://github.com/mikiobraun/jblas/pull/91)
tools.jar isn't necessary for many APIs (i.e. just stop the build system from whining it can't find it), and others are just gone.
There's a build system named "equivalence" kicking around, a perl, hand-maintained script named ./configure. There's so few of them that it's probably worth just patching all of them: https://github.com/respawner/gnome-split/pull/1/commits/0980c2939673c53ab530fda82be1075a69525e8d
`cannot find symbol` during javadoc
Javadoc generation is now more strict about the classpath being wrong during documentation generation. This should be fixable by fixing the classpath.
Sometimes this happens with Maven, cause unknown: https://bugs.debian.org/873249#10
When it happens with ant or shell as the build system, it's probably a problem with the build file?