Bug 458720 - Use GWT compatible utility methods in generated hashCode(), equals(), toString() implementations
Summary: Use GWT compatible utility methods in generated hashCode(), equals(), toStrin...
Status: UNCONFIRMED
Alias: None
Product: Xtend
Classification: Tools
Component: Core (show other bugs)
Version: 2.7.3   Edit
Hardware: PC Windows 7
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-29 05:54 EST by Norbert Sándor CLA
Modified: 2016-05-08 14:13 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Norbert Sándor CLA 2015-01-29 05:54:13 EST
For example, instead of generating code like

  public int hashCode() {
    final int prime = 31;
    int result = super.hashCode();
    result = prime * result + ((this.o== null) ? 0 : this.o.hashCode());
    return result;
  }

use

  com.google.common.base.Objects.hashCode(Object...)

There are similar utility methods for generating compact and GWT compatible equals() and toString() as well.
See: https://code.google.com/p/guava-libraries/wiki/CommonObjectUtilitiesExplained

Furthermore in my case the generated toString() method is not GWT compatible:

  public String toString() {
    String result = new ToStringBuilder(this)
    	.addAllFields() // not supported by GWT
    	.toString();
    return result;
  }
Comment 1 Stefan Oehme CLA 2015-01-30 10:22:18 EST
We don't use Guava API directly in our generated code, because otherwise the xbase.lib.slim would not work (it has an inlinded and renamed version of Guava)

toString uses reflection when your class has a superclass, because there is no other way to get all the fields. I'm not a huge fan of this mechanism, but this is how it worked before and we needed to be backwards compatible. 

We may introduce something like "callSuper", which would nest the superclass toString inside the subclass.