[23] Top Level Bug for Java 23 Support for JDT.Core

[mpalat]

Umbrella bug for Java 23 activities - Ref :
https://openjdk.org/projects/jdk/23/
https://openjdk.org/projects/jdk/23/spec/

for updates on 23

Features for Java 23 release:

Batch Compiler:

• [23] JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) #2298
• [23] JEP 466: Class-File API (Second Preview) #2331
• [23] JEP 467: Markdown Documentation Comments #2429
• [23] JEP 469: Vector API (Eighth Incubator) #2332
• [23] JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal #2473
• [23] JEP 473: Stream Gatherers (Second Preview) #2333
• [23] JEP 474: ZGC: Generational Mode by Default #2430
• [23] JEP 476: Module Import Declarations (Preview) #2383
• [23] JEP 477: Implicitly Declared Classes and Instance Main Methods (Third Preview) #2474
• [23] JEP 480: Structured Concurrency (Third Preview) #2475
• [23] JEP 481: Scoped Values (Third Preview) #2585
• [23] JEP 482: Flexible Constructor Bodies (Second Preview) #2472

JSR 398 Issue:

• [23] JSR 398 #2792

The following issues may warrant issues of their own - Will be created if required

• JSR 199: Java Compiler API -
• JSR 269: Pluggable Annotation-Processing API

IDE Support for the relevant features listed above under Batch Compiler

• [23] Removal of DOM part of StringTemplate work #2586
• [23][IDE Support] JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) #2298 #2844
• [23][IDE Support] JEP 467: Markdown Documentation Comments #2429 #2845
• [23][IDE Support] JEP 476: Module Import Declarations (Preview) #2383 #2846
• [23][IDE Support] JEP 477: Implicitly Declared Classes and Instance Main Methods (Third Preview) #2474 #2847
• 23][IDE Support] JEP 482: Flexible Constructor Bodies (Second Preview) #2472 #2848

Additional Tracking for Issues

• [23] Remove String Template preview feature #2353

Release Activities captured in:

• [23] General Release Activities #2213
• [23] Create Java 23 constants and test framework changes #2268

[stephan-herrmann]

Proposed to target 23 (as per JSR 398 (Java SE 23) JEP Dashboard):

• JEP 477: Implicitly Declared Classes and Instance Main Methods (Third Preview)
  • with child JLS Changes for Implicitly Declared Classes and Instance Main Methods (Third Preview) (no details yet)

[stephan-herrmann]

Proposed to target 23 (see https://mail.openjdk.org/pipermail/java-se-spec-experts/2024-May/000376.html):

• JEP 482: Flexible Constructor Bodies (Second Preview)
  • with child JLS changes for Flexible Constructor Bodies (Second Preview) (no details yet)
  • specification changes found here: https://cr.openjdk.org/~gbierman/jep482/latest

[stephan-herrmann]

Should ecj follow the behavior change proposed in Proposal to change default annotation processing policy in JDK 23? I.e., change the default to -proc:none?

• see also Add -proc:full to batch compiler #2347

[jarthana]

Should ecj follow the behavior change proposed in Proposal to change default annotation processing policy in JDK 23? I.e., change the default to -proc:none?

* see also [Add -proc:full to batch compiler #2347](https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2347)

Personally, I am not very keen. If we come across a compelling reason in future, we can do this. For the time being, we can just add support for -proc:full

[stephan-herrmann]

Personally, I am not very keen. If we come across a compelling reason in future, we can do this. For the time being, we can just add support for -proc:full

Fair enough 😄

Just for completeness, here's the reasoning from the original proposal:

This policy of implicitly running annotation processors by default may have been
reasonable when the feature was introduced in JDK 6 circa 2006, but from
a current perspective, in the interest of making build output more
robust against annotation processors unintentionally being placed on the
class path, the policy should not be the default anymore.

But since this default is not part of any specification we are free to choose (keep) our own default.

Perhaps right now, users might be badly surprised when we change the default. In the future, once users have adjusted to the change in javac, they'll probably start complaining about ecj. Let's see.

[stephan-herrmann]

Spec changes have reached state Public Review Draft 1, see https://mail.openjdk.org/pipermail/java-se-spec-experts/2024-July/000381.html

• JLS draft https://cr.openjdk.org/~iris/se/23/spec/pr/java-se-23-pr-spec-01/java-se-23-annex-3.html

[stephan-herrmann]

Specifications have been posted for Public Review, see announcement in https://mail.openjdk.org/pipermail/java-se-spec-experts/2024-July/000384.html

None of the specifications affecting the compiler have changes after 2024-06-04

[stephan-herrmann]

@mpalat I think it would be easier to track progress if we close all issues without impact on JDT, no?

On my list I see a need for JDT-work only in JEP 455 and JEP 467. Am I missing any?

[mpalat]

@mpalat I think it would be easier to track progress if we close all issues without impact on JDT, no?

@stephan-herrmann Agree.. the idea is to someone to investigate each of the JEPs listed so that we don't miss out atleast knowing that there is change/no change. Hence I keep listing all the JEPs release after release. Yes, it makes sense if we investigate some of the issues which are not relevant. I will also take up some.

On my list I see a need for JDT-work only in JEP 455 and JEP 467. Am I missing any?

Mostly yes. Additionally, JSR 398 - no issue created yet - only a placeholder - will also need to be investigated.

[stephan-herrmann]

Specifications and RI are final, see https://mail.openjdk.org/pipermail/java-se-spec-experts/2024-August/000391.html

[stephan-herrmann]

Here's some status from running relevant tests with run.javac enabled:

• SuperAfterStatementsTest
  • 1 error: javac bug https://bugs.openjdk.org/browse/JDK-8336255
• PrimitiveInPatternsTestSH
  • 1 error: assumed javac bug https://mail.openjdk.org/pipermail/compiler-dev/2024-September/027630.html
• PrimitiveInPatternsTest: success ✔️
• ModuleImportTests: success ✔️
• MarkdownCommentsTest:
  • most diffs can be avoided by better preparing tests for this comparison
  • 1 error: javac does not report unresolvable @see reference (test009)
• ImplicitlyDeclaredClassesTest: success ✔️

👍 This looks pretty good! 👍

Some random existing tests neighboring the above:

• ModuleCompilationTests
  • 8 errors, 4 of which can be resolved by test changes (javac error message changed, or javac bug got fixed)
• PatternMatching16Test
  • 83 failures, obviously not suitable for running back-to-back with javac23
  • 67 errors vs javac16
• RecordPatternTest 4 errors - 1 avoidable by suitable configuration, remaining:
  • javac-generated code throws ArithmeticException instead of expected MatchException (see comments in tests):
    • testGH1977_instance_field()
    • testGH1977_static_field()
    • testIssue1985_2()
• SwitchPatternTest: 5 errors (some related to wrongly configured --enable-preview, others not yet analysed)
• SwitchPatternTest21: 2 errors
  • testInternalDomination_this() (ecj no error, javac 2 errors)
  • testNaming() // javac jdk21 allows components to be named, but they can't be referenced

to be continued in #2959

[stephan-herrmann]

Here's some status from running relevant tests with run.javac enabled:

• PrimitiveInPatternsTestSH
  * 1 error: assumed javac bug https://mail.openjdk.org/pipermail/compiler-dev/2024-September/027630.html

Confirmation of javac bug is here: https://mail.openjdk.org/pipermail/compiler-dev/2024-September/027729.html

We'll check equivalence of compilers in the next preview round (possibly with amendments in JLS).

[stephan-herrmann]

Let's declare success here! 🍾

[mpalat]

Let's declare success here! 🍾

YES 🙏