# Code generating beans - mutable and immutable

DevFeed: [Code generating beans - mutable and immutable](<https://devfeed.tech/articles/code-generating-beans-mutable-and-immutable-21991.md>)

Original publisher: [Read original article](<http://blog.joda.org/2016/09/code-generating-beans.html>)

Author: Stephen Colebourne (noreply@blogger.com)

Published: 2016-09-26T01:36:00Z

Content type: opinion

Language: en

Sources: [Stephen Colebourne](<https://devfeed.tech/sources/stephen-colebourne.md>)

Topics: [Code generation](<https://devfeed.tech/topics/code-generation.md>), [Java](<https://devfeed.tech/topics/java.md>), [Data structures](<https://devfeed.tech/topics/data-structures.md>), [Code](<https://devfeed.tech/topics/code.md>), [ide](<https://devfeed.tech/topics/ide.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>)

Tags: [abstract-class](<https://devfeed.tech/tags/abstract-class.md>), [code](<https://devfeed.tech/tags/code.md>), [code-generation](<https://devfeed.tech/tags/code-generation.md>), [compilation](<https://devfeed.tech/tags/compilation.md>), [constructor](<https://devfeed.tech/tags/constructor.md>), [data-structure](<https://devfeed.tech/tags/data-structure.md>), [hashcode](<https://devfeed.tech/tags/hashcode.md>), [interface](<https://devfeed.tech/tags/interface.md>), [java](<https://devfeed.tech/tags/java.md>), [javaone](<https://devfeed.tech/tags/javaone.md>), [jodabeans](<https://devfeed.tech/tags/jodabeans.md>), [properties](<https://devfeed.tech/tags/properties.md>), [tostring](<https://devfeed.tech/tags/tostring.md>)

## AI overview

This article discusses Java bean code generation, arguing that immutable beans and data structures are preferable to mutable beans. It compares IDE generation with annotation processors such as AutoValue, Immutables, and VALJOGen, which generate implementations during compilation.

## Source excerpt

Java has long suffered from the pain of beans. To declare a simple data class takes far too much code. At JavaOne 2016, I talked about code generation options - see the slides. Code generation of mutable and immutable beans The Java ecosystem is massive. So many libraries releasd as open source and beyond, which naturally leads to the question as to how those libraries communicate. And it is the basic concept of beans that is the essential glue, despite the ancient specification. How do ORMs (Hibernate etc.), Serialization (Jackson etc.) and Bean Mappers (Dozer etc.) communicate? Via getters and setters. The essential features of beans have moved beyond the JavaBeans spec, and are sometimes referred to as POJOs. The features are: Mutable No-args constructor Getters and Setters equals() / hashCode() / toString() But writing these manually is slow, tedious and error-prone. Code generation should be able to help us here. But should we be using mutable beans in 2016? No, no, no! It is time to be writing immutable data structure (immutable beans). But the only practical way to do so is code generation, especially if you want to have builders. In my talk at JavaOne 2016, I considered various code generation approaches: IDE code generation This is fine as far as it goes, but while the code is likely to be correct immediately after generation, there is still no guarantee that the generated code will stay correct as the class is maintained over time. AutoValue, Immutables and VALJOGen These three projects - AutoValue, Immutables, VALJOGen - use annotation processors to generate code during compilation. The idea is simple - the developer writes an abstract class or interface, and the tool code generates the implementation at compile time. However, these tool all focus on immutable beans, not mutable (Immutables can generate a modifiable bean, but it doesn't match the JavaBeans spec, so many tools will reject it). On the up side, there is no chance to mess up the equals / hash