11 ms·

Immutable annotations for Java

111 points by javinpaul 11y ago

vbezhenar 11y 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 11y 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__ 11y ago
Scala, is that you?? :)
- mark242 11y 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 11y ago
    No, this is not the same as the linked library. See here: http://stackoverflow.com/questions/6425165/statically-decide-if-a-scala-class-is-immutable 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.
    - mark242 11y ago
      case class Foo(bar: String, baz: String)
      - pron 11y ago
        Or in Kotlin: data class Foo(bar: String, baz: String)
iwwr 11y ago
What's the advantage of that as opposed to the 'standard' java way of doing immutable via 'final'?
- atinoda-kestrel 11y 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.)
  - dikaiosune 11y 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 11y 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.
  - dikaiosune 11y 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.
    - 11y ago
miguelrochefort 11y ago
That's easy to do with Roslyn analyzers in C#.
- CmonDev 11y ago
  ...or just waiting for C# 7.
deleted 11y ago
[deleted]
carsongross 11y 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.
- pron 11y 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__ 11y 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.
    - pron 11y ago
      My rule of thumb is, if you need to switch a primary production language more than once a decade[1], then you're picking them wrong. Personally, I've been using Java for over a decade, and a few years ago I added Clojure to the mix and expect it to serve me for over a decade, as well. I like them both and believe they both qualify as good picks. I'm also adding Kotlin now, too, mostly because its switching cost and added risk are practically zero. [1]: for reasons other than targeting a new platform
      - kcorbitt 11y ago
        Seconding Kotlin coming from Java. It takes maybe 2 days to learn everything in the language if you already know Java, and it fixes pretty much all the warts that bother me about Java (the big ones for me are immutable references, first-class/higher-order functions, and unnullable-by-default references. Type inference and string interpolations are handy as well). It also has a small enough runtime/stdlib (unlike Scala or Clojure, which I've also tried) to make it practical to use in environments where startup time matters, specifically Android.
royjacobs 11y 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 https://projectlombok.org/features/index.html
fernandezpablo 11y ago
Features: [...] MongoDB Integration. WAT
pron 11y 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/checker-framework-manual.html#javari-checker http://types.cs.washington.edu/checker-framework/current/che...
CHY872 11y 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 11y ago
  Could someone elaborate on the downvotes? I'm not the OP, but this sounds like a valid concern. What am I missing?
  - drrb 11y ago
    Perhaps because this project actually is using the Pluggable Annotation Processing API (e.g. https://github.com/immutables/immutables/blob/master/generator-processor/src/org/immutables/generator/processor/Processor.java https://github.com/immutables/immutables/blob/master/generat...).
    - CHY872 11y ago
      Yep, that's fair. I took another look, Lombok is only unsupported because it inserts methods into pre-existing classes; I misremembered the limitation on the pluggable annotations. My bad!
bhickey 11y ago
If this is useful to you, check out the Mutability Detector (https://github.com/MutabilityDetector/MutabilityDetector https://github.com/MutabilityDetector/MutabilityDetector).
guelo 11y ago
There's a very similar library from Google https://github.com/google/auto/blob/master/value/README.md 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").
- elucash 11y 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 http://immutables.github.io/immutable.html#serialization [2] http://immutables.github.io/json.html http://immutables.github.io/json.html
unclebucknasty 11y 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.
- pbh101 11y 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.
molyss 11y 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/ http://types.cs.washington.edu/checker-framework/
- elucash 11y 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 https://github.com/facebook/buck [2] https://github.com/glowroot/glowroot https://github.com/glowroot/glowroot [3] http://immutables.github.io/style.html http://immutables.github.io/style.html [4] http://immutables.github.io/generated.html http://immutables.github.io/generated.html
trask 11y 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 https://github.com/glowroot/glowroot/commit/7bdd3ff
hyperpape 11y 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_jokin 11y 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.
  - hyperpape 11y ago
    We use annotations for some things, but they're either used at runtime for configuration or things like the lovely @Deprecated.
    - jestar_jokin 11y ago
      Another advantage of using annotations to generate code at compile time, is that any (simple) errors get detected at compile time instead of runtime. So, potentially less tests you need to write.
Niten 11y 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.
- elucash 11y 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 http://immutables.github.io/CompareImmutables.pdf EDIT

111 points by javinpaul 11y 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 11y 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__ 11y ago

Scala, is that you?? :)

mark242 11y 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 11y ago
  No, this is not the same as the linked library. See here: http://stackoverflow.com/questions/6425165/statically-decide-if-a-scala-class-is-immutable 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.
  - mark242 11y ago
    case class Foo(bar: String, baz: String)
    - pron 11y ago
      Or in Kotlin: data class Foo(bar: String, baz: String)

iwwr 11y ago

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

atinoda-kestrel 11y 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.)
- dikaiosune 11y 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 11y 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.
- dikaiosune 11y 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.
  - 11y ago

miguelrochefort 11y ago

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

CmonDev 11y ago
...or just waiting for C# 7.

deleted 11y ago

[deleted]

carsongross 11y 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.

pron 11y 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__ 11y 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.
  - pron 11y ago
    My rule of thumb is, if you need to switch a primary production language more than once a decade[1], then you're picking them wrong. Personally, I've been using Java for over a decade, and a few years ago I added Clojure to the mix and expect it to serve me for over a decade, as well. I like them both and believe they both qualify as good picks. I'm also adding Kotlin now, too, mostly because its switching cost and added risk are practically zero. [1]: for reasons other than targeting a new platform
    - kcorbitt 11y ago
      Seconding Kotlin coming from Java. It takes maybe 2 days to learn everything in the language if you already know Java, and it fixes pretty much all the warts that bother me about Java (the big ones for me are immutable references, first-class/higher-order functions, and unnullable-by-default references. Type inference and string interpolations are handy as well). It also has a small enough runtime/stdlib (unlike Scala or Clojure, which I've also tried) to make it practical to use in environments where startup time matters, specifically Android.

royjacobs 11y 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 https://projectlombok.org/features/index.html

fernandezpablo 11y ago

Features: [...] MongoDB Integration. WAT

pron 11y 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/checker-framework-manual.html#javari-checker http://types.cs.washington.edu/checker-framework/current/che...

CHY872 11y 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 11y ago
Could someone elaborate on the downvotes? I'm not the OP, but this sounds like a valid concern. What am I missing?
- drrb 11y ago
  Perhaps because this project actually is using the Pluggable Annotation Processing API (e.g. https://github.com/immutables/immutables/blob/master/generator-processor/src/org/immutables/generator/processor/Processor.java https://github.com/immutables/immutables/blob/master/generat...).
  - CHY872 11y ago
    Yep, that's fair. I took another look, Lombok is only unsupported because it inserts methods into pre-existing classes; I misremembered the limitation on the pluggable annotations. My bad!

bhickey 11y ago

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

guelo 11y ago

There's a very similar library from Google https://github.com/google/auto/blob/master/value/README.md 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").

elucash 11y 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 http://immutables.github.io/immutable.html#serialization [2] http://immutables.github.io/json.html http://immutables.github.io/json.html

unclebucknasty 11y 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.

pbh101 11y 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.

molyss 11y 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/ http://types.cs.washington.edu/checker-framework/

elucash 11y 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 https://github.com/facebook/buck [2] https://github.com/glowroot/glowroot https://github.com/glowroot/glowroot [3] http://immutables.github.io/style.html http://immutables.github.io/style.html [4] http://immutables.github.io/generated.html http://immutables.github.io/generated.html

trask 11y 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 https://github.com/glowroot/glowroot/commit/7bdd3ff

hyperpape 11y 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_jokin 11y 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.
- hyperpape 11y ago
  We use annotations for some things, but they're either used at runtime for configuration or things like the lovely @Deprecated.
  - jestar_jokin 11y ago
    Another advantage of using annotations to generate code at compile time, is that any (simple) errors get detected at compile time instead of runtime. So, potentially less tests you need to write.

Niten 11y 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.

elucash 11y 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 http://immutables.github.io/CompareImmutables.pdf EDIT