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

[pjmlp]

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

[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?

[pjmlp]

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.