Question

Is it completely against the Java way to create struct like objects?

class SomeData1 {     public int x;     public int y; } 

I can see a class with accessors and mutators being more Java like.

class SomeData2 {     int getX();     void setX(int x);      int getY();     void setY(int y);      private int x;     private int y; } 

The class from the first example is notationally convenient.

// a function in a class public int f(SomeData1 d) {     return (3 * d.x) / d.y; } 

This is not as convenient.

// a function in a class public int f(SomeData2 d) {     return (3 * d.getX()) / d.getY(); } 

Answer 1

This is a commonly discussed topic. The drawback of creating public fields in objects is that you have no control over the values that are set to it. In group projects where there are many programmers using the same code, it’s important to avoid side effects. Besides, sometimes it’s better to return a copy of field’s object or transform it somehow etc. You can mock such methods in your tests. If you create a new class you might not see all possible actions. It’s like defensive programming – someday getters and setters may be helpful, and it doesn’t cost a lot to create/use them. So they are sometimes useful.

In practice, most fields have simple getters and setters. A possible solution would look like this:

public property String foo;    a->Foo = b->Foo; 

Update: It’s highly unlikely that property support will be added in Java 7 or perhaps ever. Other JVM languages like Groovy, Scala, etc do support this feature now. – Alex Miller