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.


String userId = user.getId();


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.

  • 3
    It is really hard to answer questions of the type "why doesn't language X have feature Y." There is an infinite number of features you can imagine which language X doesn't have.Only if the feature was actually proposed, considered and rejected by the language designers is it possible to answer why.
    – JacquesB
    Commented Oct 24, 2015 at 18:21
  • Really getters and setters that just set and read private variables serve little purpose. I don't think they were ever supposed to be common (they have become common but I don't think they were supposed to be) Commented Oct 24, 2015 at 19:00
  • You are right for setters. But for getters, it's extremely common to need to read the value of a variable that needs to be read only, so you can read it but not modify it.
    – nialna2
    Commented Oct 24, 2015 at 20:38
  • @Malharhak getters too. Objects are not structs, they aren't supposed to just hold data till someone wants it (sometimes they do, but they should be the exception not the norm). They should have behaviour that their state (immutable or otherwise) informs. Commented Oct 25, 2015 at 17:21
  • Have you looked at Lombok? Commented Oct 27, 2015 at 0:57

2 Answers 2


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?


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.

  • As an example, Objective-C has "interesting" rules for naming getters and setters, and if you had members id and Id you would get interesting problems. And that's just a tiny detail.
    – gnasher729
    Commented Oct 24, 2015 at 18:35
  • A similar proposal was made during project coin (which was a collection of small language improvements made to Java 7), but was rejected because the idea was submitted too late. I believe there is some talk of running a process like coin again for Java 10 (Java 9 is already in feature freeze, so it can't be done any earlier), at which point the proposal would likely be considered in more detail.
    – Jules
    Commented Oct 24, 2015 at 21:41
  • Yep. Objective C generates these methods in the background or something. So if you try to name a method getId and already have a id variable, the compiler won't let you build.
    – nialna2
    Commented Oct 24, 2015 at 23:15
  • 1
    I would argue that string-concatenation with + is far more prominent than those for-loops. Commented Oct 25, 2015 at 6:24
  • @Malharhak: No, the compiler will synthesise a getter and setter for you if you don't provide one yourself. Now id is a bad example, because id is a reserved word in Objective-C, but if you have a property value then you can write the getter ("value", not "getValue" in Objective-C) and only the setter is synthesised, or write your own "setValue" and only the getter is synthesised, or write both and nothing is synthesised (no backing variable either).
    – gnasher729
    Commented Oct 27, 2015 at 0:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.