[djsumdog]

Am I missing properties? Dear god it's 2016, with Java8, and we still don't have real, language-defined properties? I mean you can use Lombok (and if you're not, you should be!), but that's something that really need to be built into the language. C# has them, Python has them, Ruby has them .. even other JVM languages like Scala have them!

I'm really glad I get to do Scala development full time. Even with all the recent improvements to Java 8, I feel the future of Java isn't the language, but the JVM and all the other languages that run on top of it (Scala, Groovy, Clojure, JRuby, etc.)

[lacampbell]

I really don't understand why people love properties so much. Getters and setters are elements of bad style to me - like global variables or gotos. A language like Java (or indeed C#) - specifically designed for huge teams and enterprise programs - shouldn't provide syntax sugar for writing getters and setters.

[kentosi]

"I really don't understand why people love properties", followed by "Getters and setters are elements of bad style".

So you don't like either of the following:

  myObject.name = "Ben";
  myObject.setName("Ben");

What alternative would you suggest then?

[lacampbell]

Probably a rethink of the design. Why are you creating an object, then mutating its name from client code?

The whole point of an object is that client code shouldn't be concerned with such details as maintaining the state of each internal field. Try and think of an object as a single thing you send high level messages to you, instead of a struct, or a bag, or a hashtable.

[chrisseaton]

What would a high level message for changing the name of some object look like, if not setName(newName)?

[marc_omorain]

Calls to mutate state, such as changing the name field, should be rare. I don't see the value in adding syntactic sugar to make it easier to mutate state.

[carterehsmith]

"Calls to mutate state, such as changing the name field, should be rare."

Says who?

For example, there is a business requirement that we know the on-hand quantity of some item in the warehouse.

It's a busy warehouse, and we keep picking that item for delivery, and replenishing it from our suppliers.

So, the quantity of the item keeps mutating.

How do you propose to deal with the above? Tell the warehouse people that they should only do their thing "rarely"? Seriously.

[cygx]

Something like obj.rename(newName). This might seem like a trivial change, but the underlying idea is that we're no longer dealing with a setter only affecting one particular field, but an abstract message that may affect arbitrary internal state.

[lacampbell]

It would probably look exactly like setName(newName).

For me a better question is - why is the name being changed? What high level goal are you trying to accomplish that truly needs you to to directly mutate internal fields, after the object has already been created? Could the object - or system of objects - have been designed with a higher level interface, so that the outside world didn't have to concern itself with such things?

[carterehsmith]

Things change?

Consider a trivial to-do list. You can click on the 'completed' checkbox. So the 'completed' field has chaged.

Or, you can say ooops I mistyped the label. So you change the label.

Is there anything wrong with that?

[st3v3r]

Let's say I have an object representing a file in the file system, and I'm writing a file browser. I give the user the ability to rename the file.

[clusmore]

I agree that setter properties are often a code smell, but getter properties are nice for calculated fields. As a very simple example, consider the following (C#):

  class Circle
  {
    public Circle(int radius) { Radius = radius; }
    public int Radius { get; }
    public int Diameter => Radius * 2;
  }

[lacampbell]

Diameter is a nice example of a getter property. However you could change radius to simply

    public int Radius;

[wtetzner]

I think you mean

    public final int radius;

[pjmlp]

> Scala, Groovy, Clojure, JRuby, etc.

I am yet to work in a Java project where I am allowed to use any of them.

Regarding the properties I really don't get what is the big deal.

No one used to complain about C++ properties, that besides having to write accessors and mutator methods, one needs to declare them on the header files as well.

Or the first version of C# properties isn't much shorter than how it is done in Java, which is still required when extra logic needs to be implemented.

It is been a few years since I have done any Python, but don't do they require two separate functions that are then mapped to a property declaration?

[jjoonathan]

> isn't much shorter than how it is done in java

The savings in screen space and visual cortex neurons doesn't come from the one or two properties that need logic, it comes from the dozen avoided

    /**
     * Gets the foo
     * @return the foo
     */
    public Foo getFoo() {
        return foo;
    }

    /**
     * Sets the foo
     * @param foo
     */
    public void setFoo(final Foo foo) {
        this.foo = foo;
    }

[benjiweber]

Thing is you don't really need to write getters and setters in modern Java.

They're quite a smell that you have no encapsulation, plus mutable state.

I find myself either

- Writing object oriented code with higher level operations that operate on data internally without exposing it via getters and setters.

or

- Value types that take values in constructor and provide naming and additional behaviour on that data (proper Value Types support will really help with this.)

or

- Data pipelines dealing with n-tuples. For which you might be tempted to reach for getters/setters but I'd tend to either use off the shelf tuple types. i.e. tuple(A,B,C) or classes with public fields, or interfaces with static factory to create instances. I'd love better support for tuples with named attributes (Like new c# has)

Loads of getters/setters is something that the frameworks of the last decade encouraged people to do but aren't really a thing any more.

[fauigerzigerk]

Adding 8 comment lines doesn't help your argument. More importantly though, you need to consider the mental load of constantly thinking about and remembering whether something is a property or a method.

I used to be an advocate property syntax, but after seeing them used in C# and now in Swift I have completely changed my mind. It's an inconsistent mess that Java has avoided at the small price of some more lines of code (that are mostly auto generated and need no documentation)

[int_19h]

Can you clarify what's inconsistent about properties in C# (seeing how this is the most obvious counterpart), and how it doesn't apply to Java's properties-by-convention?

[fauigerzigerk]

In Java you can be reasonably sure that whenever you need something from an object you call a method of its class. That's one thing you rarely have to think about in practice. Yes there are exceptions (sometimes painfully inconsistent ones) where fields are accessed directly, but at least that gives you some performance guarantees. It's generally not a big concern.

In C# you do have to think about it all the time. Most types have both properties and methods and in many cases it's not obvious whether the author of that type had the same idea about whether or not something should be a property or a method as you do. Where you only have to remember a name in Java, you have to remember both a name and its syntactic category in C#. One more thing to keep in mind equals greater mental load.

In fact, the guidelines for choosing between one and the other include considerations that should be of no concern to the user of a public interface (https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100)....). If any of these implementation details change, the logical conclusion would be to change the public interface from property syntax to method syntax or vice versa. That's what I call inconsistent.

If you're saying that the choice between getX() and x() in Java is also somewhat inconsistent then you are absolutely right. It's just not a problem on the same scale as in C#.

[breischl]

I would argue that the distinction is actually a good thing. If you're working with a reasonably well-designed library, then the fact that something is a method instead of a property tells you it might be doing some serious (or just slow) work. Whereas in Java calling getX() might do just about anything.

And if the implementation of a C# property changes in any of the ways that would make it a method, that probably deserves to be surfaced as a breaking change in the API. That's a feature, not a bug. eg, I would certainly want to know if the implementation of a property was changed from a field access to a network call.

[int_19h]

There's no actual syntactic load in practice. You look at the documentation page (or, more often these days, at autocompletion list), and see all members. Whether they are properties or methods is readily indicated, and in case of autocompletion, it'll also insert the parentheses for you for methods.

Semantically, the difference between properties and methods is the same as the difference between data and behavior. Are you saying that it's not a useful distinction to have?

[pjmlp]

The worst case I tend to encounter across customer code is having properties with big bodies of several lines that should have been made proper methods in first place.

[hota_mazi]

And you forget the declaration of the field itself.

Compare with Kotlin:

    class MyFoo(val foo: Foo)

Done.

[usrusr]

A compiler switch that makes trivial comments on accessor methods a compile error, now that would be something I could support!

[pjmlp]

Javadoc plugin?

[electrum]

Those Javadoc comments are useless. If you have useful comments, they would take up the same space even if the language supported properties.

Now you're left with something that could be fit on three lines (the "final" for the parameter is also useless and can be removed):

    public Foo getFoo() { return foo; }

    public void setFoo(Foo foo) { this.foo = foo; }

Even if you don't write the actual source like that, a good editor like IntelliJ can automatically display them like that (code folding).

The C# version is about the same length:

    public Foo Foo {
        get { return foo; }
        set { foo = value; }
    }

Also, you don't have to write the get/set methods yourself. You hit a few keys and your editor generates them.

[int_19h]

The C# version was the same length 10 years ago. Now you would write:

  public Foo Foo { get; set; }

and get the backing field for free.

[pjmlp]

Now write that with validation on set.

[kentosi]

You could do this in Java, but therein lies the cultural problem: From my experience, the Java world is so accustomed to get/set method doing nothing other than getting and setting the value that any attempt to do more (validation included) is seen as "surprising" and is frowned upon in code reviews. I'd typically have to create a special "setWIthValidation" method to please people...

Bring in properties already.

[int_19h]

That'll be about as long as Java, sure. But most properties that are actually written in code don't need validation. In fact, most of them don't even have a setter. In C#, this means that I can do:

   public Foo Foo { get; }

or for a computed property:

   public int Foo => Bar + 1;

The real savings from property come when you use them, though - the extra pair of () doesn't feel like much, but when you start chaining properties, I find that not having () there significantly improves readability. Then, of course, Java also insists on `get` prefix by convention. So you have Java:

   foo.getBar().getBaz().blah()

vs C#:

   foo.Bar.Baz.Blah()

More importantly, the latter visually emphasizes the difference between accessing data and operating on it. You can see that "Bar" and "Baz" are data members, conceptually similar to "foo", whereas "blah()" is an operation.

[breischl]

So your argument is that because there are some uses that require boilerplate, therefore all uses should require at least that much boilerplate?

[josho]

> Regarding the properties I really don't get what is the big deal.

I used to feel the same as you, then I dabbled with Rails. I think the deal is that in Java there is a lot of noise in the code. So, developing feels like you need to do a lot of yak shaving before you get to actually work on what you intend to build.

As a result, properties on their own isn't a big deal, but it's one more thing to slow you down and make things a little less enjoyable.

[dmux]

Are people manually writing getters and setters? Every Java IDE I've used has the ability to generate them for you.

[kentosi]

I think that the point is that you shouldn't have to rely on an IDE in the first place.

[djsumdog]

Code generation is a design smell. You shouldn't need it, and it makes the code terrible and less readable. Use Lombok, not the IDE.

[agentgt]

When I see some one complaining code generation being design smell I gag a little at this hackneyed Fowler expression. I'm curios what do you think lambok does?

[nine_k]

It does code generation. What id does not is _source_ code generation. That is, you never see the code Lombok generates, never have to maintain it, and never have a chance to break it by editing. You can see it as a macro substitution.

OTOH IDE-generated code is "normal" source code, adding boilerplate to your "real" code, not tracking changes in it automatically, and perfectly breakable.

[st3v3r]

"Code generation is a design smell."

What do you think Lombok is doing?

[carterehsmith]

Properties are not a huge deal, I agree, but they sure are annoyance in Java (compared to e.g. C#).

That is, instead of one line of the code declaring the property, we end up with 10 lines doing the same thing, because we also need to declare getter and setter.

So, a realistic "POJO" that has 8 properties, will have 8 lines of code in C#, but 80 lines of code in Java.

Sure, your IDE will generate the getter and setter, but when you are reading the code, you have to check whether getter and setter are trivial, or perhaps they do something else, too.

It is quite common to get burned by a setter that someone made so that, after setting the value, it also does other shit like, hit Google Analytics, which is why everything is so slow.

The above problem is super easy to spot in 8 lines of code, but much harder to spot in 80 lines of monotonic, repeatable code, especially so when they are decorated with another 100 lines of code that is IDE-generated comments like 'Sets the foo'/'Gets the foo'.

My 5c.

[aardvark179]

Properties mean a lot of things to different people, and C#'s can do stuff that you don't expect so I would guess won't make it into Java as they tend to prioritise reading code over writing it. Having said that if you look at https://www.oracle.com/javaone/on-demand/index.html?bcid=513... about 30 minutes in you might see Brian talking about something that may be close enough to what most people want from properties to satisfy them.

[int_19h]

> Properties mean a lot of things to different people

Thing is, this is true whether your language offers syntactic sugar for them, or not. Properties already exist in Java, they just exist as a matter of convention and custom - but the expectations on how they behave are just as strong, and a misbehaving getter, say, is just as surprising and damaging.