[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

• TODO

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)

[stephan-herrmann]

@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)

Thanks for the reminder, but I think this is not much different from cje-production/P-build/mb220_buildSdkPatch.sh and assumes to be run in the aggregator context with git submodules, no? (See that several jdt plugins from different git repos are built as part of one maven build). Our purpose here, however, is to become independent of that aggregator context, as to unburden platform releng :)

[MohananRahul]

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.

Yes @jarthana and also https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/JenkinsJobs/YBuilds/P_build.groovy ,Jenkins Job

[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 @MohananRahul can correct me if there's more.

Yes @jarthana and also https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/JenkinsJobs/YBuilds/P_build.groovy ,Jenkins Job

Thanks, @MohananRahul , so there is some more complexity :)

With all that input, let's please continue in #3244, thanks.

[stephan-herrmann]

Monitoring of test results in ep434Y-unit-cen64-gtk3-java24 looks promising

• jdt.core is clean!
• jdt.ui has 1 single failure
• jdt.debug shows 9 failures
• pde has 5 failures

Plus one failure in releng (regarding comparator logs, which I believe we can ignore for the time being).

[mpalat]

I updated the list yesterday night and at this point - this list may not have too many changes now, I believe.

[stephan-herrmann]

As we are approaching what @mpalat declared as M2 (2nd Tuesday of December), we seem to haven fallen behind, mostly during the course of switching to 4.35, I believe:

• latest Y-Build failed with equinox-sdk not finding the expected version of ecj.
• latest tests in ep435Y-unit-cen64-gtk3-java24/ show tons of failures, with a smoking gun from SWT:
  /home/vnc/.swt/lib/linux/x86_64/libswt-pi3-gtk-4968r2.so: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /home/vnc/.swt/lib/linux/x86_64/libswt-pi3-gtk-4968r2.so)
• eclipse.jdt.core-run.javac-24 shows new failures

I'll look into the last item, but I'd like to know if anyone (@mpalat) is in contact with releng regarding Y-build & tests? The SWT issue looks like jenkins needs a library update?

[iloveeclipse]

• latest tests in ep435Y-unit-cen64-gtk3-java24/ show tons of failures, with a smoking gun from SWT:
  /home/vnc/.swt/lib/linux/x86_64/libswt-pi3-gtk-4968r2.so: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /home/vnc/.swt/lib/linux/x86_64/libswt-pi3-gtk-4968r2.so)

See eclipse-platform/eclipse.platform.swt#1631
SWT natives are built on a Linux with GLIBC 2.34 in path so it now requires that library version on any other Linux distro, which means you need a machine with an updated OS to run tests.
@akurtakov or @HannesWell or @laeubi may recommend which machine could be used.

[HannesWell]

See eclipse-platform/eclipse.platform.swt#1631\nSWT natives are built on a Linux with GLIBC 2.34 in path so it now requires that library version on any other Linux distro, which means you need a machine with an updated OS to run tests.

Yes. I'm currently looking into unifying the Y-build tests with the I-build tests and also noticed that the Y-builds tests for Linux are still running on the old CentOS Images. Updating the jobs to run on Ubuntu should fix that problem.
I'll try to push a change this evening to adjust that.

[HannesWell]

I have just created eclipse-platform/eclipse.platform.releng.aggregator#2627 with the mentioned change.

[stephan-herrmann]

I have just created eclipse-platform/eclipse.platform.releng.aggregator#2627 with the mentioned change.

Test Result (42 failures / -7400)

cool, thanks, @HannesWell !