Immutable annotations for Java

http://immutables.github.io/

by javinpaul • 11 years ago

111 111 11 years ago

immutables.github.io

vbezhenar• 11 years ago

I tried to use annotation processors, but they were very IDE-unfriendly. According to the linked user guide it's better now. It's an interesting alternative to runtime bytecode generators or proxies.

stdbrouw• 11 years ago

"the most full-featured and mature tool in this field!", "With Immutables you can generate state of the art immutable object and builder."

A programming library with copy that looks like it's written by a marketeer – well, why not, I guess :-)

istvan__5• 11 years ago

Scala, is that you?? :)

mark2422• 11 years ago

val immutableString = "foo"

val immutableList = List(1, 2, 3)

val immutableMap = Map("foo" -> "bar")

var mutableString = "foo"

val mutableList = collection.mutable.List(1, 2, 3)

val mutableMap = collection.mutable.Map("foo" -> "bar")

RyanZAG• 11 years ago

No, this is not the same as the linked library. See here: http://stackoverflow.com/questions/6425165/statically-decide...

A similar example in Scala would be a class that has only 'val' types and no 'var' types, but read through the stackoverflow post to see the complexities.

iwwr• 11 years ago

What's the advantage of that as opposed to the 'standard' java way of doing immutable via 'final'?

atinoda-kestrel• 11 years ago

What's the advantage of that as opposed to the 'standard' java way of doing immutable via 'final'?

They're not really comparable.

This is code generation for builders, getters, etc. The idea is that you write less of the boilerplate that you'd write if you were rolling your own immutable POJOs.

Plus, unless I'm mis-reading the docs, it also handles certain collection types transparently. (Which obviously just throwing final on a property won't do.)

dikaiosune3• 11 years ago

My IDE (IntelliJ) does a lot of the writing of immutable POJOs for me :). The builders are a bit different for sure, but I don't see what's wrong with having an object that is only "mutable" in the construction phase.

quarterto• 11 years ago

These aren't immutable variables, they're immutable (i.e. persistent) data structures. You can't directly change the objects themselves; instead, "setters" create a new copy of the object.

dikaiosune3• 11 years ago

Perhaps I haven't had enough coffee yet, but could you explain how an immutable data structure is any different than an object whose class definition is all final? If you can't change any property of the object, wouldn't that be the same as what this annotation does?

To be clear, it seems like a nice boiler-plate avoidance technique (which Java could always use more of). But you're implying that there's some other significant underlying problem this solves and I don't see it.

_asummers3• 11 years ago

final in Java is only immutable references.

If I have:

private final Map<String, String> map = new HashMap<>();

I cannot say map = someOtherMap;, but I can still say map.put("key", "value");.

mbreese• 11 years ago

But you can wrap that Map with Collections.unmodifiableMap() for an immutable version.

miguelrochefort• 11 years ago

That's easy to do with Roslyn analyzers in C#.

CmonDev• 11 years ago

...or just waiting for C# 7.

carsongross• 11 years ago

It is fascinating to watch how both the java and javascript communities deal with the very different shortcomings of their respective programming languages.

It is also horrifying.

pron7• 11 years ago

It is fascinating to watch how people underestimate the cost of switching a programming language[1], and overestimate the benefits of a new one.

It is also horrifying.

[1]: Switching to another language on the same platform (JVM/JS) lowers the cost considerably, but it is still high.

istvan__5• 11 years ago

True, how about starting with the right language? :) I only write Clojure for both JVM and JS. Works like a charm. The only problem is when you need to work in a team and nobody does anything else but Java and JS.

banthar2• 11 years ago

This is just what programmers do. They all have irresistible urge to write their own meta language on top of what they are using.

C programmers do that with pre-processor. C++ programmers do that with templates and pre-processor. Java programmers do that with annotations.

pron7• 11 years ago

And then you have Lisp, that said, "fuck it, let's keep just the meta-language!" :)

cscurmudgeon5• 11 years ago

Fascinating. A programmer gives automation/abstraction to other domains, but yet uses tools which rob him(her) of that in their own work. Amazing that we had tools to solve most of these problems decades ago.

lemevi• 11 years ago

How does anything here rob the programmer of automation and abstraction? This adds something, it doesn't detract. It's an annotation you can use where you want. Your observation is specious.

ExpiredLink• 11 years ago

What "shortcomings"? What's "horrifying"? What real-wold use-cases does this "Immutables" library solve?

saryant3• 11 years ago

Immutable values can be safely shared across concurrent contexts.

unclebucknasty10• 11 years ago

Mutability isn't a shortcoming. It's a feature.

hyperpape4• 11 years ago

It's arguably a good feature, but I've come to the opinion that it's a bad default.

nmrm2• 11 years ago

Immutability isn't a shortcoming. It's a feature. :-)

catnaroek2• 11 years ago

Mutability is a feature, of course. Lots of useful algorithms need mutable data structures (e.g., dynamic programming, unification, etc.), and have no counterparts that rely solely on immutable ones.

However, totally unconstrained mutability is definitely a shortcoming. The ability to look at a type signature and be immediately able to tell what might or might not change is a big win for maintainability, especially in big projects.

By the way, constraining mutability doesn't require a purely functional language. The ML family (Standard ML, OCaml) allows all expressions to have arbitrary side effects (when evaluated), but all values other than reference cells are immutable.

hyperpape4• 11 years ago

This requires some explanation. What limitations are people working around here?

If you mean immutability, it's doesn't make sense to single out Java, since immutability was not significantly valued by any mainstream language until the 2000s (of course Haskell and various MLs existed before, but I'm talking about popular mindshare).

microtonal4• 11 years ago

Exactly. Object oriented languages of this generation even embraced mutability. The idea was that by having encapsulated/hidden data, methods could validate data and make sure that objects are always in an inconsistent state, hence making mutability safe. (Of course, the same can be achieved in C with opaque pointers.)

It was only until concurrency/parallelization/multi-core became more important that immutability-by-default gained much traction.

Nowadays, Java feels like the victim of the OO hype: mutable by default, static methods being the only escape hatch from OO, only predefined value types (yes, I know, Java 9). People always say that Go is like pre-generics Java, but it at least doesn't make two of the aforementioned mistakes.

royjacobs• 11 years ago

Hmm, this seems like a more heavyweight version of the immutable object support in Lombok [1], through the @Value and @Builder annotations. The website looks nicer than Lombok's, though :)

[1] https://projectlombok.org/features/index.html

fernandezpablo• 11 years ago

Features: [...] MongoDB Integration.

WAT

pron7• 11 years ago

BTW, Java now has pluggable type systems. One of them[1] adds true static, compile-time checks for immutability, and allows method to specify that they only receive immutable objects.

There are many others, including tainting types, linear types, physical unit types and more.

[1] http://types.cs.washington.edu/checker-framework/current/che...

CHY8722• 11 years ago

This kind of thing has worried me a little in the past (Lombok is a similar, but less focused project). My main concern is that this is not part of the pluggable annotations standard; it's an undocumented API provided by Sun javac. This means that it is prone to breakages, although I don't suppose it will particularly soon.

I know that Lombok had to change their code quite frequently to fit with different javac versions for a while, which means that this project becoming stale could be a problem.

nothrabannosir• 11 years ago

Could someone elaborate on the downvotes? I'm not the OP, but this sounds like a valid concern.

What am I missing?

drrb• 11 years ago

Perhaps because this project actually is using the Pluggable Annotation Processing API (e.g. https://github.com/immutables/immutables/blob/master/generat...).

bhickey• 11 years ago

If this is useful to you, check out the Mutability Detector (https://github.com/MutabilityDetector/MutabilityDetector).

guelo• 11 years ago

There's a very similar library from Google https://github.com/google/auto/blob/master/value/README.md

The one thing that tripped me up when I tried to use it is that you can't add other library annotations. For example, I couldn't change the json serialized field name using Gson's @SerializedName("custom_naming").

elucash3• 11 years ago

Maybe it's not what you looking for, but Immutables support binary [1] and JSON serialization [2] (Jackson or Gson) very well including field naming customization.

[1] http://immutables.github.io/immutable.html#serialization

[2] http://immutables.github.io/json.html

unclebucknasty10• 11 years ago

One of the most frequently trumpeted cases for immutability is WRT thread safety. Is it me, or does this need come up rarely in practice relative to the forcefulness of arguments to make everything immutable? I get that it depends on your project, etc. But, I'm talking overall.

There are other benefits to immutability, to be sure, but I appear to be the rare voice that finds the dictum to "make everything immutable" to be overstated. And, we seem to ignore the code bloat that comes along with it--builders and the like, as well as performance implications.

Of course we solve the challenges that mutability can introduce by lopping it off altogether, but at what cost? It's really not too far from solving problems that object misuse can introduce by getting rid of objects.

Replace all setters with builders, annotations, etc. Do not ever change an object's state. Ever! Run this Mutability Detector on your code to ensure you are not allowing something to be mutable. At all costs, kill those language features that allow object state to be changed!

At what point have we jumped the shark?

Maybe others believe in moderation as do I, and I just happen to be reading more of the forceful champions of immutability lately. But, they seem pretty loud and I have learned that edicts to never or always do something warrant great suspicion.

pbh1013• 11 years ago

Having worked in a couple different large Java projects, there are certainly tradeoffs to both sides: make too many things immutable and you will not end up in a happy place GC-wise. And add the requisite "it depends on the project" to the remainder of this comment :)

But if I were to start a project, I would start with immutability by default and go from there, chiefly because when you find yourself needing to add additional threads and share data, I consider the transition from mutable to immutable would be more difficult than the inverse.

Another perspective: mutability is a feature that can be used in certain contexts (and QUITE useful there) but nothing intrinsic to the feature (in Java, at least) enforces the contexts' prerequisites (i.e. thread-safe access), and thus it is easy to end up with runtime errors when the environment of your project shifts.

Immutability, OTOH, makes fewer contextual assumptions (or perhaps more tractable ones).

Said perhaps more pithily: when mutable-by-default, your resultant architecture will frequently hinge on mutability. If you instead start with immutability, the immutability will be less of a crutch than the mutability would have been.

unclebucknasty10• 11 years ago

nothing intrinsic to [mutability] (in Java, at least) enforces the contexts' prerequisites (i.e. thread-safe access)

I guess that's where I differ: To my mind the mutability construct is not supposed to provide this. Instead, enforcing thread-safety should involve the use of concurrency constructs.

And, that's the thing: OOP represents a stateful paradigm, in the sense that operations may be performed which mutate the state of an object. When we bring out the Hammer of Immutability to prevent potential concurrency issues, we are basically saying that we no longer want to be OO because of an unrelated requirement. Let's turn the objects into structs that can only be passed around and copied so we don't accidentally screw something up. This, rather than using the language's actual concurrency constructs to safely share data.

it is easy to end up with runtime errors when the environment of your project shifts

I can't remember when this has happened to me and I'm genuinely having trouble seeing the case. If I have an object which suddenly must be shared across another thread, then I generally cease to access it on the initial thread without some sort of synchronization.

So, I just don't see how you'd suddenly share data across threads under any model without very careful consideration of what's being shared and why. What operations will be performed with the data as input, what will be the output, and how/when do we communicate this to other threads?

Once you've done that analysis, then you have a blueprint for how to safely share data the right way.

microtonal4• 11 years ago

One of the most frequently trumpeted cases for immutability is WRT thread safety. Is it me, or does this need come up rarely in practice relative to the forcefulness of arguments to make everything immutable? I get that it depends on your project, etc. But, I'm talking overall.

Yes, I more than once had to fix code in an natural language processing library, because multi-threaded Jersey services led to either crashes or partial annotations literally ending up in the wrong request. In the cases where I had access to the code, I rewrote the classes to be immutable (all state is created and passed between method calls), which fixed it.

In one natural language parser that we couldn't patch, I had to create one full parser instance per thread (weighing in at ~1-2GB), because the class was mutable and did not use correct locking. (So, we ended up creating a couple of parsers at startup and putting them in an object pool.)

unclebucknasty10• 11 years ago

What you're describing are just plain bad coding practices by people who didn't understand concurrency. Proper locking and synchronization are the real fixes.

Again, that's not to say that immutability never has a place.

lmm3• 11 years ago

Some language features are just bad and should be removed entirely. Moderation is often the answer, but not always. https://xkcd.com/690/ .

Of course we solve the challenges that mutability can introduce by lopping it off altogether, but at what cost? It's really not too far from solving problems that object misuse can introduce by getting rid of objects.

At what cost then? I can point to specific scenarios where objects are useful and languages without them (e.g. Haskell) solve the problem less elegantly. Can you say the same for mutability? Have you got a specific business problem that you've solved with and without mutability and found that the mutability made it better?

(FWIW my position is: no unmanaged mutability beyond method scope. Local mutability is fine, but anything that crosses method boundaries should be explicitly managed using e.g. State)

unclebucknasty10• 11 years ago

FWIW if you advocate managed local mutability, then you also have folks who will tell you even that is evil. They would say internal mutability is still mutability. And, of course, it's true that you do also have to manage the same concurrency issues as with any mutability.

At what cost then?

If a language offers a construct for achieving a certain goal, and you opt to bypass that construct to create a parallel construct, then you are necessarily creating additional cost. But, it's actually worse than that because it goes beyond creation of parallel constructs: it also includes working to actively suppress the built-in language constructs.

And now we are creating immutability tools and new annotations, and running Mutability Detection, etc. as if mutability itself is a defect and stamping it out automatically improves code quality.

Have you got a specific business problem that you've solved with and without mutability

Yes. Every bit of code I've written before the age of Mutability-is-Pure-Evil. That code worked well without the additional code bloat, object copying, and performance penalties associated with defeating natural language constructs. No annotations. No builders everywhere. Just pure, clean, intuitive code whereby other developers were required to actually understand the design before using it.

You need to set a property? Then, set it. Don't construct a completely new object with a builder, just to update the zip code. In a multithreaded environment? Sorry, you need to understand concurrency issues. No amount of dumbing down objects is going to make up for your lack of understanding there.

Otherwise, let's stop calling immutability OOP. What people really want is to pass around a struct and have procedural code wrapped in other objects perform operations on it.

And, sorry. Moderation is key. Your use of "internal mutability" is actually a nod to moderation. When people find themselves repeating that something is always evil, it should trip a mental alarm. Sure, there are cases wherein immutability might be a reasonable way to solve a problem, but definitively stating that it is always the right approach is shark-jumping.

molyss2• 11 years ago

immutability is some clear gap in java, but I'm curious on what immutable has that checker framework [1] doesn't.

Looks like immutables transform the code in even more spaghettis.

Just looking at the "get started", it looks like the author voluntarily ignores all the java conventions around variables and getters/setters.

I might be wrong on this, but I suspect this framework heavily relies on introspection, which in my experience has always led to very hard to debug and explore code.

[1] http://types.cs.washington.edu/checker-framework/

elucash3• 11 years ago

> what immutable has that checker framework doesn't.

Functionality overlap is not particularly clear with Checker framework, in fact Immutable users often use Checker framework also. There are other tools like AutoValue, FreeBuilder, Lombok where I can see more similarities, but with important differences.

> Looks like immutables transform the code in even more spaghettis.

I would not agree, but you should look at real world codebases like [1] or [2] which use immutables.

> Just looking at the "get started", it looks like the author voluntarily ignores all the java conventions around variables and getters/setters.

Immutables support getters convention and you can configure any other convention you have, see [3].

> I might be wrong on this, but I suspect this framework heavily relies on introspection, which in my experience has always led to very hard to debug and explore code.

Immutables uses standard APIs of annotation processing. You can take a look at example generated code [4].

[1] https://github.com/facebook/buck

[2] https://github.com/glowroot/glowroot

[3] http://immutables.github.io/style.html

[4] http://immutables.github.io/generated.html

trask• 11 years ago

In my experience, Immutables really helps address some of Java's verbosity problem. Introducing it into my project cut 2,500 LOC (~10% of total code base), https://github.com/glowroot/glowroot/commit/7bdd3ff

hyperpape4• 11 years ago

So, I work at a company that uses Java for all its server-side technology (~2 million lines today), but we don't use annotations for code-gen. Can someone explain to me why I would want to do that instead of a hypothetical IDE feature/plugin?

jestar_jokin2• 11 years ago

Assuming you don't use annotations at all...

* DRY for cross-cutting concerns, like database transactions, logging, dependency injection, serialization, validation, web controllers/endpoints... basically, macros for Java.

* Less code means less chance for error - even if that code was generated at some point in the past, it will need to change in the future, and the future developer may do the change manually and might introduce mistakes. Using annotations can help enforce patterns.

hyperpape4• 11 years ago

We use annotations for some things, but they're either used at runtime for configuration or things like the lovely @Deprecated.

Niten• 11 years ago

Neat. It would be interesting to see a comparison between this and FreeBuilder (as well as AutoValue, though I think the differences there are more obvious).

I'm all for tools that make immutability easier; the lack of immutable objects is one of my main sources of cognitive dissonance when programming in Go instead of Java.

elucash3• 11 years ago

Maybe it would not be an exhaustive comparison, but there's (biased enough) feature matrix of Immutables, AutoValue, FreeBuilder: [1]

[1] http://immutables.github.io/CompareImmutables.pdf

EDIT

Immutable annotations for Java

Related Stories