-
Notifications
You must be signed in to change notification settings - Fork 132
Adding support for new Java version and Features in JDT
Every time there's a new Java Language version, JDT needs to be updated in several places in order for the compiler and other JDT components to support.
First and foremost, any file that is modified for language features that is not final (GA) yet, must contain the following disclaimber as part of the copyright at the top:
This is an implementation of an early-draft specification developed under the Java <br> Community Process (JCP) and is made available for testing and evaluation purposes <br> only. The code is not compatible with any specification of the JCP.
First and foremost, the compiler needs the following changes to recognize the new Java version and to be able to produce .class files for the new version.
Add the new major Java version
+ int MAJOR_VERSION_19 = 63;
Update the latest major version to point to the new version.
- int MAJOR_LATEST_VERSION = MAJOR_VERSION_18;
+ int MAJOR_LATEST_VERSION = MAJOR_VERSION_19;
Add a new JDK level, which is the combination of the major version and minor version (which is usually zero)
+ long JDK19 = ((long)ClassFileConstants.MAJOR_VERSION_19 << 16) + ClassFileConstants.MINOR_VERSION_0;
Add the string constant for the new version. + public static final String VERSION_19 = "19"; //$NON-NLS-1$
Important: And update the getLatestVersion() to point to the newly added version.
- return VERSION_18;
+ return VERSION_19;
3. Main.java
Update the optionStringToVersion() to provide the mapping between the command line version (of the format 19/19.0) and the internal version string from CompilerOptions.java
+ case "19": //$NON-NLS-1$
+ case "19.0": //$NON-NLS-1$
+ return CompilerOptions.VERSION_19;
Changes to the command line program warrants the documentation to be updated as below.
-configure.source = source level should be in ''1.1''...''1.8'',''9''...''18'' (or ''5.0''..''18.0''): {0}
+configure.source = source level should be in ''1.1''...''1.8'',''9''...''19'' (or ''5.0''..''19.0''): {0}
-configure.targetJDK = target level should be in ''1.1''...''1.8'',''9''...''18'' (or ''5.0''..''18.0'') or cldc1.1: {0}
+configure.targetJDK = target level should be in ''1.1''...''1.8'',''9''...''19'' (or ''5.0''..''19.0'') or cldc1.1: {0}
-\ -source <version> set source level: 1.3 to 1.9, 10 to 18
+\ -19 -19.0 use 19 compliance (-source 19 -target 19)
+\ -source <version> set source level: 1.3 to 1.9, 10 to 19
-\ -target <version> set classfile target: 1.3 to 1.9, 10 to 18
+\ -target <version> set classfile target: 1.3 to 1.9, 10 to 19
Update if/else switch block and in case also JDT minimal supported version changes, MINIMAL_REQUIRED_RUNTIME_VERSION and VERSION_FOR_MINIMAL_RUNTIME.
The new Java version constant as a string need to be added with an appropriate @since tag:
+ /**
+ * Configurable option value: {@value}.
+ * @since 3.31 BETA_JAVA19
+ * @category OptionValue
+ */
+ public static final String VERSION_19 = "19"; //$NON-NLS-1$
Please note the BETA_JAVAxx as part of the @since version. This will be removed just before promoting the changes from the beta branch to the main (master)
The test framework uses a constant bit to tag tests with one or more versions (levels). The new version needs to be added as below: + public static final int F_19 = 0x10000;
Provide the mapping between this new flag the constant we earlier added in ClassFileConstants.java
The new flag (F_19) then will be used by new tests that will be added for this version or any tests that may have to be migrated to the new version. For example, tests that pertain to a preview feature will need to be updated to reflect the fact that the test should only be run from this version onward.
- return buildMinimalComplianceTestSuite(testClass(), F_18);
+ return buildMinimalComplianceTestSuite(testClass(), F_19);
Update test matrix / add new JLS here https://github.com/eclipse-jdt/eclipse.jdt.core/blob/master/org.eclipse.jdt.core.tests.compiler/test.xml#L60
As and when we start developing new Language features, there are certain things to be kept in mind or taken care of. Firstly, the Java Language feature(s) that undergo state change, for e.g., newly added preview feature or preview feature being promoted to standard feature etc. need to be marked as such in JavaFeature.java:
- PATTERN_MATCHING_IN_SWITCH(ClassFileConstants.JDK18,
+ PATTERN_MATCHING_IN_SWITCH(ClassFileConstants.JDK19,
Any new grammar rules being introduced for new language features in java.g, should be tagged with /:$compliance 19:/
Parser.java has to be updated manually after running GenerateParserScript.java, see more details in https://github.com/eclipse-jdt/eclipse.jdt.core/wiki/ECJ-Parse#generating-the-parser-see-also-bug-562044.
The Parser.buildFileForCompliance() must be updated to have new Java version case.
If the compiler changes warrant any changes to the DOM API, then we must introduce a new AST Level in the DOM API - AST.java. However, in order to keep things simple and to avoid maintaining a mapping between the Language version and DOM API version, we add a new AST Level always.
The new AST level constant should be added to AST.java and as should the similarly named internal constant:
+ public static final int JLS19 = 19;
+ public static final int JLS19_INTERNAL = JLS19;
And finally the latest AST level being updated:
- public static final int JLS_Latest = JLS18;
+ public static final int JLS_Latest = JLS_INTERNAL_Latest;
Update the default formatter to the latest AST Level in DefaultCodeFormatter.createParser(int).
There's a high possibility that several tests from org.eclipse.jdt.core.tests.dom.RunAllTests will start failing with unsupported operation errors. This probably means that some of the supportedOnlyInxx() methods need a AST version update.
Important: Ensure that all test suites are run with the JRE version in question before releasing your changes.