A recent Java Enhancement Proposal, targetted for Java 8 and Java 9, aims to codify the support model for the -target
and -source
directives used by the Java compiler. The proposal states that the compiler will support at most three versions behind the version of the Java compiler itself.
The -target
flag allows the compiler to target a specific version of the Java class format. Although typically specified as Java versions such as 1.5 or 1.6, this actually translates to the bytecode version used in the generated output:
- 48: Java 4
- 49: Java 5
- 50: Java 6
- 51: Java 7
- 52: Java 8 (not yet released)
- 53: Java 9 (not yet released)
The -source
flag allows the compiler to recognise or treat as errors new language constructs, such as lambdas, try-with-resources, strings-in-switch and so on. Some new language features (such as lambdas) require the use of specific bytecode features (such as invokedynamic
). As a result, it is often not possible to use a newer source version than the target version.
JEP 182 clarifies that at most 3 versions of the -target
and -source
will be supported by the compiler going forwards. With the demise of Java 6 earlier this year, the limitation to only support Java 6 onwards for the Java 8 compiler (and therefore Java 7 for the Java 9 compiler), this restriction is unlikely to affect anyone in a significant way. However, some build tools (such as Maven) default to a source compatibility version of 1.5 if not otherwise specified, which may require an update in order to run on Java 8.
The change has already begun; the jsr14
and 1.4
targets are no longer accepted in Java 8, and the use of 1.5
will generate warnings. Java 9, when released, will remove support for 1.5
and raise warnings for 1.6
.
From a practical perspective, this may not seem like a big change; but up until recently, the OSGi runtimes were compiled with -source 1.5 -target jsr14
to generate code that was capable of embodying generics but emitting bytecode compatible with J2ME. The use of jsr14
was removed last year from the Eclipse codebase. Since Android has all but killed off J2ME (and in any case, OSGi runtimes such as Felix and Equinox remain available should the commercial need exist) the fact that they are compiled with more recent runtimes should not be an issue for the majority of Java developers.