Thank you for reading the post and adding your comments and feedback.
As mentioned in the post, this is a comparison of some of the three libraries' features, not an extensive review of every single feature.
In this article, we will compare some of the features of the Immutables.org library, Google AutoValue, and Project Lombok:
The particular set of evaluated features is based on the features that I consider essential for my use cases and are also defined at the beginning of the post.
Answering your question below:
If I don't want a builder? If my class has 3 attributes I don't really need a builder. How do I do that with the others? Will still be the same amount of boiler plate?
Immutables is even more flexible than Lombok in that case, allowing you to choose between a simple constructor with the parameters, but also a static factory method
About "helper for copying": an builder in Lombok creates a toBuilder method that allows you to make a builder with all values, change the ones you want and rebuild the object.
Good catch, Even when I do not evaluate that in the comparison, I'll remove the java comment in the lombok example.
Having an abstract class/interface defining your model, how these play together with jackson or hibernate where you have to annotate your class, how does it work?
For Hibernate/JPA, I do not use these libraries, IIRC the JPA standard requires JavaBeans mutable objects. But I do use them in particular for De/Serialization with Jackson, Jsonb, Gson, etc. and those play well with Interfaces and abstract classes.
What about if my fields are made of mutable fields, will Immutable still be immutable by default?
Yes, and that is one of the critical aspects of the library, AutoValue and Lombok generate shallowly immutable classes.
There are a lot of additional features in the Immutables library that I consider useful. Lombok and AutoValue are not providing those, but I agree with the fact that it depends on the need and uses cases.
The three libraries work pretty well, and if you don't need any additional features from the immutables library, AutoValue and Lombok are also valid options.
Its some time now, but maybe it still helps. The copy-function of lombok is @With, which creates a copy with one property changed.
For your example it might be something like myModel1.withMyString("other string")
which will create a copy of myModel1 with the changed myString value.
Thats what I also like about lombok, that you can use just the parts you need. Immutable is hard to use for legacy code, since you need to adapt all at once, while lombok leaves you with the chance to enhance classes with just the stuff you need. Copy a class? Add @With to it. Want a builder? Add @Builder to a class. Get rid of existing getters and setters? Just add @Getter and/or @Setter to it and delete whats already there.
With lombok you could still generate code for JPA entities, since you can chose what you want to use, e.g. getters, setters, constructors, etc. Of cause there are pitfalls to watch out for, but it is usable, since it doesn't turn it immutable automatically.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Canem,
Thank you for reading the post and adding your comments and feedback.
As mentioned in the post, this is a comparison of some of the three libraries' features, not an extensive review of every single feature.
The particular set of evaluated features is based on the features that I consider essential for my use cases and are also defined at the beginning of the post.
Answering your question below:
Immutables is even more flexible than Lombok in that case, allowing you to choose between a simple constructor with the parameters, but also a static factory method
Good catch, Even when I do not evaluate that in the comparison, I'll remove the java comment in the lombok example.
For Hibernate/JPA, I do not use these libraries, IIRC the JPA standard requires JavaBeans mutable objects. But I do use them in particular for De/Serialization with Jackson, Jsonb, Gson, etc. and those play well with Interfaces and abstract classes.
Yes, and that is one of the critical aspects of the library, AutoValue and Lombok generate shallowly immutable classes.
There are a lot of additional features in the Immutables library that I consider useful. Lombok and AutoValue are not providing those, but I agree with the fact that it depends on the need and uses cases.
The three libraries work pretty well, and if you don't need any additional features from the immutables library, AutoValue and Lombok are also valid options.
I just checked the Lombok generated code and I cannot see the utility method for copying/cloning:
Can you point me to an example or documentation around that?
Its some time now, but maybe it still helps. The copy-function of lombok is @With, which creates a copy with one property changed.
For your example it might be something like
myModel1.withMyString("other string")which will create a copy of
myModel1with the changedmyStringvalue.Thats what I also like about lombok, that you can use just the parts you need. Immutable is hard to use for legacy code, since you need to adapt all at once, while lombok leaves you with the chance to enhance classes with just the stuff you need. Copy a class? Add
@Withto it. Want a builder? Add@Builderto a class. Get rid of existing getters and setters? Just add@Getterand/or@Setterto it and delete whats already there.With lombok you could still generate code for JPA entities, since you can chose what you want to use, e.g. getters, setters, constructors, etc. Of cause there are pitfalls to watch out for, but it is usable, since it doesn't turn it immutable automatically.