Adding a custom record constructor prevents successful compilation #10045
Comments
|
Workaround: public record Rec(String s) {
public Rec { }
public Rec(int i) {
this("" + i);
}
}Two stack traces I've identified that can come from this bug - this looks like the one reported: And another that is similar, but not quite the same: The bug is that when being called in this way, the "super" constructor is incorrectly identified as being a native method as it has no body. I'm still working out why it has no body - it appears that either JDT doesn't emit a body for the canonical record constructor if there is a non-default constructor declared, or GWT just doesn't read it properly - but if the canonical constructor is declared or no constructors are declared at all, it will correctly have the field assignments as expected. |
|
This is an upstream JDT bug, already fixed there: eclipse-jdt/eclipse.jdt.core#365. It appears that updating to 3.33 may resolve this. That version is also compiled to work with Java 11 so we should be safe to update, but it might be risky to do so on a point release like 2.12.2. We should be able to work around it in a way that still works when JDT is later updated, by detecting if the body is missing from the canonical constructor, and if so, generate the field assignments. There is a caveat here that this must end up in the GwtAstBuilder rather than in ImplementRecordComponents - since the field assignments never were generated, the first |
Very helpful 👍 |
|
Unfortunately, JDT 3.33.0 does not fix this, it is 3.34.0 that fixes it, but 3.34.0 will require that we drop Java 11 support and build GWT with Java 17 . I have updated GWT JDT and a made a local build with both versions of JDT to test it. |
|
I assume, we will see this happen more often in the future. Many components start required at least Java 17. May be it is time to start a discussion if GWT still support Java 11 or not and request at least Java 17. |
|
Agreed - let's raise this in the new year on the mailing list. We would be in good company dropping support for Java 11, but at the same time I'm guessing there are more than a few projects which successfully updated from Java 8 and are not ready to move past 11 for a little while. Reviewing some of the "state of Java ecosystem 2024" surveys, the percent of projects using Java 11 is roughly the same as last year, though given the trends with 8/17/21 I am guessing that this indicates mostly the portion of Java 8 projects that updated but couldn't yet move to 17 or 21. The good news there is that we haven't heard any pushback at all on dropping Java 8, so we likely aren't in a position to backport anything to 2.11 - but if we make 2.12 the end of Java 11 support, we may end up with a string of backport releases there. |
From how it looks it requires GWT itself to be built with 3.34.0 at least, which means GWT itself will be built with Java 17, here is a summary of my testing using unpacked jars as suggested in #10026 :
|
|
If we would release gwt-dev without the JDT, then we can build gwt using java 11 and JDT 3.33.0 then in the user application they can add a dependency on jdt 3.34.0 and build with java 17 and the issue should be fixed. |
|
This is a possible solution. However, one that requires a configuration for GWT to run flawlessly. Looking back, this would be the first time in GWT's history that a user has to make a configuration before a build works. I think we should, as @niloc132 already suggested, start a survey and make a decision depending on the outcome. Personally, I would be in favor of upgrading to Java 17. |
|
Part of my experiment was related to some work being done to move gwt build from ant to maven, and this was a confirmation that this kind of limitation can be avoided when we switch and provides a work around so people wont be blocked by this until the next release or so. |
|
That's what I understood. I just wanted to point out that it will be the first time in the history of GWT that a dependency needs to be added for a successful build and the questions that come with it. And, you also have to ask the question, what effects does this have on third-party libs. However, it is good to know that there is a workaround. |
|
I think you still misunderstand slightly @FrankHossfeld - the linked #10026 issue would not require any other dependencies added except to resolve the current issue. For any user not using records, or using records with the workaround provided here, it would be sufficient to ignore this custom setup - and we will not close this issue at all until HEAD-SNAPSHOT without extra dependencies has the bug fixed. Instead, when the JDT is removed from the maven copy of gwt-dev.jar (like asm, htmlunit, and a few others), the gwt-dev pom.xml will include a dependency to it, so user projects will transitively pick it up. Projects not using artifacts from maven central will still include the jdt classes in the jar, so they will remain unaffected (and cannot apply this workaround). |
|
Yeap, you are right. Thought anyone has to do it with the upcoming release. |
**GWT version: 2.12.1
**Browser (with version): any
**Operating System: any
Description
A custom record constructor prevents successful compilation even if never invoked
Steps to reproduce
invoked like this
Known workarounds
Don't use custom constructors
Links to further discussions
The text was updated successfully, but these errors were encountered: