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.

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)

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?

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#.

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.

The syntactical distinction makes us believe that there is a technical difference as well, but that is not the case. I find that misleading. If properties don't give us any technical guarantees, then a naming convention as in Java seems more appropriate to me.

And if you look at the guidelines I linked to, you'll see that the criteria that are supposed to tell us whether or not to use a property are much more subtle than making a network call vs accessing a field. Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?

I think disguising a function call as a direct variable access is much more problematic than calling a function that may or may not do more than return the value of a variable.

That said, I do realize that reasonable people can absolutely disagree on this issue.

I think disguising a simple function call as a variable access is sensible. But yes, people can disagree on this. I think the C# and Java designers are probably all smart people who thought about this a lot more than the two of us. :)

>>Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?

I just quickly re-read that page, but I don't see what you're referring to here.

I think it's a reference to this:

"The operation is a conversion, such as the Object.ToString method."

But this only pertains to the conversion of the object on which the property is defined. In other words, you should have methods like ToString or AsEnumerable, rather than properties like String or Enumerable, even though other rules would indicate property to be valid (idempotent, fast, no arguments). This rule is just an indication that properties represent conceptual attributes of an object; and the result of a conversion of an object to something else is not an attribute.

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?

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.

And you forget the declaration of the field itself.

Compare with Kotlin:

    class MyFoo(val foo: Foo)

Done.

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

Javadoc plugin?

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.

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.

Now write that with validation on set.

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.

I have been using Java since 1998 and hardly seen it.

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.

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

My argument is that I use Java since 1998 and C# since 2002, and I don't see that as a big issue.

There are bigger fishes to fry in Java than how properties are defined.