JavaBeans - Quiz

Total: 5 questions

1. 

What are getters and setters in Java, and what are the JavaBeans naming conventions for them?

A getter is a public method that returns the value of a property; a setter is a public method that assigns a new value to it. Fields stay private, so the outside world reaches the state only through these methods. The name is built mechanically: take the property name, upper-case its first letter and prepend the prefix — name becomes getName() / setName(String). A getter takes no arguments and returns the property type; a setter returns void and takes exactly one argument of that same type, and the two types must match or the methods describe different properties. For a primitive boolean, is may replace get: isPrinted(). The pair defines a property, and the property name comes from the methods, not from the field.

2. 

When may a getter be named with the is prefix, and when is get the only option?

The JavaBeans specification allows isXxx() only when the property type is the primitive boolean: isEnabled() and getEnabled() are both valid there, and is is the idiomatic form that IDEs generate. For the Boolean wrapper only getArchived() works: java.beans.Introspector checks the return type and refuses to treat isArchived() returning Boolean as a read method. The practical consequence is that switching a field from boolean to Boolean to allow null silently removes the property from JSP/JSF expression language, JavaFX and Spring’s BeanWrapper, while Jackson is more forgiving and still accepts the is getter. The setter is named setEnabled(...) in both cases.

3. 

What makes a class a JavaBean, and why does it need a no-argument constructor?

A JavaBean is an ordinary class written to a convention: it is public, it has a public no-argument constructor, it keeps its state in private fields, it exposes that state through accessors that follow the naming rules, and by the specification it implements Serializable. The no-argument constructor exists because a framework instantiates the object reflectively, before any values are known: it calls new with no arguments and then fills the properties through setters. That is how Hibernate loads an entity and how Jackson deserialises JSON. As soon as you declare any constructor with parameters, the implicit default one disappears, and the failure shows up at runtime — InstantiationException from Hibernate, InvalidDefinitionException from Jackson. Declare it explicitly.

4. 

Why use getters and setters instead of simply making the field public?

A public field lets any caller put the object into an impossible state: with public radius and diam, the lines c.diam = 25; c.radius = 10; compile happily, because Java checks types, not meaning — and the bad value surfaces far from where it was written. A setter gives the class a single entry point for change, where it can validate the argument (throwing IllegalArgumentException on a negative radius) and recompute the related field (this.diam = radius * 2), which is what keeping the invariant means. A getter can likewise return a computed value or a defensive copy of a collection. Accessors also let you change the internals without touching calling code, and they are what makes the class usable by every JavaBeans-aware framework.

5. 

How does a record differ from a JavaBean, and when should you use each?

A record (Java 16+) generates private final fields, an all-arguments constructor, equals(), hashCode(), toString() and accessors for you. The accessors are named after the component with no prefix: person.fullName() rather than getFullName(), person.retired() rather than isRetired(). A record is immutable, has no setters, cannot have a no-argument constructor and is implicitly final. Strictly speaking it is therefore not a JavaBean, and anything built on java.beans.Introspector will find no properties on it; libraries updated for modern Java read records natively (Jackson since 2.12). Use records for DTOs, API responses, map keys and query results; use a classic bean where the object must change or where the framework demands the convention, above all for JPA and Hibernate entities.

Page 1 of 1