I find the readability is where Java's verbosity really hurts it. E.g. if you bring up the horribly verbose getters/setters in Java many people will respond that you can autogenerate them - which is true as far as it goes. But you can't "autoread" them, and if you have a thousand getters/setters of which ten provide different functionality to the standard field access, that makes the code very hard to read.
I don't find much validity to this argument that constantly comes up. Out of the box, you have two options and neither are bad... (1) Make your variable package/public/protected scope and refactor one day if you have to. (2) Use getters/setters, possibly with shorter names (if your fancy framework allows that) and more terse formatting.
Most coding standards don't like that, and if you can't autoformat your code then you have bigger problems. I do agree that some of the problems are cultural rather than inherent to the language, but even if we do that,
public class Potato {
private final int size;
public Potato(int size) { this.size = size; }
int size() { return size; }
}
makes poor reading in comparison to
class Potato(val size: Int)
(I didn't mean a thousand getters/setters in a single class, but across the codebase as a whole)
> I find the readability is where Java's verbosity really hurts it.
I'd agree, but on the JVM there are plenty of statically-typed languages with clean interop that permit more concise expressions than Java, so I don't see conciseness alone as a reason to go to a dynamic JVM language. (That said, Java is getting better at this over time, though its still, to me, a pretty big negative for Java.)
