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.

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

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.

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.

> 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.

> 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.