JDK 12 RFR of JDK-802856: Remove javac support for 6/1.6 source and target values

joe darcy joe.darcy at oracle.com
Sun Jul 8 17:01:22 UTC 2018


Please review the initial implementation of

     JDK-802856: Remove javac support for 6/1.6 source and target values

and the accompanying CSR:


I suspect at least one adjustment of the changeset will be needed, as 
discussed below.

All the langtools tests pass with these changes.

A few comments about the current state of the patch:

Updating the various components of the compiler was in part revisiting 
and then retiring some of the detailed engineering done for Project 
Coin, such as giving distinct error messages about a try statement 
lacking other pieces dependent on whether or not try-with-resources is 
supported under the source version in effect.

The refactoring in Source.java to use the Feature enum was easy to work 
with. Excising the now conceptually dead code and checks was 
straightforward. The enum constant for DIAMOND was *not* removed, 
although it is also semantically unconditionally true now just like the 
other introduced-in-7 features, because messages about diamond from 
checkSourceLevel called in the parser are used in the testing  of 
diagnostics generated for the preview feature functionality. I didn't 
dig down to try to determine the full set of interactions here. There is 
also support for the diamond finder elsewhere in the compiler. I think 
it would be acceptable to leave DIAMOND available as a enum constant if 
there are other uses for it.

While an earlier changeset cleared out uses of -source 6 and -target 6 
(JDK-8206439), various other tests needed updating since -source 7 is 
now obsolete. This was often handled by adding "-lint:-options" to the 
compile invocation. I'll file a follow-up issue to add "-lint:-options" 
to a handful of uses of -source 8 to avoid similar edits being needed in 
the future.

For expediency, I ignored the warning in make/data/symbols/symbols that 
to remove support for --release 6. This aspect of the change should be 
redone properly, but I thought it would be quicker to ask about this 
point during the code review than investigate how this aspect of the 
build works. Once the proper way is determined, I'll send a note to 
build-dev for a review of that aspect of the change.



More information about the compiler-dev mailing list