Absence of property syntax in Java

Question

C# has syntax for declaring and using properties. For example, one can declare a simple property, like this:

public int Size { get; set; }

One can also put a bit of logic into the property, like this:

public string SizeHex
{
    get
    {
        return String.Format("{0:X}", Size);
    }
    set
    {
        Size = int.Parse(value, NumberStyles.HexNumber);
    }
}

Regardless of whether it has logic or not, a property is used in the same way as a field:

int fileSize = myFile.Size;

I'm no stranger to either Java or C# -- I've used both quite a lot and I've always missed having property syntax in Java. I've read in this question that "it's highly unlikely that property support will be added in Java 7 or perhaps ever", but frankly I find it too much work to dig around in discussions, forums, blogs, comments and JSRs to find out why.

So my question is: can anyone sum up why Java isn't likely to get property syntax?

• Is it because it's not deemed important enough when compared to other possible improvements?
• Are there technical (e.g. JVM-related) limitations?
• Is it a matter of politics? (e.g. "I've been coding in Java for 50 years now and I say we don't need no steenkin' properties!")
• Is it a case of bikeshedding?

Answer 1

I think it's just Java's general philosophy towards things. Properties are somewhat "magical", and Java's philosophy is to keep the core language as simple as possible and avoid magic like the plague. This enables Java to be a lingua franca that can be understood by just about any programmer. It also makes it very easy to reason about what an arbitrary isolated piece of code is doing, and enables better tool support. The downside is that it makes the language more verbose and less expressive. This is not necessarily the right way or the wrong way to design a language, it's just a tradeoff.

Answer 2

For 10 years or so, sun has resisted any significant changes to the language as hard as they could. In the same period C# has been trough a riveting development, adding a host of new cool features with every release.

I think the train left on properties in java a long time ago, they would have been nice, but we have the java-bean specification. Adding properties now would just make the language even more confusing. While the javabean specification IMO is nowhere near as good, it'll have to do. And in the grander scheme of things I think properties are not really that relevant. The bloat in java code is caused by other things than getters and setters.

There are far more important things to focus on, such as getting a decent closure standard.

Answer 3

Property syntax in C# is nothing more than syntactic sugar. You don't need it, it's only there as a convenience. The Java people don't like syntactic sugar. That seems to be reason enough for its absence.

Answer 4

Possible arguments based on nothing more than my uninformed opinion

• the property syntax in C# is an ugly hack in that it mixes an implementation pattern with the language syntax
• It's not really necessary, as it's fairly trivial.
• It would adversly affect anyone paid based on lines of code.

I'd actually like there to be some sort of syntactical sugar for properties, as the whole syntax tends to clutter up code that's conceptually extremely simple. Ruby for one seems to do this without much fuss.

On a side note, I've actually tried to write some medium-sized systems (a few dozen classes) without property access, just because of the reduction in clutter and the size of the codebase. Aside from the unsafe design issues (which I was willing to fudge in that case) this is nearly impossible, as every framework, every library, every everything in java auto-discovers properties by get and set methods.They are with us until the very end of time, sort of like little syntactical training wheels.

Answer 5

I would say that it reflects the slowness of change in the language. As a previous commenter mentioned, with most IDEs now, it really is not that big of a deal. But there are no JVM specific reasons for it not to be there.

Answer 6

According to Volume 2 of Core Java (Forgotten the authors, but it's a very popular book), the language designers thought it was a poor idea to hide a method call behind field access syntax, and so left it out.

Answer 7

Might be useful to add to Java, but it's probably not as high on the list as closures.

Personally, I find that a decent IDE makes this a moot point. IntelliJ can generate all the getters/setters for me; all I have to do is embed the behavior that you did into the methods. I don't find it to be a deal breaker.

I'll admit that I'm not knowledgeable about C#, so perhaps those who are will overrule me. This is just my opinion.

Answer 8

If I had to guess, I'd say it has less to do with a philosophical objection to syntactic sugar (they added autoboxing, enhanced for loops, static import, etc - all sugar) than with an issue with backwards compatibility. So far at least, the Java folks have tried very hard to design the new language features in such a way that source-level backwards compatibility is preserved (i.e. code written for 1.4 will still compile, and function, without modification in 5 or 6 or beyond).

Suppose they introduce the properties syntax. What, then does the following mean:

myObj.attr = 5;

It would depend on whether you're talking about code written before or after the addition of the properties feature, and possibly on the definition of the class itself.

I'm not saying these issues couldn't be resolved, but I'm skeptical they could be resolved in a way that led to a clean, unambiguous syntax, while preserving source compatibility with previous versions.

The python folks may be able to get away with breaking old code, but that's not Java's way...

Answer 9

You may not need for "get" and "set" prefixes, to make it look more like properties, you may do it like this:

public class Person {
    private String firstName = "";
    private Integer age = 0;

    public String firstName() { return firstName; } // getter
    public void firstName(String val) { firstName = val; } // setter

    public Integer age() { return age; } // getter
    public void age(Integer val) { age = val; } //setter

    public static void main(String[] args) {
        Person p = new Person();

        //set
        p.firstName("Lemuel");
        p.age(40);

        //get
        System.out.println(String.format("I'm %s, %d yearsold",
            p.firstName(),
            p.age());
    }
}

Answer 10

It's the same reason that they don't change anything else in Java - backwards-compatibility.

Answer 11

- Is it because it's not deemed important enough when compared to other possible improvements?

That's my guess.

- Are there technical (e.g. JVM-related) limitations?

No

- Is it a matter of politics? (e.g. "I've been coding in Java for 50 years now and I say: we don't need no steenkin' properties!")

Most likely.

- Is it a case of bikeshedding?

Uh?

One of the main goals of Java was to keep the language simple.

From the: Wikipedia

Java suppresses several features [...] for classes in order to simplify the language and to prevent possible errors and anti-pattern design.

Answer 12

Here are a few little bits of logic that, for me, lead up to not liking properties in a language:

Some programming structures get used because they are there, even if they support bad programming practices.

Setters imply mutable objects. Something to use sparsely.

Good OO design you ask an object to do some business logic. Properties imply that you are asking it for data and manipulating the data yourself.

Although you CAN override the methods in setters and getters, few ever do; also a final public variable is EXACTLY the same as a getter. So if you don't have mutable objects, it's kind of a moot point.

If your variable has business logic associated with it, the logic should GENERALLY be in the class with the variable. IF it does not, why in the world is it a variable??? it should be "Data" and be in a data structure so it can be manipulated by generic code.

---

I believe Jon Skeet pointed out that C# has a new method for handling this kind of data, Data that should be compile-time typed but should not really be variables, but being that my world has very little interaction with the C# world, I'll just take his word that it's pretty cool.

Also, I fully accept that depending on your style and the code you interact with, you just HAVE to have a set/get situation every now and then. I still average one setter/getter every class or two, but not enough to make me feel that a new programming structure is justified.

And note that I have very different requirements for work and for home programming. For work where my code must interact with the code of 20 other people I believe the more structured and explicit, the better. At home Groovy/Ruby is fine, and properties would be great, etc.