Java method naming conventions: Too many getters

I personally don't use getters and setters whenever it's possible (meaning : I don't use any framework who needs it, like Struts for instance).

I prefer writing immutable objects (public final fields) when possible, otherwise I just use public fields : less boiler plate code, more productivity, less side effects. The original justification for get/set is encapsulation (make your objects as shy as possible), but in fact, I don't need it very often.

In Effective Java, Joshua Bloch makes this compelling recommendation :

Classes should be immutable unless there's a very good reason to make them mutable... If a class cannot be made immutable, limit its mutability as much as possible.

In the same book, he also says (but I don't want to copy the whole book here) :

The JavaBeans pattern has serious disadvantages.

I totally aggre with that, since JavaBeans were originally intended for a very narrow problem domain : manipulation of graphical components in an IDE. It is a bad practice to use one solution designed for solving another problem.

It comes from the JavaBeans naming conventions.

Part of the reason there's so many get* methods is that Java doesn't support "properties" a la .net/COM, and Java beans and such use functions getX and setX to replicate the functionality of a property called X. Some IDEs for Java take advantage of this to allow the setting and retrieval of properties.