Changing Sources and Moving Targets: Evolving the javac command line
By Darcy-Oracle on Apr 14, 2013
As written up in
JEP 182: Policy for Retiring javac -source and -target Options, we're implementing a policy to over time clean up the
-target portions of
javac's command line:
- Class files going all the way back to version 45.3 generated by JDK 1.0.2 will continue to be recognized by
javacwhen put on the classpath, etc.
- The never-documented
jsr14have been removed in JDK 8 (8010179).
- In JDK 8, source and target options for 1.5 and below will be deprecated and a warning will be printed on their use (8011043).
- In JDK 9, source and target options for 1.5 and below will be removed (8011044).
- Starting in JDK 9, a "one plus three back" policy will apply to source and target options. JDK 9 will support (9/1.9, 8/1.8, 7/1.7, 6/1.6) and JDK 10 will support (10/1.10, 9/1.9, 8/1.8, 7/1.7) and so on.
Removing support for the old options will ease compiler maintenance in several ways. First, there will be direct benefits from allowing some code to be deleted. Nixing
jsr14 allowed about 250 lines of code to be excised. Second, fewer interactions between new language features and old source levels need to be handled in the compiler. The Java Language Specification only deals with a single version of the language and there is no formal specification of many aspects of how a Java compiler is supposed to behave. To use a recent example, there is no specification for how a new-in-8 default method being introduced to the language and core libraries by Project Lambda should appear to code being compiled under, say,
-source 6. Limiting the span of source and target version supported reduces the need to define such cross-version interactions. (The practical impact of source cross-version interfaces would be greatly reduced if developers more often follwed the recommended practice of setting the bootclasspath when cross-compiling to an older platform version.)