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

[mpalat]

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

[for reference to previous release -> Java 23 support captured in issue #2212 ]

for updates on 24

Features for Java 24 release (may change):

Batch Compiler:

• [24] JEP 404: Generational Shenandoah (Experimental) #3237
• [24] JEP 450: Compact Object Headers (Experimental) #3236
• [24] JEP 472 Prepare to Restrict the Use of JNI #2971
• [24] JEP 475 : Late Barrier Expansion for G1 #3087
• [24] JEP 478: Key Derivation Function API (Preview) #3238
• [24] JEP 479: Remove the Windows 32-bit x86 Port #3295
• [24] JEP 483: Ahead-of-Time Class Loading & Linking #3296
• [24] JEP 484: Class-File API #3049
• [24] JEP 485: Stream Gatherers #3142
• [24] JEP 486: Permanently Disable the Security Manager #3291
• [24] JEP 487: Scoped Values (Fourth Preview) #3292
• [24] JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview) #2900
• [24] JEP 489: Vector API (Ninth Incubator) #3061
• [24] JEP 490: ZGC: Remove the Non-Generational Mode #3293
• [24] JEP 491: Synchronize Virtual Threads without Pinning #3294
• [24] JEP 492: Flexible Constructor Bodies (Third Preview) #2901
• [24] JEP 493: Linking Run-Time Images without JMODs #3139
• [24] JEP 494: Module Import Declarations (Second Preview) #2903
• [24] JEP 495: Implicitly Declared Classes and Instance Main Methods (Fourth Preview) #2902
• [24] JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism #3362
• [24] JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm #3363
• [24] JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe #3364
• [24] JEP 499: Structured Concurrency (Fourth Preview) #3365
• [24] JEP 501: Deprecate the 32-bit x86 Port for Removal #3366

JSR 399 Issue

• [24] JSR 399 #3010

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

• [24] IDE Support for JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)  #3558

Issues/PRs - Raised while further testing/investigating

• [24] Check if preview flag is set in classfiles where needed #3604
• Preview Flag not set with runtime only preview features #3614

Additional Tracking Issues

• [24] Create Java 24 constants and test framework changes #2905
• [24] General Release Activities #2904

JDT Core Friends' reference

• [24] Umbrella Bug for BETA_JAVA24 Activities in jdt.ui eclipse.jdt.ui#1675
• [24] Umbrella Bug for BETA_JAVA24 issues in JDT.Debug eclipse.jdt.debug#515

[stephan-herrmann]

Quoting @mpalat from #2985 (reply in thread):

Have created the following milestones :

BETA_JAVA24 M1
Second Tuesday of October
First Milestone where all non- feature related issues, eg - infrastructure, testing, constants etc are targeted to

BETA_JAVA24 M2
Second Tuesday of December
All non-language changes are identified, investigated and closed.
All language grammar changes are done (maybe almost done depending on the spec freeze)

BETA_JAVA24 M3
Second Tuesday of February
All Language features completed [with a few odd number of tests still pending, perhaps]

BETA_JAVA24 RC1
Fourth Tuesday of February
All Features completed

BETA_JAVA24 RC2
Second Tuesday of March
All Pre-release testing to be done here
Quiet period until release

BETA_JAVA24
March 18, 2025
JAVA 24

plus:

for example, P build creation should be done in M1 , Y build creation, java24 addition in jenkins etc - all in M1. - Will create the detailed releng tasks and will try to target it to the earlier milestone. Some of the releng tasks, like beta removal etc - needless to say, will have to be only at the main release BETA_JAVA24 in the current case.

So, we are past M1, so let's check:

• Constants for 24 seem to be in place ✔️
• Y-Build: https://ci.eclipse.org/releng/job/YPBuilds/job/Y-build-4.34/ ✔️
  • Tests below https://ci.eclipse.org/releng/job/YPBuilds/ have many failures ❌
  • Do we have an issue for those failures already?
• P-Build: I see nothing. Who is looking into this?

[stephan-herrmann]

• Tests below https://ci.eclipse.org/releng/job/YPBuilds/ have many failures ❌

• Do we have an issue for those failures already?

I created #3228 for this

[jarthana]

* P-Build: I see nothing. Who is looking into this?

Last time, we spoke about having these scripts in JDT. I am still wondering if we should do that or keep it the current way.

[stephan-herrmann]

* P-Build: I see nothing. Who is looking into this?

Last time, we spoke about having these scripts in JDT. I am still wondering if we should do that or keep it the current way.

Can you provide a pointer to the scripts used so far, so we can get a clearer picture?

• there could be technical problems: we don't have a git repo that aggregates all of JDT
• there could be dependencies on other parts of platform releng, which we are unfamiliar with, cannot control.

If all fails, we could even try to script this on our own: pulling artifacts from a Y-Build and only perform these additional steps:

• compile the tiny feature jar file
• generate p2 metadata
• get additional files signed

All might perhaps be solved with just a few shell commands?

[jarthana]

Can you provide a pointer to the scripts used so far, so we can get a clearer picture?

These are the ones: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/cje-production/P-build
@MohananRahul can correct me if there's more.

* there could be technical problems: we don't have a git repo that aggregates all of JDT

My first thought was we could put them in https://github.com/eclipse-jdt/eclipse.jdt. I don't know if the repo really has to aggregate all the bundles to be built. Honestly, I am not sure one way or other.

[stephan-herrmann]

Can you provide a pointer to the scripts used so far, so we can get a clearer picture?

These are the ones: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/cje-production/P-build

Thanks this helps!

At the core I see one mvn invocation in mb220_buildSdkPatch.sh which uses this pom.

So far nothing fancy (except for the large number of build properties).

• there could be technical problems: we don't have a git repo that aggregates all of JDT

My first thought was we could put them in https://github.com/eclipse-jdt/eclipse.jdt. I don't know if the repo really has to aggregate all the bundles to be built. Honestly, I am not sure one way or other.

java23patch/pom.xml expects all these mvn modules to be accessible in the filesystem:

  <modules>
    <module>../../eclipse-platform-parent</module>
    <module>../../eclipse.platform.releng.prereqs.sdk</module>
    <module>org.eclipse.jdt.dummy</module>
    <module>org.eclipse.jdt-feature-dummy</module>
    <module>../../eclipse.jdt.core/org.eclipse.jdt.core</module>
    <module>../../eclipse.jdt.core/org.eclipse.jdt.core.compiler.batch</module>
    <module>../../eclipse.jdt.ui/org.eclipse.jdt.ui</module>
    <module>../../eclipse.jdt.ui/org.eclipse.jdt.core.manipulation</module>
    <module>../../eclipse.jdt.ui/org.eclipse.jdt.astview</module>
    <module>../../eclipse.jdt.debug/org.eclipse.jdt.launching</module>
    <module>org.eclipse.jdt.java23patch</module>
    <module>eclipse.releng.repository.java23patch</module>
  </modules>

The releng build uses git submodules to pull all those into the aggregator git. I don't think we'd want to start anything like that.

Perhaps the approach of least effort is: to essentially use those scripts indeed, but rather then relying on git submodules, use a shell script to manually clone (or export) individual jdt repos into folders of the jenkins workspace.

I'm just not yet convinced that a full blown build is even necessary, given that we could pull artifacts from a Y-Build, and only add the feature plus metadata.

I might give both strategies a try - time permitting :)

• to be continued in [24] Try building the java24 patch on JDT infra #3244

[akurtakov]

@stephan-herrmann Full build is not needed according to me too and @merks even proved the P-build could be done far simpler in eclipse-platform/eclipse.platform.releng.aggregator#2341 (comment)