Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Java 21 #3037

Merged
merged 22 commits into from
May 17, 2024
Merged

Support for Java 21 #3037

merged 22 commits into from
May 17, 2024

Conversation

LorenzoBettini
Copy link
Contributor

Closes #2823

Addresses most of #2686

@LorenzoBettini
Copy link
Contributor Author

A few comments:

  • Basically the support of Java 21 from JDT is automatic in Eclipse, taking the latest version of JDT; however, this https://github.com/eclipse/xtext/pull/3037/files#diff-829bb66211b81ee8e7e87794e1319b00452a80ff6916b8feeead5d7e72e6e27eR157 is also required when we use the JDT parser to parse Java files, so that we can correctly detect Java records; that method was introduced in JDT several versions ago, so that's harmless: for sure, it's present in our minimal required version of JDT.
  • Concerning Maven the BOM has a profile using the new version of JDT core. I found out that a profile in a BOM CANNOT be activated explicitly with -P; in fact, a profile must be present in the aggregator or parent to be explicitly activated. However, good news, a profile in a BOM can still be implicitly activated through a System property! E.g., either at the command line or through the file ".mvn/maven.config" as I do in the IT projects of our Maven plugins, e.g., https://github.com/eclipse/xtext/pull/3037/files#diff-b9a50ce2dde853da7188fbdbf5eac95cf0259c51d108b42360bd1a7dbfda555bR1 For the profile I chose the name java-21 and the same for the property; if you prefer some other names, please let me know
  • I also added a CLI Wizard test for Java 21. I don't know whether it's worthwhile, wdyt?
  • As for the rest, it's mostly related to added tests, activated when the runtime is Java 21. I took the chance to refactor a bit standalone incremental builder tests.

One further possibility for Maven projects when selecting Java 21 in the wizard would be to generate the".mvn/maven.config" file. However, I seem to understand that this solution is temporary anyway: when we switch to Java 17 as the minimal requirement, the BOM profile is not needed anymore.

@LorenzoBettini
Copy link
Contributor Author

Another small note: the GitHub Actions build-maven-artifacts uses Java 21; while for the full builds there's only an Ubuntu job for Java 21.

@cdietrich
Copy link
Member

what are the org.eclipse.draw2d changes for?

@LorenzoBettini
Copy link
Contributor Author

what are the org.eclipse.draw2d changes for?

It's documented in the tests: it's to access a java record from an existing library. JDK itself doesn't provide any in my findings.

@cdietrich
Copy link
Member

there are some rare ones e.g.

UnixDomainPrincipal one in MXBean

@LorenzoBettini
Copy link
Contributor Author

UnixDomainPrincipal

But is that available on all platforms?

I felt safer using something like the one from draw2d, which is in our target platform anyway.

It's a temporary solution until we use Java 21 in Eclipse.

However, I have to remove the lower bound to let it also build with the older platform: in Jenkins, it cannot resolve the latest draw2d

@LorenzoBettini
Copy link
Contributor Author

@cdietrich I removed the lower bound for draw2d to let the build work also on older target platform.

Of course, if you don't like this temporary solution I can also try with UnixDomainPrincipal

@cdietrich
Copy link
Member

maybe now that we are in a monorepo. maybe we can reconsider a single testdata bundle for jvm stuff
@szarnekow wdyt

@LorenzoBettini
Copy link
Contributor Author

maybe now that we are in a monorepo. maybe we can reconsider a single testdata bundle for jvm stuff @szarnekow wdyt

I think we already have something like that: org.eclipse.xtext.xbase.testdata.
But I couldn't add a Java record there: it wouldn't compile unless we always use Java 21.

That's why I was considering mine as a temporary solution.

@cdietrich
Copy link
Member

i see. maybe we use draw2d for now and something else later.

@LorenzoBettini
Copy link
Contributor Author

i see. maybe we use draw2d for now and something else later.

Yes, that's what I was proposing as well.

@LorenzoBettini
Copy link
Contributor Author

Argh! There's a compilation failure in Jenkins:

08:40:36  [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:4.0.7:compile (default-compile) on project org.eclipse.xtext.xbase.ui.tests: Compilation failure: Compilation failure: 
08:40:36  [ERROR] /home/jenkins/agent/workspace/xtext_PR-3037/org.eclipse.xtext.xbase.ui.tests/src/org/eclipse/xtext/xbase/ui/tests/JavaVersionExtendedTest.java:[32] 
08:40:36  [ERROR] 	assertEquals(ClassFileConstants.JDK21, JavaVersion.JAVA21.toJdtClassFileConstant());
08:40:36  [ERROR] 	                                ^^^^^
08:40:36  [ERROR] JDK21 cannot be resolved or is not a field

We're using an old version of JDT in that old target platform...

@cdietrich
Copy link
Member

this is why we in the past partially used reflection

@LorenzoBettini
Copy link
Contributor Author

this is why we in the past partially used reflection

Let's see whether this 6ec2a2f makes it happy.
Again, temporary solution, which I'll start to keep track in #2686

@@ -22,6 +22,5 @@
<booleanAttribute key="org.eclipse.jdt.launching.ATTR_SHOW_CODEDETAILS_IN_EXCEPTION_MESSAGES" value="true"/>
<booleanAttribute key="org.eclipse.jdt.launching.ATTR_USE_CLASSPATH_ONLY_JAR" value="false"/>
<booleanAttribute key="org.eclipse.jdt.launching.ATTR_USE_START_ON_FIRST_THREAD" value="true"/>
<stringAttribute key="org.eclipse.jdt.launching.JRE_CONTAINER" value="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.7/"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting to see what we still had in some of the config files.

@LorenzoBettini LorenzoBettini force-pushed the lb_java_21-2 branch 2 times, most recently from 9a8e43d to 8e4c424 Compare May 16, 2024 12:15
@LorenzoBettini LorenzoBettini added this to the Release_2.35 milestone May 17, 2024
@LorenzoBettini LorenzoBettini merged commit 83e6497 into eclipse:main May 17, 2024
7 checks passed
@LorenzoBettini LorenzoBettini deleted the lb_java_21-2 branch May 17, 2024 05:13
@cdietrich
Copy link
Member

@LorenzoBettini
Copy link
Contributor Author

@cdietrich It is triggered by https://ci.eclipse.org/xtext/job/xtext/job/main/ upon success build.

It has built: https://ci.eclipse.org/xtext/job/xtext-monorepo-full-deploy-nightly/273/

Of course, slowness of JIRO doesn't help ;)

@cdietrich
Copy link
Member

@LorenzoBettini i started it manually
this is why i am asking

@cdietrich
Copy link
Member

@LorenzoBettini runniing

JavaSourceLanguageTest with the record i dont see
org.eclipse.xtext.java.resource.JavaDerivedStateComputer.createType(TypeDeclaration, String)
called

@LorenzoBettini
Copy link
Contributor Author

@LorenzoBettini i started it manually this is why i am asking

That's strange... indeed I see in the main job

14:21:00  Stage "Trigger Snapshot Deployment" skipped due to when conditional

@LorenzoBettini
Copy link
Contributor Author

@LorenzoBettini i started it manually this is why i am asking

That's strange... indeed I see in the main job

14:21:00  Stage "Trigger Snapshot Deployment" skipped due to when conditional

It worked yesterday though: https://ci.eclipse.org/xtext/job/xtext/job/main/1138/console

@LorenzoBettini
Copy link
Contributor Author

@LorenzoBettini runniing

JavaSourceLanguageTest with the record i dont see org.eclipse.xtext.java.resource.JavaDerivedStateComputer.createType(TypeDeclaration, String) called

But the test succeeds and the corresponding class is found.
What do you mean?

@cdietrich
Copy link
Member

@LorenzoBettini this test wll do nothing.
as org.eclipse.xtext.java.resource.JavaDerivedStateComputer.installStubs(Resource)
will swallow all problems
and not produce a type

@cdietrich
Copy link
Member

grafik

@cdietrich
Copy link
Member

=> maybe a installFull vs installStub thing

@cdietrich
Copy link
Member

gralde trace

       at org.eclipse.xtext.java.resource.JavaDerivedStateComputer.createType(JavaDerivedStateComputer.java:130)
        at org.eclipse.xtext.java.resource.JavaDerivedStateComputer.installStubs(JavaDerivedStateComputer.java:107)
        at org.eclipse.xtext.java.resource.JavaResource.lambda$0(JavaResource.java:179)
        at org.eclipse.xtext.java.resource.JavaResource.initializing(JavaResource.java:195)
        at org.eclipse.xtext.java.resource.JavaResource.installStubs(JavaResource.java:178)
        at org.eclipse.xtext.java.resource.JavaResourceDescriptionManager.getResourceDescription(JavaResourceDescriptionManager.java:48)

@cdietrich
Copy link
Member

grafik no j21 here

@cdietrich
Copy link
Member

cdietrich commented May 17, 2024

JavaConfig javaConfig = new JavaConfig();
javaConfig.setJavaSourceLevel(JavaVersion.JAVA21);
javaConfig.setJavaTargetLevel(JavaVersion.JAVA21);
javaConfig.attachToEmfObject(rs);

called too late and should be moved into this.resourceSet

@cdietrich
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Does Xtend work with java records?
3 participants