5 ms·

The problem isn't the first-time generating the code. The problem is when objects gain fields and people forget to add them to hashCode and equals (or worse, ha

by lucumo 2y ago

The problem isn't the first-time generating the code. The problem is when objects gain fields and people forget to add them to hashCode and equals (or worse, hashCode OR equals). It's the kind of thing you won't notice until months later when you have intermittent hard to debug glitches in your system. Records have reduced the advantages of Lombok by a boatload. But there still are some things that can't be records.

xxs 2y ago
>add them to hashCode and equals (or worse, hashCode OR equals) That's a fundamental misunderstanding of hashCode, and lombok makes no exception. Not all fields need to be used to calculate hashCode, it makes the overall performance worse in most cases. Equals is of course different, however if you have an identity (i.e. database primary key), only the identity should be used.
- cogman10 2y ago
  Hurray! I thought I was the only one that understood this. There are two of us! I've seen so many performance issues with hashcode because devs will put all fields into it. Even though there's an id column or even fields that imply other fields. Hashing 1000 char strings when there's a UUID or int field that guarantees identity is silly. I think it's because devs have an preference for symmetry. I see the same thing happen when they preferably add setters for all fields even though they aren't necessary.
  - xxs 2y ago
    >There are two of us! Realistically, I have trained quite a few folks on my own. >I think it's because devs have an preference for symmetry. Another option is that's the default for all IDEs auto gen, so few clicks/taps and it's done.
    - ivan_gammel 2y ago
      In Idea you have to explicitly select the fields which should be included. So it’s always choice of a developer to misuse it. My favorite question on interviews is explaining all methods of class Object, including the contract and best practices for equals/hashCode. Failure to answer this question automatically disqualifies applicants to mid-level and senior positions.
      - xxs 2y ago
        >all methods of class Object finalize() is actually is a very hard mode; I'd not expect any extra senior to be able to explain it properly (incl. the semantics of JMM, the fact half created objects can be finalized; the resurrection ability). Deprecated now, so perhaps no need? wait/notify/notifyAll - easier, still require some practice, also not that useful any longer; but still I'd expect to know not to use a naked notify and how to properly use a loop around wait clone() - it'd be a hard nut for many, and I have seen more than enough implementations that straight out use new XXX(); not very difficult but not intuitive hashCode/equals -> hashCode being by default a random number generator is sort of cool; yes they are the backbone of all collection framework; also the value of the not overridden hashCode() is available through System.identifyHashCode() getClass() - if included anonymous classes, it might puzzle some toString() - finally something easy --- flip note: the standard templates for intellij could use some work when it comes to the quality of hashCode;
        ivan_gammel 2y ago
        > finalize() is actually is a very hard mode; > Deprecated now, so perhaps no need? Yes. Worth mentioning existence and “do not touch it”, but no need to go deep. Same with clone. The point of this exercise is to demonstrate that you can use the core library without shooting yourself in the foot. As for wait/notify/notifyAll, I’d expect the correct usage patterns from mid-level.
        vips7L 2y ago
        > the standard templates for intellij could use some work when it comes to the quality of hashCode; Doesn't everyone just use Objects::hash?
- lucumo 2y ago
  > That's a fundamental misunderstanding of hashCode Right. So the parenthetical clause should more correctly state "(or worse, adding them to hashCode but not equals)". That's fine, but it's still the same problem: there's a hidden dependency between changes in two or more locations. People make errors in those kind of updates all the time.
  - xxs 2y ago
    >or worse, adding them to hashCode but not equals That's proper bad, however it should be noted in a pull request and explained how hashCode operates - people learn and improve. > there's a hidden dependency between changes in two or more location True, of course. However, just do not modify hashCode and consider if the extra fields do contribute to equality either. Realistically I have not seen this error since very early 00s. I have seen use of mutable fields in hashCode, though (and the latter being modified while added to a hashset, used as map keys. lombok encourages such designs). Another a lot more common error is "compareTo"

by lucumo 2y ago

xxs 2y ago

>add them to hashCode and equals (or worse, hashCode OR equals) That's a fundamental misunderstanding of hashCode, and lombok makes no exception. Not all fields need to be used to calculate hashCode, it makes the overall performance worse in most cases. Equals is of course different, however if you have an identity (i.e. database primary key), only the identity should be used.

cogman10 2y ago
Hurray! I thought I was the only one that understood this. There are two of us! I've seen so many performance issues with hashcode because devs will put all fields into it. Even though there's an id column or even fields that imply other fields. Hashing 1000 char strings when there's a UUID or int field that guarantees identity is silly. I think it's because devs have an preference for symmetry. I see the same thing happen when they preferably add setters for all fields even though they aren't necessary.
- xxs 2y ago
  >There are two of us! Realistically, I have trained quite a few folks on my own. >I think it's because devs have an preference for symmetry. Another option is that's the default for all IDEs auto gen, so few clicks/taps and it's done.
  - ivan_gammel 2y ago
    In Idea you have to explicitly select the fields which should be included. So it’s always choice of a developer to misuse it. My favorite question on interviews is explaining all methods of class Object, including the contract and best practices for equals/hashCode. Failure to answer this question automatically disqualifies applicants to mid-level and senior positions.
    - xxs 2y ago
      >all methods of class Object finalize() is actually is a very hard mode; I'd not expect any extra senior to be able to explain it properly (incl. the semantics of JMM, the fact half created objects can be finalized; the resurrection ability). Deprecated now, so perhaps no need? wait/notify/notifyAll - easier, still require some practice, also not that useful any longer; but still I'd expect to know not to use a naked notify and how to properly use a loop around wait clone() - it'd be a hard nut for many, and I have seen more than enough implementations that straight out use new XXX(); not very difficult but not intuitive hashCode/equals -> hashCode being by default a random number generator is sort of cool; yes they are the backbone of all collection framework; also the value of the not overridden hashCode() is available through System.identifyHashCode() getClass() - if included anonymous classes, it might puzzle some toString() - finally something easy --- flip note: the standard templates for intellij could use some work when it comes to the quality of hashCode;
      - ivan_gammel 2y ago
        > finalize() is actually is a very hard mode; > Deprecated now, so perhaps no need? Yes. Worth mentioning existence and “do not touch it”, but no need to go deep. Same with clone. The point of this exercise is to demonstrate that you can use the core library without shooting yourself in the foot. As for wait/notify/notifyAll, I’d expect the correct usage patterns from mid-level.
      - vips7L 2y ago
        > the standard templates for intellij could use some work when it comes to the quality of hashCode; Doesn't everyone just use Objects::hash?
lucumo 2y ago
> That's a fundamental misunderstanding of hashCode Right. So the parenthetical clause should more correctly state "(or worse, adding them to hashCode but not equals)". That's fine, but it's still the same problem: there's a hidden dependency between changes in two or more locations. People make errors in those kind of updates all the time.
- xxs 2y ago
  >or worse, adding them to hashCode but not equals That's proper bad, however it should be noted in a pull request and explained how hashCode operates - people learn and improve. > there's a hidden dependency between changes in two or more location True, of course. However, just do not modify hashCode and consider if the extra fields do contribute to equality either. Realistically I have not seen this error since very early 00s. I have seen use of mutable fields in hashCode, though (and the latter being modified while added to a hashset, used as map keys. lombok encourages such designs). Another a lot more common error is "compareTo"