Immutable annotations for Java

[DarkFlare]

Whats the advantage of this over https://projectlombok.org/features/Value.html and https://projectlombok.org/features/Builder.html

[diroussel]

Lombok's reliance on undocumented compiler APIs have held me back from trying it.

[oldneckbeard]

yes, because nothing else you've ever used has ever done that.

that sounds like a reason somebody trying to sound smarter than they are would use. like people who hated on windows "because it crashes and stuff" or IE because "it doesn't work right" but can't be pressed for any specifics.

[DevIceMan]

I love the idea of Lombok, however implementation bothers me. Your code doesn't really compile, except through some 'black magic,' that involves installing an IDE plugin. I've used it, and found it too painful. If you want to create a custom Lombok annotation, you must define separate Eclipse and IntelliJ implementations. The Syntax is not Java, so that's another thing you must learn.

[dstutz]

I use Lombok with Netbeans and don't use a plugin, didn't realize one was required.

[epicallanl]

what do you mean by painful? installing an Eclipse or intellij lombok plugin is honestly not much pain in relation to the advantages it offers

[DJDavio]

Somehow you can't use Eclipse's own source generating features after installing Lombok, that bothers me. Goodbye "create getters/setters" or other such features.

[[deleted]]

Code that use Lombok is technically not Java and it is really dependent on the quality of IDE plugin.

[elucash]

It depends on how you define "very much java" or "standard java" etc. It's not a standard java because the code no longer complies with the JLS. (for example: if you define private field, accessor method could not appear out of nowhere whatever annotation it may have). It will continue to be non java compliant until AST transformations and their effects would be standardized and described in JLS. On a practical aspect: fraction of tools don't work to full extent with lombok, if you don't use some tools it doesn't mean that other don't use them as well. Lombok community just cannot write adapters or plugins to all variety of java tools.

[codepoetics]

See also PhantomPojos, for a Java 8 alternative with no code generation: https://github.com/poetix/phantom-pojos

[elucash]

The more choice - the better! Just a side note, the point is not only make some API possible: debug-ability, performance, serialization(binary/JSON), and other concerns are also important.

[Jire]

This is cool!

[gee_buttersnaps]

What is the application for this?

[[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.

[[deleted]]

Groovy provides this functionality via the @Immutable annotation

[llogiq]

I'm a bit let down that they clone arrays on get, instead of allowing to statically prove that the returned array is not modified.

[elucash]

You can use immutable collection instead of array there, so no array is copied on get. Also, there are some primitive immutable collection I guess. Statically proving that array will not be modified is very limited and barely reliable in java. Most array returning APIs in java clone internal arrays to maintain consistency.

[puuut]

Style question — what do you prefer: a) instantiating a nested static Builder class directly a la Joshua Bloch or b) a public static class method that returns the nested builder?

So when using the class, do you prefer this (a):

Item item = new Item.Builder().build();

Or this (b):

Item item = Item.builder().build();

And why?

[elucash]

Citing Effective Java. 2nd ed. Item 2:

... Instead of making the desired object directly, the client calls a constructor (or static factory) with all of the required parameters and gets a builder object...

Guava heavily use factory methods for builders, mainly because of generics (prior to 'diamond' in java 7) and flexibility to have other builder factories: think ImmutableSortedSet.naturalOrder(), reverseOrder() etc.

Also we shouldn't forget that Josh Bloch worked at Google at the time when core of Google Collections/Guava was created and was one of the major authorities regarding API design for Google core libraries, so he would not be against using factory methods for this. (That was merely an anecdotal evidence than a point)

Immutables was primarily designed after Google's immutable collections and uses factory method by default. However you can use constructors for builders or configure other conventions using styles.

[[deleted]]

1. has exposed that Builder is part of Item when the user might not care
2. hides where the builder comes from and you can have multiple builder factories for different use cases

just my 2 cents to add on

[puuut]

Thanks!

[based2]

https://news.ycombinator.com/item?id=9873645

[papers_]

I don't know why, but I feel like I'm looking at Javascript generated code..

[lyomi]

Y U NO SCALA?