JDK-8242284 : Bootstrap javac having problem finding features flags
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 14
  • Priority: P2
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2020-04-07
  • Updated: 2020-10-29
  • Resolved: 2020-10-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16Resolved
Related Reports
Blocks :  
JDK-8241745 - Implement Text Blocks as a standard feature in javac
Blocks :  
JDK-8242456 - PreviewFeature.Feature enum removal of TEXT_BLOCKS
Description
From Jim Laskey:

Ran into a javac bootstrap issue not sure what is wrong. I switched from a 13 to a 14 bootstrap for my text blocks changes and now I'm getting.

warning: unknown enum constant Feature.TEXT_BLOCKS
warning: unknown enum constant Feature.TEXT_BLOCKS
warning: unknown enum constant Feature.TEXT_BLOCKS

for the 3 checkSourceLevel in JavaTokenizer.java.

but Source clearly has TEXT_BLOCKS(JDK15, Fragments.FeatureTextBlocks, DiagKind.PLURAL),

JavaTokenizer.java has import com.sun.tools.javac.code.Source.Feature;

This is after a nuked build folder configure

Switching back to 13 works fine
Comments
Note the problem is not the compiler enum. It is the PreviewFeature.Feature enum. We could use ints or Strings instead of the enum, but (unlike enums), any int or String would work. I.e. we could write: @PreviewFeature(feature="arbitrary feature") which to some degree contradicts the point of having the feature attribute at all (which is to ensure all uses are explicitly marked with a known preview feature). Note this does not apply to most preview features, but only to those that have APIs in "important" APIs, and even for them, the cost is that an enum constant (of an internal enum) needs to remain one more release. I wonder if the unavoidable discussion when solving this by using ints/Strings brings more than simply deleting the constant in the next release.
05-05-2020
It is not clear if there's something that could be done. This effectively only applies to preview features that have associated API in java.base. We may need to keep the obsolete enum constants in PreviewFeature.Feature for such features as long as the old bootstrap is supported.
22-04-2020
Not sure what advantage of using the compiler enum serves in the @preview. I think it would be better to have an independent enum that has a static int that check the compiler flag reflectively. If the compiler enum disappears then a warning message (not a warning error) is issued. Or even have the enum in quotes to be checked reflectively.
22-04-2020