The document discusses the use of JavaBeans, including mutable and immutable beans, and various methods for creating them using different languages and tools like AutoValue, Immutables, Lombok, and Joda-Beans. It highlights the importance of beans in applications for tasks such as serialization and ORM mapping. Additionally, it compares the pros and cons of these tools, providing insights into best practices for developing JavaBeans efficiently.

1. Bean generation
Stop writing getters and setters
Stephen Colebourne, @jodastephen
Engineering Lead, OpenGamma
September 2016
http://blog.joda.org

2. Stephen Colebourne
● Java Champion, regular conference speaker
● Best known for date & time - Joda-Time and JSR-310
● More Joda projects - http://www.joda.org
● Major contributions in Apache Commons
● Blog - http://blog.joda.org
● Worked at OpenGamma for 6 years

3. Strata, from OpenGamma
● Open Source market risk library
● Valuation and risk calcs for finance
○ interest rate swap, FRA, CDS
● Great example of Java SE 8 coding style
http://strata.opengamma.io/

4. Introduction
⇒

5. Why use beans?
● Beans are used in most applications
● Common denominator between applications & libraries
● ORMs (Hibernate, JPA, etc.)
● Serialization (Binary, JSON, XML, etc.)
● Mappers/configuration (Spring, Dozer, etc.)

6. What is a bean?
● JavaBean specification v1.01, from 1997
● Focus on software components, COM/DCOM
● Manipulated visually in GUIs
● Java components within MS Word/Excel !!!
● References to floppy disks !!!

7. What is a bean?
● JavaBeans must extend java.awt.Component
● Created via standard factories
● No use of casts of instanceof checks
● Checked exceptions, not unchecked
● Communication via events
● Very specific rules around capitalization
● Use of BeanInfo and PropertyEditor

8. What is a bean?
"Bean" != JavaBean

9. What is a mutable bean?
● Each tool has subtly different definition
● Most agree on
○ no-args constructor
○ getters match getXxx()
○ setters match setXxx()
○ equals() / hashCode() / toString()

10. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Pattern for mutable bean
/** Represents a person. */
public class Person {
/** The forename of the person. */
private String forename;
/** The surname of the person. */
private String surname;
/** The birth date of the person. */
private LocalDate birthDate;

11. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Pattern for mutable bean
/** Creates an empty instance of Person. */
public Person() {}
/** Gets the forename of the person. */
public String getForename() { … }
/** Sets the forename of the person. */
public void setForename(String forename) { … }
// same for surname/birthDate

12. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Pattern for mutable bean
/** Compares this person to another. */
public boolean equals(Object obj) { … }
/** Returns a suitable hash code. */
public int hashCode() { … }
/** Returns a string summary of this object. */
public String toString() { … }

13. What is an immutable bean?
● "Beans" has traditionally implied mutability
● Many tools can't handle immutable beans
● No setters, may have "withers"
● Class must be final, with final fields
● Factory or builder instead of constructor

14. Why immutable?
● Thread-safe
● Java Memory Model guarantees
● No need to trust other methods not to modify
● State checked and valid on construction
● Nulls can be eliminated

15. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Pattern for immutable bean
/** Represents a person. */
public final class Person {
/** The forename of the person. */
private final String forename;
/** The surname of the person. */
private final String surname;
/** The birth date of the person. */
private final LocalDate birthDate;

16. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Pattern for immutable bean
/** Obtains an instance of Person. */
public Person of(
String surname, String forename, LocalDate date) { … }
/** Gets the forename of the person. */
public String getForename() { … }
/** Returns a copy with the specified forename. */
public Person withForename(String forename) { … }
// same for surname/birthDate

17. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Pattern for immutable bean
/** Compares this person to another. */
public boolean equals(Object obj) { … }
/** Returns a suitable hash code. */
public int hashCode() { … }
/** Returns a string summary of this object. */
public String toString() { … }

18. Pattern for immutable bean
● May prefer to have a builder instead of a factory
// factory
Person person = Person.of("Stephen", "Colebourne", date);
// or builder
Person person = Person.builder()
.forename("Stephen")
.surname("Colebourne")
.birthDate(date)
.build();

19. What is a VALJO?
● POJO - Plain Old Java Object
● VALJO - Value Java Object
○ http://blog.joda.org/2014/03/valjos-value-java-objects.html
● No use of identity - equal is interchangeable
● Immutable bean with extra restrictions
○ may be suitable for conversion to value types in Java 10/11
○ logical state clearly defined and used in equals()/hashCode()
○ comparable consistent with equals()
○ constructor must be private
○ formal string representation that can be parsed

20. Creating beans

21. How to create beans
● Lots of different ways to create beans
● Best option depends on use case
● Mutable vs Immutable

22. Option 1 - Manual
● Write each bean manually
● Deathly boring
● Double deathly boring for immutable beans
● Error-prone
● Probably not tested or code reviewed

23. Option 2 - Another JVM language
● Kotlin code much shorter
// Kotlin immutable bean
data class Person(
val forename: String,
val surname: String,
val birthDate: LocalDate)

24. Option 2 - Another JVM language
● Groovy code much shorter
// Groovy mutable bean
class Customer {
String forename
String surname
LocalDate birthDate

25. Option 3 - Language change
● New language feature in Java
● Perhaps like Kotlin/Groovy
● Doesn't help us now
● Likely to be restrictive

26. Option 4 - IDE generation
● Eclipse / IntelliJ / NetBeans can generate the code
○ Eclipse uses Ctrl+Alt+S followed by R / O / H / S
○ IntelliJ uses Alt+Insert
● One time generation, doesn't handle change
● Can you express field is not null?
● Can you generate immutable builders?
● Still not tested or code reviewed

27. Option 5 - Use a tool
● AutoValue
● Immutables
● Lombok
● Joda-Beans
● (VALJOGen)
● (POJOmatic)

28. AutoValue

29. AutoValue
● Annotation processor
● Open Source, from Google
○ https://github.com/google/auto/tree/master/value

30. Annotation processing
● Additional step during compilation
● Compiler calls annotation processor
● Processor generates additional files
● If generated file is a .java file then it is compiled

31. Annotation processing
Person
(abstract)
PersonImpl
(concrete)
Compilation finds
annotations and
code generates
You write
abstract class

32. Annotation processing
● Maven
○ just add the dependency
● Eclipse with Maven
○ install m2e-apt plugin
○ turn it on in the preferences
● IntelliJ with Maven
○ turn it on in the preferences

33. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
AutoValue: your code
@AutoValue
public abstract class Person {
public static Person of(String name, LocalDate date) {
return new AutoValue_Person(name, date);
}
public abstract String getName();
public abstract LocalDate getBirthDate();
}

34. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
AutoValue: generated
@Generated("com.google.auto.value.processor.AutoValueProcessor")
final class AutoValue_Person extends Person {
private final String name;
private final LocalDate birthDate;
// constructor, getters, equals, hashCode, toString

35. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
AutoValue builder: your code
@AutoValue
public abstract class Person {
public static Builder builder() {
return new AutoValue_Person.Builder();
}
@AutoValue.Builder
public static abstract class Builder {
public abstract Builder name(String name);
public abstract Builder birthDate(LocalDate date);
public abstract Person build();
}
public abstract Builder toBuilder();

36. AutoValue options
● Handles name() or getName() convention
● Can override (underride) equals/hashCode/toString
● Can add any other method
● Can change fields to nullable using @Nullable
● Supports memoized fields
● Builder can have sub-builders for collections
● Pattern to handle builder validation
● Extensions API, but undocumented

37. AutoValue pros/cons
● Callers use Person like a normal bean
○ but they can see class is abstract
● Generated code is package scoped
○ you must write outline builder and/or static factory method
○ quite a lot of code still to write
● Simple, does sensible thing for most use cases
○ not that many options
● Only for immutable beans

38. Immutables

39. Immutables
● Annotation processor
● Open Source
○ https://immutables.github.io/
● Reacts to use Guava if available

40. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Immutables: your code
@Value.Immutable
public interface Person {
String getName();
LocalDate getBirthDate();
}

41. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Immutables: generated
@SuppressWarnings("all")
@Generated({"Immutables.generator", "ImmutablePerson"})
public final class ImmutablePerson implements Person {
private final String name;
private final LocalDate birthDate;
private ImmutablePerson(String name, LocalDate birthDate) {
this.name = name;
this.birthDate = birthDate;
}
// getters, withers, equals, hashCode, toString, builder

42. Immutables options
● Can generate from abstract class or interface
● Handles name() or getName() convention
● Can override (underride) equals/hashCode/toString
● Can add any other method
● Pre-computed hash code
● Instance interning
● and lots more!

43. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Immutables: hide implementation
@Value.Immutable
@Value.Style(visibility = PACKAGE)
public abstract class Person extends WithPerson {
public String getName();
public LocalDate getBirthDate();
public static class Builder
implements ImmutablePerson.Builder {}
}

44. Immutables pros/cons
● Many options and ways to generate
○ takes time to choose best option
● Callers see and use generated class (by default)
○ hiding generated class possible if you write more code
● Mutable beans supported
○ more like builders, do not follow JavaBeans spec

45. Lombok

46. Lombok
● Internal APIs
● Open Source
○ https://projectlombok.org/
● Uses agents and annotation processors
● Works best with Eclipse, but requires installing

47. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Lombok: your code - mutable
@Data
public class Person {
private String name;
private LocalDate birthDate;
}

48. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Lombok: generated- mutable
@Data
public class Person {
private String name;
private LocalDate birthDate;
// constructor, getters, setters, equals, hashCode, toString
}

49. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Lombok: your code - immutable
@Value
public class Person {
private String name;
private LocalDate birthDate;
}

50. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Lombok: generated - immutable
@Value
public final class Person {
private final String name;
private final LocalDate birthDate;
// constructor, getters, equals, hashCode, toString, builder
}

51. Lombok options
● Over 15 annotations and tweaks
● Use other annotations for more control
● Can add any other method

52. Lombok pros/cons
● No second class, proper immutable bean
○ resulting bean is exactly the same as manually written
● Works best with Maven and Eclipse
○ installation in Eclipse not via a standard plugin
● Uses internal API hackery
○ higher risk option
● Generated code is invisible
○ cannot step in when debugging
○ can "delombok" to code generated code

53. Joda-Beans

54. Joda-Beans
● Same-file regenerator
● Open Source, by me @jodastephen
○ http://www.joda.org/joda-beans/
● Adds autogenerated block to your code
● Generation using Maven/Gradle, on-save in Eclipse

55. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Joda-Beans: your code - mutable
@BeanDefinition
public class Person implements Bean {
@PropertyDefinition
private String name;
@PropertyDefinition
private LocalDate birthDate;
}

56. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Joda-Beans: generated - mutable
@BeanDefinition
public class Person implements Bean {
@PropertyDefinition
private String name;
@PropertyDefinition
private LocalDate birthDate;
// ---- AUTOGENERATED START ----
// getters, setters, equals, hashCode, toString, properties
// ----- AUTOGENERATED END -----
}

57. Properties
● C# and most other languages have properties
● Higher level than a field
● Bean is a set of properties
● Can list, get and set properties
○ like reflection
● Very useful abstraction for frameworks

58. Joda-Beans properties
● Bean provides abstraction for properties
● MetaBean acts like Class
● Can loop over MetaProperty for each property
○ meta bean acts as a hash-map of property name to property
○ no reflection
● BeanBuilder allows a bean to be created
○ this allows immutable beans to be created one property at a time

59. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Joda-Beans: your code immutable
@BeanDefinition
public class Person implements ImmutableBean {
@PropertyDefinition(validate = "notNull")
private String name;
@PropertyDefinition(validate = "notNull")
private LocalDate birthDate;
}

60. // Java 7
List<Person> people = loadPeople();
Collections.sort(people, new Comparator<Person>() {
@Override
public int compare(Person p1, Person p2) {
return p1.name.compareTo(p2.name);
}
});
Joda-Beans: generated immutable
@BeanDefinition
public class Person implements ImmutableBean {
@PropertyDefinition(validate = "notNull")
private String name;
@PropertyDefinition(validate = "notNull")
private LocalDate birthDate;
// ---- AUTOGENERATED START ----
// getters, equals, hashCode, toString, properties, builder
// ----- AUTOGENERATED END -----
}

61. Joda-Beans options
● Annotations allow field-level and bean-level control
● Control scope/style for getters/setters
● Supports pragmatic optional usage
● Can add any validation code
● Defaults/cross-validation for immutable bean builders
● Can default one property from another in builder
● Can fully override constructor

62. Joda-Beans pros/cons
● No second class, proper immutable bean
○ resulting bean is same as manually written
● Adds abstraction for properties without reflection
○ key reason to use Joda-Beans, but requires runtime dependency
● Built in XML, JSON, Binary serialization
● Generated code is visible for debugging
○ more code to checkin, but easy to ignore in review
○ proper Javadoc
● Plugin for Maven, Gradle and Eclipse with M2E
○ anyone want to volunteer to write an IntelliJ one?

63. Comparisons

64. Comparisons
● Annotation processor
○ AutoValue
○ Immutables
● Internal APIs
○ Lombok
● Same file regenerator
○ Joda-Beans

65. Comparisons
● All can generate a lot of useful code
○ getters, factories, builders, equals, hashCode, toString
● Some can generate mutable beans
● Only Joda-Beans generates C# style properties
● Each project has a different trade-off

66. Same class vs Generated class
● Same class (Joda-Beans, Lombok)
○ your code involves writing fields
○ caller sees concrete class
○ properly immutable
● Generated class (AutoValue, Immutables)
○ your code involves writing methods (more code)
○ caller sees abstract class or interface
○ is it really immutable?
○ IDE rename class typically breaks code

67. Collections
● Immutable beans should use Guava ImmutableList
● Builder needs to take List and convert internally
● All except Lombok do this correctly

68. Installation requirements
● AutoValue & Immutables use annotation processor
○ must be configured in IDE, extra plugin for Eclipse
● Lombok uses internal API hackery
○ requires specific Eclipse installation
● Joda-Beans runs as separate code regenerator
○ for Eclipse, just needs standard M2E

69. AutoValue vs Immutables
● AutoValue
○ you write abstract class
○ generated class is package-scoped
○ cannot generate static factory
○ must write builder outline manually
● Immutables
○ you write interface or abstract class
○ generated class is public (can be made private or package-scoped)
○ static factory and builder in generated class
○ lots of flexibility

70. Valid on checkout
● AutoValue, Immutables, Lombok
○ code invalid in IDE on checkout unless configured
○ only your code checked in
● Joda-Beans
○ code valid in IDE on checkout, even if not configured
○ your code and generated code checked in

71. Evaluate yourself
● GitHub project with everything setup for comparison
○ https://github.com/jodastephen/compare-beangen
● Includes 4 tools discussed
○ plus VALJOGen, POJOmatic, Eclipse wizards and IntelliJ wizards
● Good project to play with each tool

72. Summary
✯

73. Summary
● All four tools have their sweet spot and trade off
○ AutoValue - simplicity, abstract class
○ Immutables - comprehensive, abstract class or interface
○ Lombok - almost a language extension, hacky implementation
○ Joda-Beans - C# style properties, runtime dependency

74. Summary - personal view
● Use Joda-Beans if you like properties
○ Code should be valid on checkout
○ Immutable beans should be final
○ Want C# style properties
○ Hence I wrote and use Joda-Beans
● Otherwise, use Immutables
@jodastephen
http://blog.joda.org