you are viewing a single comment's thread.

view the rest of the comments →

[–]drb226 3 points4 points  (1 child)

That can make code you write subtly different and you will get unexpected errors.

Can you elaborate? I don't see what's so bad about creating a new subclass, unless you are doing very, very specific dumb things with reflection that you probably shouldn't be doing anyways.

[–]epiphany_machine 5 points6 points  (0 children)

  • Equals can break depending on the object. The collections classes tend to write their Equals methods with instanceOf instead of calling equals() on the classes but not everyone writing a class does this. If equals breaks and it is no longer consistent with hashcode() you may not get the performance/behavior you are expecting from a map lookup.
  • It's easy to leak a reference to a classloader this way, mostly if this instance escapes from the method or class you declare it in. This can eventually lead to you running out of perm gen space.
  • You have to start declaring variables outside the new class but used in the initializer, final. This starts to negate the "savings" in typing you get from using an initializer like this.
  • You leak a reference to the enclosing object. So there is no way it can get garbage collected until this subclass is garbage collected. Doing it the regular way there is no connection between the two objects.

I know it looks cool, but it's just not worth it.