Are Java Beans as data storage classes bad design?

Question

Usually JavaPractices.com is a good site with good idea\'s, but this one troubles me: JavaBeans are bad.

The article cites several reasons, mainly that the term JavaBea

Answer 1

The article's intentions are well-meant, but in practice avoiding beans and setters is hard to uphold. For example, having frameworks use constructors is not possible in many cases since names are usually the identifying feature, and method/constructor parameter names are not maintained in the .class file. (Although there is at least one library to work around this.)

Setters are the next best thing - not as "pure" OO, but a huge convenience over constructors and work well in practice.

Whem tests start failing because of "bad" java beans, then I'll reconsider it cause for concern. But I've not seen that so far. The only time I'd say they are probably inappropriate is having shared beans in multithreaded code, since synchronizing the shared mutable state is tricky. Steer clear of that and beans are just fine.