Skip to content
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

@Wither generates code, which violates best practives #737

Closed
lombokissues opened this issue Jul 14, 2015 · 7 comments
Closed

@Wither generates code, which violates best practives #737

lombokissues opened this issue Jul 14, 2015 · 7 comments

Comments

@lombokissues
Copy link

Migrated from Google Code (issue 702)

@lombokissues
Copy link
Author

👤 mcbeelen   🕗 Jul 04, 2014 at 07:07 UTC

What steps will reproduce the problem?

  1. Create a class Book with two fields (Long id, String name)
  2. @ Wither on the id-field
  3. 'De-lombok' the code

Generated code looks like:
public Book withId(Long id) {
return this.id == id ? this : new Book(id, this.name);
}

What is the expected output? What do you see instead?
public Book withId(Long id) {
return this.id.equals(id) ? this : new Book(id, this.name);
}

What version of the product are you using? On what operating system?
Lombok 1.14.4 on MacOSX (In IntelliJ)

Please provide any additional information below.
The generated code raises a violation in our QA reporting (Sonar):

Bad practice - Suspicious reference comparison

This method compares two reference values using the == or != operator, where the correct way to compare instances of this type is generally with the equals() method. Examples of classes which should generally not be compared by reference are java.lang.Integer, java.lang.Float, etc.
findbugs:RC_REF_COMPARISON Sep12 Reliability > Instruction

@lombokissues
Copy link
Author

👤 r.spilker   🕗 Jul 04, 2014 at 07:58 UTC

This is done on purpose. Executing the equals might be way more expensive than just creating a copy of the instance.

@lombokissues
Copy link
Author

👤 Maaartinus   🕗 Aug 30, 2014 at 02:15 UTC

While I completely agree with using '=' being the best choice, I wonder if there's any sane way to make the checker (findbugs in my case) shut up. Currently, I see two possibilities:

  • adding @ SuppressFBWarnings("ES_COMPARING_PARAMETER_STRING_WITH_EQ") to the whole class.
  • Using @ Wither(onMethod=@ __(@ SuppressFBWarnings("ES_COMPARING_PARAMETER_STRING_WITH_EQ"))).

While the former method is too unspecific, the latter is way too long (especially when @ Wither gets applied to a couple of fields rather than the whole class).

Maybe there could be a configuration key like HUSH_FINDBUGS doing this automatically?

@lombokissues
Copy link
Author

👤 reinierz   🕗 Nov 20, 2014 at 13:14 UTC

Re-opening this; now that we have a config system, we can have a config key to add @ SuppressFBWarnings(justification = "Generated code") to everything if the user likes.

@lombokissues lombokissues added accepted The issue/enhancement is valid, sensible, and explained in sufficient detail and removed invalid-or-intentional labels Jul 14, 2015
@lombokissues lombokissues reopened this Jul 14, 2015
@lombokissues
Copy link
Author

👤 reinierz   🕗 Feb 01, 2015 at 23:18 UTC

For now the justification is not configurable, it's just 'generated code' (all lowercase, no final dot, I believe that's the proper style), and obviously not enabled by default, but there's a config key to turn it on.

I assume that is enough to make FB shut up? I don't need to provide any particular value to it?

This feature is available in the edge build now, and should be in the next version.

https://projectlombok.org/download-edge.html

@lombokissues
Copy link
Author

👤 reinierz   🕗 Feb 01, 2015 at 23:29 UTC

Issue #770 has been merged into this issue.

@lombokissues
Copy link
Author

End of migration

lianhaijun pushed a commit to lianhaijun/lombok that referenced this issue May 8, 2020
* Fixed for issue 724: @accessors with prefix can break with numbers
* - replace isUpperCase || isDigit to !isLowerCase for AccessorInfo prefix check
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant