Should all properties necessarily influence a JavaBean's hashcode() and equals() method?

Question

For a class to be a valid Javabean (according to the JavaBeans Specification ), should all of its properties be tested in its equals() method — and, accordingly, influence itshascode() implementation? Or some properties may be deliberately put aside?

For instance, a class Person with:

• id and name properties exposed in geters and setters
• a no-args constructor
• equals and hashcode methods that only take id into account

would qualify as a valid JavaBean?

Answer 1

Unlike other Java specifications the Java Beans specification is pretty vague. The idea is that a bean encapsulates some reusable functionality with focus on GUI. At the time of this specification there was an idea that developers sell separate components, eg some GUI elements.

A Java Bean is a reusable software component that can be manipulated visually in a builder tool.

The specification distinguishes Java beans from "normal" Java libraries:

Not all useful software modules should necessarily turn into beans. Beans are appropriate for software components that can be visually manipulated and customized to achieve some effect. Class libraries are an appropriate way of providing functionality that is useful to programmers, but which doesn't benefit from visual manipulation.

The specification does not define any requirements for hashCode() and equals() . It is up to you to implement or not to implement them. Also there are no requirements for constructors.

If your class provides some reusable functionality for GUI, you can call it Java Bean. If your class doesn't paint any elements in GUI, does not react on GUI events, then it is not a Java bean in the sense of this specification. But hey, how often you see applications that have GUI implemented in Java? :)

Many developers call Java bean any class that fulfills only some of requirements in this specification, mainly defined in the sections 8.1, 8.2, 8.3, 8.6, and ignore any other requirements like those about listeners and events. In this sense your class is a Java bean.

To hashCode() and equals(): It is up to you to use some properties in hashCode() and equals() . It depends on use case. For instance, your class has 4 attributes: ID, first name, last name and favorite drink. In one use case you may need to distinguish object instances by names only. Then you would use only first name and last name in hashCode() and equals() , and ignore ID and favorite drink. In some other use case you may consider this class as an assignment of drink to person, and you would need to include not only first and last name, but also favorite drink into hashCode() and equals() . In some other use case you may have a constraint that each combination of attributes is unique and to distinguish instances it is sufficient to use ID, so you would have only one attribute ID in hashCode() and equals() . Depending on your goals you would implement these methods differently.