Why doesn't Java implement a better way of handling getters and setters? [closed]

Question

Getters and setters are everywhere in Java, but they are managed in a horribly outdated way.

Simply put: Why doesn't a newer version of Java enable a simpler syntax for managing it? Even if this syntax is converted to the old one by the compiler for compatibility, at least it would be good to let people write code without putting boilerplate getters everywhere.

For example instead of:

private String id;

public String getId() {
    return id;
}

We could just have:

public readonly String id;

And then, in the "client" code, instead of having to call getId everywhere, the compiler could detect if you are reading the variable id, and automatically match it at compilation by a getId call.

Example:

String userId = user.getId();

Becomes:

String userId = user.id: // Compiler automatically manages the call to getId

This post is not here for ranting, I'm just curious if there is a reason for not doing that, because it feels like Java could really use an update on that point.

Answer 1

There are many reasons why a particular language feature in a language might not be implemented.

In Java, data binding in Java Beans relies on the traditional arrangement of getter and setter methods, so it wouldn't work with first-class properties unless you rewrote the binder. Because you still have to support the old way, you now have two different ways of doing the same thing.

Adding language features is expensive, and the more widespread and popular the language is, the more expensive it is to add the feature. Every language feature that you add has to justify the expense; that is, it has to add more value than the time and effort required to implement it. Every language feature addition has an opportunity cost; time, money and programmer resources are not unlimited, so implementing one feature sometimes requires giving up another.

Eric Lippert describes the process better than anyone. He says that

Just being a good feature is not enough. Features have to be so compelling that they are worth the enormous dollar costs of designing, implementing, testing, documenting and shipping the feature. They have to be worth the cost of complicating the language and making it more difficult to design other features in the future.

A good example of this process is extension properties in C#. Extension properties seem like a natural addition to C#. But they weren't essential like Extension Methods were. As Eric explains:

It was of course immediately obvious that the natural companion to extension methods is extension properties. It's less obvious, for some reason, that extension events, extension operators, extension constructors (also known as "the factory pattern"), and so on, are also natural companions. But we didn't even consider designing extension properties for C# 3; we knew that they were not necessary and would add risk to an already-risky schedule for no compelling gain.

So they didn't get into C# 3, which would have been the natural place to put them. Now we'll probably never get them, because they're really not compelling enough as a standalone feature to justify the expense.

Further Reading
How Many Microsoft Employees does it Take to Screw In a Light Bulb?

Answer 2

Java is generally light on syntactic sugar. The only things that spring to mind are String concatenation with + and enhanced for loops. It seems the Java designers prefer to only add syntax for genuinely new semantics.

However, the only people who can definitely answer this question, are the designers of Java.

A tip: try to write up a JSR for your proposed change, and implement it in one of the open source Java compilers (e.g. OpenJDK javac, Eclipse ecj, etc.). Either you will run into problems (say, an ambiguity in the grammar, an ambiguity in the semantics of fields vs. methods, unsoundness of the overload resolution rules, whatever …), in which case you know the answer to your question, or you don't run into problems, in which case you can propose your change to the JCP, and maybe it will get accepted.

I can already sense that there will be ambiguities in the resolution of fields vs. methods, and I'm curious as to how you are going to handle that.