Java 9 to Drop Support for Compiling 1.5 and Older Source Code

by Alex Blewitt on Jun 28, 2013 |

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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.