2

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 its hascode() 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?

bruno
  • 2,213
  • 1
  • 19
  • 31
  • 2
    Certainly the general contracts for `equals` and `hashcode` allow ignoring fields. I don't think the JavaBeans spec would be different. – jaco0646 Sep 19 '19 at 18:13
  • Yes, it would be a valid bean. In fact, that’s usually how it should be. `equals` and `hashCode` should be based on the object’s conceptual identity. Rarely is it correct to base identity of every property of a bean. – VGR Sep 19 '19 at 18:34

1 Answers1

3

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, e.g. 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.

mentallurg
  • 4,967
  • 5
  • 28
  • 36
  • I like your answer in general, but I think you are misinterpreting 'can be visually manipulated' part. The fact that you can set properties in a visual editor ( which is the reason for standard naming - visual editor must be able to discover them) does not imply that the bean is gui element itself. If you squint, you can imagine wiring any other type of app in a visual editor. – Lesiak Sep 20 '19 at 04:53
  • 1) *does not imply that the bean is gui element itself* - correct. I didn't say that it is. I say following: *If your class provides some reusable functionality for GUI*. It doesn't have to be a button or a table. It can be for instance a controller. But in my opinion (may be I'm wrong) the whole specification was implicitly built around GUI. It explicitly separates Java beans from "normal" libraries. 2) You are right about property editor and property discovery. But when we have an object over a long time that you can work with and ca distinguish from other objects? Mainly in GUI. – mentallurg Sep 20 '19 at 21:19
  • I think we now agree – Lesiak Sep 21 '19 at 06:00
  • 1
    Future readers may also be interested in, [What is the difference between a JavaBean and a POJO?](https://stackoverflow.com/q/1394265/1371329) – jaco0646 Sep 22 '19 at 12:59