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

[mpalat]

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

[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 #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.