search

xtext / xtext-reference-projects

A collection of Xtext sample projects for build integration tests
Eclipse Public License 1.0
7 stars 6 forks source link

J21 Tests #421

Closed cdietrich closed 4 months ago

LorenzoBettini commented 4 months ago

@cdietrich there's a problem making the build fail: https://github.com/eclipse/xtext/issues/3045

cdietrich commented 4 months ago

@LorenzoBettini do you have an idea what is the problem with https://github.com/xtext/xtext-reference-projects/actions/runs/9124362079/job/25098778202

[INFO] --- xtend-maven-plugin:2.35.0-SNAPSHOT:testCompile (default) @ org.xtext.example.mydsl --- Warning: Compilation of stubs had errors. Error:

this will need the new bom?

cdietrich commented 4 months ago

ahh i need to pass java-21

cdietrich commented 4 months ago

have no clue why gradle is working at all. it pulls the old jdt

cdietrich commented 4 months ago

it does not if e.g. a record is acutally used

LorenzoBettini commented 4 months ago

@cdietrich Yes, for Maven you need to pass that property. For gradle, I think you should force the new version of jdt in the dependencies; I don't know gradle at all, so I don't know how that can be done.

cdietrich commented 4 months ago

but this may also be a java source language problem

cdietrich commented 4 months ago

i am not sure how to do that. we need to check out workaround in 5 year old projects

LorenzoBettini commented 4 months ago

but this may also be a java source language problem

What do you mean? If I understand correctly, the JDT Java parser is old and cannot handle the record specification.

cdietrich commented 4 months ago

the cannot handle type seems to come from JavaDerivedStateComputer public JvmDeclaredType createType(TypeDeclaration type, String packageName) {

i still have no clue which jdt is picked.

LorenzoBettini commented 4 months ago

the cannot handle type seems to come from JavaDerivedStateComputer public JvmDeclaredType createType(TypeDeclaration type, String packageName) {

i still have no clue which jdt is picked.

In Gradle? Without proper intervention, it takes the old one

cdietrich commented 4 months ago

@LorenzoBettini i see this in the java soruce language test too if i

    public void installStubs(Resource resource) {
        if (isInfoFile(resource)) {
            return;
        }
        CompilationUnit compilationUnit = getCompilationUnit(resource);
        DefaultProblemFactory problemFactory = new DefaultProblemFactory();
        ProblemReporter problemReporter = new ProblemReporter(DefaultErrorHandlingPolicies.exitOnFirstError(),
                getCompilerOptions(resource), problemFactory);
        problemReporter.options.sourceLevel =ClassFileConstants.JDK21;
        problemReporter.options.targetJDK =ClassFileConstants.JDK21;
        problemReporter.options.originalSourceLevel = ClassFileConstants.JDK21;
        problemReporter.options.complianceLevel = ClassFileConstants.JDK21;
        problemReporter.options.originalComplianceLevel = ClassFileConstants.JDK21;

java.lang.IllegalArgumentException: Cannot handle type public record MyRecord(String name, int age) { / Implicit / private final String name; / Implicit / private final int age; public MyRecord(String name, int age) { .name = name; .age = age; } } at org.eclipse.xtext.java.resource.JavaDerivedStateComputer.createType(JavaDerivedStateComputer.java:140) at org.eclipse.xtext.java.resource.JavaDerivedStateComputer.installStubs(JavaDerivedStateComputer.java:116) at org.eclipse.xtext.java.resource.JavaResource.lambda$0(JavaResource.java:180) at org.eclipse.xtext.java.resource.JavaResource.initializing(JavaResource.java:196) at org.eclipse.xtext.java.resource.JavaResource.installStubs(JavaResource.java:179) at org.eclipse.xtext.java.resource.JavaResourceDescriptionManager.getResourceDescription(JavaResourceDescriptionManager.java:48) at org.eclipse.xtext.java.tests.JavaSourceLanguageTest.resourceSet(JavaSourceLanguageTest.java:245) at org.eclipse.xtext.java.tests.JavaSourceLanguageTest.testJava21Record(JavaSourceLanguageTest.java:202) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.eclipse.xtext.testing.XtextRunner$1.evaluate(XtextRunner.java:50) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:93) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:529) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:757) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:452) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)

cdietrich commented 4 months ago

otherwise the source lang will just swallow errors

LorenzoBettini commented 4 months ago

Does it work with Gradle as well now?

cdietrich commented 4 months ago

I did not test the cradle usecsse again with using record Need to figure out what the best workaround is

cdietrich commented 4 months ago

seems to work with

    dependencies {
        api platform("org.eclipse.xtext:xtext-dev-bom:${xtextVersion}") {
            dependencies {
                api 'org.eclipse.jdt:org.eclipse.jdt.core:3.37.0'
            }

        }
    }

but have no clue if this is the state of the art workaround or not

LorenzoBettini commented 4 months ago

I'd expect that to be required only when using the plugins. But I don't know what those lines do in Gradle. Are those the equivalent of dependency management in Maven? Where are those lines to be inserted in the examples?

cdietrich commented 4 months ago

The platform yes. But don’t know if the way I override is correct

LorenzoBettini commented 4 months ago

The platform yes. But don’t know if the way I override is correct

I meant: have you applied those changes to the reference project using java 21? In any case, to document current java 21 support, I asked where those lines are to be inserted in which Gradle file.

cdietrich commented 4 months ago

yes but as it was also "failing" with the same error message before (see original report in the xtext repo about records) i dont know if the new jdt is actually used or just the 2.33 one which might have some preview stuff

so i have NO CLUE AT ALL if this is the correct way for java 21 in gradle

i just see that it 3.37 is downloaded but dont kniw when its used and when not

LorenzoBettini commented 4 months ago

I'm afraid I'm not following anymore..

You said that with the lines above it's working in gradle as well, or it doesn't?

I thought also that the Xtext issue you fixed also fixed things in gradle.

With the older version of jdt things were not working in maven: java 21 support wasn't there. If jdt correctly parses records it's the new version. I ensured our plugin tests were failing without the new version of jdt.

cdietrich commented 4 months ago

Yes we are two confused people. Thus I cannot tell if it really works in 21. is there a real Java 21 only feature to test with

LorenzoBettini commented 4 months ago

Yes we are two confused people. Thus I cannot tell if it really works in 21. is there a real Java 21 only feature to test with

Java 21 records (if your last sentence was a question). I thought that's what you tested as well. That's what I used in tests in Xtext. I'm not confused in that respect ;)

cdietrich commented 4 months ago

https://github.com/eclipse/xtext/issues/2823#issuecomment-1768978255

The error for records was the same back then. Thus the old 33er JDT seems to recognize them somehow too

cdietrich commented 4 months ago

So records working am am not sure if this proves Java 21 working then

LorenzoBettini commented 4 months ago

So records working am am not sure if this proves Java 21 working then

As I said, in Maven yes: without proper jdt version the tests were failing.

In gradle: add a record in a java file, refer to that record from an xtend file. Run the build. Without any specific version if jdt it should fail. With the added jdt version in the gradle file (your lines above) it should succeed.