Emit java.util.Objects in generated code instead of Guava's Objects #2993

HannesWell · 2024-04-14T14:13:36Z

This PR adjusts XbaseCompiler and ObjectExtensions to emit java.util.Objects instead Guava's Objects class for generated code. java.util.Objects.equals is a drop-in replacement for Guava's Objects.equal().
All other changes are either just adoption of compiler tests or updates of xtend-generated code committed into this repository.

Some changes in the code generated for the examples is done in anticipation of this change. Without this change being submitted the compiler respectivly the Xtend-Container cause the old code to be generated.

This is the complement of #2992.

Part of #2975

HannesWell · 2024-04-14T14:20:22Z

Many changes in the generated code could be avoided if the (some of) the compiler tests would be migrated to pure Java classes using text-blocks, like in #2991.

LorenzoBettini · 2024-04-15T12:26:15Z

...nd.core.tests/xtend-gen/org/eclipse/xtend/core/tests/compiler/CompilerXtendIssue230Test.java

@@ -170,6 +170,6 @@ public void testIssue230() {
    _builder.newLine();
    _builder.append("}");
    _builder.newLine();
-    this.assertCompilesTo("\n\t\tpackage b\n\t\t\n\t\timport org.eclipse.xtend.lib.annotations.Accessors\n\t\t\n\t\tclass MyTest {\n\t\t\t\n\t\t\t@Accessors\n\t\t\tstatic class A1 {String name}\n\t\t\t@Accessors\n\t\t\tstatic class A2 {String name}\n\t\t\t\n\t\t\tdef doItWithNumber(Object n) \'\'\'\n\t\t\t�IF n instanceof A1�\n\t\t\t\tA1: �n.name�\n\t\t\t�ELSEIF n instanceof A2�\n\t\t\t\tA2: �n.name�\n\t\t\t�ELSE�\n\t\t\t\tElse: �n�\n\t\t\t�ENDIF�\n\t\t\t\'\'\'\n\t\t}\n\t\t", _builder);
+    this.assertCompilesTo("\r\n\t\tpackage b\r\n\t\t\r\n\t\timport org.eclipse.xtend.lib.annotations.Accessors\r\n\t\t\r\n\t\tclass MyTest {\r\n\t\t\t\r\n\t\t\t@Accessors\r\n\t\t\tstatic class A1 {String name}\r\n\t\t\t@Accessors\r\n\t\t\tstatic class A2 {String name}\r\n\t\t\t\r\n\t\t\tdef doItWithNumber(Object n) \'\'\'\r\n\t\t\t�IF n instanceof A1�\r\n\t\t\t\tA1: �n.name�\r\n\t\t\t�ELSEIF n instanceof A2�\r\n\t\t\t\tA2: �n.name�\r\n\t\t\t�ELSE�\r\n\t\t\t\tElse: �n�\r\n\t\t\t�ENDIF�\r\n\t\t\t\'\'\'\r\n\t\t}\r\n\t\t", _builder);


WARNING: "\r" Windows EOLs appeared! If you use Windows and use Xtend strings that span several lines you run into this (there's an open issue for that). I don't mean multiline strings ''' ... '''.

Ahh. Yes, I noticed already that this can happen as the changed java-files poluted my git staging. I actually wanted to check it before creating creating the PR, but forgot it. Sorry for that and thanks for spotting this.
I'm about to fix that.
In general this problem could be avoided if those tests would be converted to plain java classes using text-blocks, similar to #2991, but this would require a BREE of Java-17.
As far as I understand the plan for Java-21 you intend to raise the required java version to 17 with the support of Java-21.
I don't know how far your work on the Java-21 support has already reached. But if you are fine with it, I can provide a PR already now to raise the required Java-version for all Xtext bundles (in the MANIFEST.MF, .classpath and JDT settings, plus root pom.xml) and then a subsequent one to migrate the tests as suggested above.
This would also reduce the number of changes in this PR.

I'd wait for the transition to Java text blocks and Java 17.

In particular, similar to the others you experienced here, this issue is due to tests not using Xtend template strings (''') but standard quoted strings that keep the \r.

I don't think those tests were meant to use standard strings, and maybe at that time, it went unnoticed because most developers were using macOS or Linux.

I've opened an issue to track that: #2999

...ests/xtend-gen/org/eclipse/xtend/core/tests/macro/AbstractReusableActiveAnnotationTests.java

org.eclipse.xtend.core.tests/xtend-gen/org/eclipse/xtend/core/tests/smoke/SmokeTestCase.java

LorenzoBettini · 2024-04-15T12:31:05Z

org.eclipse.xtend.core.tests/xtend-gen/org/eclipse/xtend/core/tests/EmfModelsTest.java

@@ -225,48 +225,48 @@ private Object getDefaultValue(final Class<?> clazz) {
    boolean _isPrimitive = clazz.isPrimitive();
    if (_isPrimitive) {
      boolean _matched = false;
-      if (Objects.equal(clazz, Boolean.TYPE)) {
+      if (com.google.common.base.Objects.equal(clazz, Boolean.TYPE)) {


Why here there's still Objects.equal? I've seen that also below in another file

That remained since it is generated by the XbaseCompiler which is adapted just in this PR and my development-eclipse doesn't have this fix yet. I oversaw that since when I didn't have #2992 in the same branch and also had my search configured to not contain derived resources.

I have now used a secondary Eclipse launched from my Xtext workspace to regenerated all the java files that still contained Guava's Objects class.
Now, with this change I don't find any occurrence of com.google.common.base.Objects in my Xtext workspace, not even in derived resources.

Usually we do this update with a milestone update for the xtend version in the root pom

As you prefer.
Of course it would be bad to have mismatches in the generated code by the current XBaseCompiler.
So I think it mainly depends on which version you Xtext developers use. If you only use the latest milestone, then I agree this should be postponed, if you use the latest nightly build it is probably ok to change it now in since you would adapt it the next day after this is submitted any ways.

@HannesWell I didn't think about that.

I typically use the latest nightly in my Xtext workspace.

@cdietrich do you prefer to keep the old version of the generated files for the moment?

Do you have Cappa to regen all

Also is this about fragment or about xtend
If xtend regen with the m2 boot strap

@cdietrich this is not about the fragment but about a change in XbaseCompiler, so the regenerated Java code from Xtend could be done once we install the new Xtend in the development workspace (i.e., when this is merged to master, the nightly p2 site is published, and the development workspace takes Xtend from the nightly p2 site). When we publish M1, the xtend maven plugin will also behave accordingly.

Yes this is why I hesitate to regen rn. If we can burn milestones we could build it now after merge and then for the real milestone but I guess it’s not Wort or

LorenzoBettini · 2024-04-15T12:33:11Z

I've just left a few comments, I see @szarnekow is already reviewing that.

Part of eclipse-xtext#2975

HannesWell · 2024-04-25T16:30:20Z

M2 is approaching so I wonder if this should be landed before it and if there is anything I can do to make this to completion?

LorenzoBettini · 2024-04-25T16:45:13Z

As for me, we could merge this; the updated generated Java files can be done in another PR, once this update is part of the nightly update site.

szarnekow · 2024-04-25T16:46:49Z

Ok. But let's make sure we regen Xtend before M2

HannesWell · 2024-04-25T16:53:29Z

As for me, we could merge this; the updated generated Java files can be done in another PR, once this update is part of the nightly update site.

So should I revert the anticipatory changes of generated code or leave it as it is?

cdietrich · 2024-04-25T16:54:58Z

I assume you can leave it as the build will replace then anyway

HannesWell · 2024-04-25T17:03:23Z

I assume you can leave it as the build will replace then anyway

Yes the build replaces it automatically, but at the moment this PR already contains the changes the XtendBuilder will do once this change is available in the development Eclipses (I created the current state with a secondary Eclipse launched with this PR).
So without this change available, i.e. if you don't update to the nightly build immediatly you will get the following changes in your WS that undo parts of this PR:

But from your previous comments I understand it that you don't want to have that anticipatory changes now but apply it once you update the dev-Eclipses to M2?

cdietrich · 2024-04-25T17:04:47Z

I don’t care. Repo code differs from shipped code for m2

szarnekow · 2024-04-25T17:21:13Z

if you don't update to the nightly build immediatly

It's necessary in any case. So no worries. Thank you for the modernization of the generated code!

HannesWell · 2024-04-26T15:18:31Z

if you don't update to the nightly build immediatly

It's necessary in any case. So no worries. Thank you for the modernization of the generated code!

Great and you are welcome. I'm glad to get more modern code generated. :)

Since everbody seem to be fine with this change can it be submitted or should I rebase it on the current master first?

LorenzoBettini · 2024-04-27T19:24:43Z

@HannesWell Thanks! I've just merged.

LorenzoBettini · 2024-04-27T19:25:58Z

The first one who updates the development environment to the nightly update site can then create a PR with the regenerated code.

LorenzoBettini · 2024-04-27T19:30:13Z

@cdietrich I don't understand what you were proposing here:

Yes this is why I hesitate to regen rn. If we can burn milestones we could build it now after merge and then for the real milestone but I guess it’s not Wort or

HannesWell · 2024-04-27T21:20:28Z

@HannesWell Thanks! I've just merged.

Thank you. :)

cdietrich · 2024-04-28T05:46:54Z

Normally I would wait after the milestone or build an extra milestone but I have no Cappa so I don’t care

after #2993

szarnekow assigned HannesWell Apr 14, 2024

szarnekow self-requested a review April 14, 2024 14:23

szarnekow added this to the Release_2.35 milestone Apr 14, 2024

szarnekow added the enhancement label Apr 14, 2024

HannesWell force-pushed the emit_java.utils.Objects_in_generate_code branch from 710494a to 26bb015 Compare April 14, 2024 14:32

LorenzoBettini reviewed Apr 15, 2024

View reviewed changes

...ests/xtend-gen/org/eclipse/xtend/core/tests/macro/AbstractReusableActiveAnnotationTests.java Outdated Show resolved Hide resolved

LorenzoBettini reviewed Apr 15, 2024

View reviewed changes

org.eclipse.xtend.core.tests/xtend-gen/org/eclipse/xtend/core/tests/smoke/SmokeTestCase.java Outdated Show resolved Hide resolved

LorenzoBettini reviewed Apr 15, 2024

View reviewed changes

Emit java.util.Objects in generated code instead of Guava's Objects

720e7a9

Part of eclipse-xtext#2975

HannesWell force-pushed the emit_java.utils.Objects_in_generate_code branch from 26bb015 to 720e7a9 Compare April 15, 2024 17:20

LorenzoBettini mentioned this pull request Apr 16, 2024

Check usage of quoted strings instead of multiline strings in some Xtend tests #2999

Closed

szarnekow requested a review from LorenzoBettini April 25, 2024 16:47

szarnekow approved these changes Apr 25, 2024

View reviewed changes

LorenzoBettini approved these changes Apr 27, 2024

View reviewed changes

LorenzoBettini merged commit 385e329 into eclipse-xtext:main Apr 27, 2024
6 checks passed

HannesWell deleted the emit_java.utils.Objects_in_generate_code branch April 27, 2024 21:20

LorenzoBettini added a commit that referenced this pull request Apr 29, 2024

regenerated Xtend file

341050e

after #2993

This was referenced Apr 29, 2024

Regenerated Xtend files #3022

Merged

Line ending confusion in generated files of Xtext project? #2778

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Emit java.util.Objects in generated code instead of Guava's Objects #2993

Emit java.util.Objects in generated code instead of Guava's Objects #2993

HannesWell commented Apr 14, 2024 •

edited

Loading

HannesWell commented Apr 14, 2024

LorenzoBettini Apr 15, 2024

HannesWell Apr 15, 2024

LorenzoBettini Apr 16, 2024

LorenzoBettini Apr 15, 2024

HannesWell Apr 15, 2024

cdietrich Apr 15, 2024

HannesWell Apr 15, 2024

LorenzoBettini Apr 16, 2024

cdietrich Apr 25, 2024

cdietrich Apr 25, 2024

LorenzoBettini Apr 25, 2024

cdietrich Apr 25, 2024

LorenzoBettini commented Apr 15, 2024

HannesWell commented Apr 25, 2024

LorenzoBettini commented Apr 25, 2024

szarnekow commented Apr 25, 2024

HannesWell commented Apr 25, 2024

cdietrich commented Apr 25, 2024

HannesWell commented Apr 25, 2024

cdietrich commented Apr 25, 2024

szarnekow commented Apr 25, 2024

HannesWell commented Apr 26, 2024

LorenzoBettini commented Apr 27, 2024

LorenzoBettini commented Apr 27, 2024

LorenzoBettini commented Apr 27, 2024

HannesWell commented Apr 27, 2024

cdietrich commented Apr 28, 2024

Emit java.util.Objects in generated code instead of Guava's Objects #2993

Emit java.util.Objects in generated code instead of Guava's Objects #2993

Conversation

HannesWell commented Apr 14, 2024 • edited Loading

HannesWell commented Apr 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LorenzoBettini commented Apr 15, 2024

HannesWell commented Apr 25, 2024

LorenzoBettini commented Apr 25, 2024

szarnekow commented Apr 25, 2024

HannesWell commented Apr 25, 2024

cdietrich commented Apr 25, 2024

HannesWell commented Apr 25, 2024

cdietrich commented Apr 25, 2024

szarnekow commented Apr 25, 2024

HannesWell commented Apr 26, 2024

LorenzoBettini commented Apr 27, 2024

LorenzoBettini commented Apr 27, 2024

LorenzoBettini commented Apr 27, 2024

HannesWell commented Apr 27, 2024

cdietrich commented Apr 28, 2024

HannesWell commented Apr 14, 2024 •

edited

Loading