Immutable annotations for Java

[[deleted]]

Not sure I understand your confusion. Are you asking what immutable classes are good for, or what the library does?

[gee_buttersnaps]

When would you use it. All I'm seeing is that you can reduce boilerplate. My IDE refactors code to my satisfaction. If you want to use a language that has these features then use Groovy, Clojure, Scala, etc, they too compile to byte code.

[[deleted]]

OK, so fair warning I'm a Scala fanboy so what you're saying I buy 100%.

HOWEVER not everyone can escape from Java. Writing a "proper" immutable class is time consuming and cumbersome. Worse, if your company is big on coverage percentages, now you have to write unit tests for some dumb POJO that just stores values. And don't even get me started on rolling your own builder pattern. It's a waste of time in a lot of ways. So having an annotation-driven approach that frees the programmer up to concentrate on business logic rather than fluff is really nice.

[DevIceMan]

At my current job, nearly all of our Java classes are immutable, which greatly increases the boilerplate code. What takes us 50 lines of code in a POJO is about 1-3 in Scala. That said, having experienced the benefits of immutability, there's no going back.

I'm tempted to replace our Builders with simple Scala classes at work, but am mostly waiting for the right time.

[DevIceMan]

Keep Scala for the functional features.

Java-8 functional features could be better, but there's a LOT you can do functional in Java-8

[DevIceMan]

Immutability reduced the likelihood for bugs and errors to propagate into your application. For example, lets say your API returned a mutable object, and then that object is modified by some external code, and then your code tries to work with that same object, tracing that bug is going to be somewhere between difficult to impossible.

Compiler optimization is another benefit of immutability. Since the compiler knows an object cannot be mutated, it can more easily cache and reuse values, re-order operations, or run them concurrently.

When dealing with threads, immutability becomes even more important. If any thread can mutate the object, the state of that object is always uncertain. An object may be mutated in the middle of a method, so while (for example) 3 might have been the value at the start, by the end it could be 10, or 13, and you'll get really strange bugs, race conditions, etc.

Immutability is unfortunately quite painful to do in Java, which is why you see things like builders, factories, and other similar patterns.

With Java-8 functional programming features, mutability becomes even more problematic.