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
Does Xtend work with java records? #2823
Comments
hi, can you please provide more information what you are actually doing? |
I just dropped the gradle plugin into an existing java project, and am trying to get a clean build. On a side note, I don't really like records: Should I just convert the records to Xtend? |
there is no record in xtend. there is also no in java source lang. |
|
question would be if record can easily be mapped to a class |
Who know which one it will choose? |
You don’t have an explicit xbase/xtend.lib dependency in your project ? |
I wonder if you face the same problem in a maven project |
oh, there we go:
what could possibly be the difference? |
Maven links against class files and not java files |
We are also having the same issue with records. The records are consumed by Xtext when building the index for Java classes. I see two possible solutions:
Point two should not be a big issue as records are really just syntactic sugar. i.e. they are just normal Java classes with some special properties (fields are final, accessor methods, constructor with all properties, ...). So, IMHO, this would be a straightforward and desirable fix. |
If I understand correctly, the Ecore model of Xtext Java bundle should be updated with records first, shouldn't it? |
I don't think this is really necessary. Records are just Java classes. |
we at least need to transform them to classes. |
At least, this xtext/org.eclipse.xtext.java/src/org/eclipse/xtext/java/resource/JavaDerivedStateComputer.java Line 115 in bc28645
|
yes but this also affect the code that runs in eclipse |
that is exactly where I am looking at. The "record" has to be handled there. |
ping @szarnekow |
I was trying to fix this issue, but I have stumbled over additional problems. I have been experimenting with the domain language example:
The record cannot be resolved. What I found out after a longer debugging session: JdtBasedTypeFactory constructs a ASTParser with JLS 3. This obviously does not support records, as records have not been part of JLS 3 (Java 5!?). Changing that to something more up to date at least fixes this issue. Why is this fixed to such a legacy version of Java? Aside of that (shall I open a defect for it?), I do not get to the JavaDerivedStateComputer and verify that just adding "records" to the type switch fixes the issue. I would need some hints to further debug and test this. |
i cannot tell you anything about why. |
when I bump the version to e.g. AST.getJLSLatest() the Xtext properly resolves the reference to the record from the domain model DSL |
with or without changes to the Type factories? |
all I did was bump the JLS version in JdtBasedTypeFactory#157; no other changes so far |
I would have expected to find a similar switch there too |
maybe its working cause |
I think back then there was no AST.getLastest available. We use much more recent JDT now, so that can be fixed |
Some updates: by setting /**
* A cached AST parser that's reused by top-level type {@link #createType(IType) creation}.
*/
@SuppressWarnings("all")
private final ASTParser parser = ASTParser.newParser(AST.getJLSLatest()); in |
I am testing Xtend with a Java 17 project and it complains about record classes:
The text was updated successfully, but these errors were encountered: