Hacker News Reader

Comment by hiram112 | Hacker News Reader

I've seen numerous posts lamenting the use of typical Java Beans.

The problem with the struct approach is that numerous tooling / libraries expects beans with typical getter/setters - Jackson Json, Spring binding, etc. Yes it's possible with configurations and/or annotations to get around this, but IMO, saving a few lines of code in exchange for non-default behavior isn't a valid trade-off.

Adding a dependency on Lombock is even worse.

Honestly, I can spot a Bean class within 1 second of opening it up. Unlike Scala or other languages, Java programmers typically use one class per file, and beans rarely get in the way as they're typically contained in some 'model' package anyway.

View on HN

Another problem with struct approach is inconsistency.

Sometimes you want a computed property and you use non-trivial getter. Sometimes you want to do some work in setter. And then client's code will look terrible: point.x * point.x + point.getY() * point.getY(). There are other problems: binary incompatibility; non-trivial refactoring when I need to introduce a getter or setter.

Java really need lightweight property syntax which would solve all those problems. I don't understand why it isn't introduced yet.

> Sometimes you want a computed property and you use non-trivial getter

Then pre-compute it, make it immutable, and expose the variable. And if that ends up being too hard it's probably because you need a builder and/or to group your properties into smaller classes.

Precomputing properties on a hundred million object instances is not cheap.

Going from C# to Java, one of the biggest things I miss is the Property syntax.

C# property shares its own set of issues , especially when there are exceptions involved.

The lack of simple property syntax is probably the main reason I keep using Groovy now that Java 8 has arrived. Yes, state is evil. But there are still plenty of situations where you are just schlepping data around and generating thousands of lines of boilerplate to achieve simple data transfer is such a pointless and ugly hack.

For DTOs we don't user mutators. Just public member variables. It is the only way to keep business logic out of them. That being said, I wish Java has some object/struct syntactic sugar like Javascript Object Literals. They are so powerful.

Projects exist to to make a light weight property syntax. The most prominent might be @Getter and @Setter from lombok (https://projectlombok.org/), but there are others which have similar goals (e.g. http://immutables.github.io/, https://github.com/google/auto).

That said, I agree that java _really_ needs something like this built in.

I'm surprised I haven't seen anybody mention the "public final fields" approach yet. I use this myself for immutable objects and I quite like it. Granted, you still need to implement equals and hashcode, but these can be generated easily and verified with tools like EqualsVerifier [2].

[1]

  public class MyImmutable {
    public final String field1;
    public final int field2;

    public MyImmutable(String field1, int field2) {
        // assign
    }

     // equals, hashcode, toString
  }

[2] https://github.com/jqno/equalsverifier

> Spring binding

Not sure what in particular you're referring to, but Spring supports constructor based dependency injection, and I tend to insist upon it vehemently - getter/setter injection means that you can instantiate your object in an invalid state.

Lombock is one of the most valuable enhancements to Java. Without it, it would make Java development not as fun.

Lombok is also a non-standard dependency and there are costs with having to rely on it.

If the cost overweights the benefit you can delombok everything will works as before.

The problem comes when you spot a Bean class and then it isn't. 99.9% of "getX" methods simply read the field. But if you assume that every "getX" method just reads the field, you'll be caught out by the rare one that doesn't - I've seen a production bug happen this way.

Also, whatever stylistic issues are raised by JavaBeans are largely obviated by modern IDEs.

Reply on news.ycombinator.com