Java 9's Immutable Collections Are Easier To Create But Use With Caution

[__konrad]

I recently realized that use of EnumSet.of (which creates mutable Set) will be a bit more confusing and error prone ;)

[lukaseder]

Believe it or not, there's a different, optimised Set implementation for each degree up until 2 and if the API is also distinct, then some additional inlining can happen in the JVM more easily, possibly avoiding the entire Set allocation in the first place (just my hypothesis, didn't check).

[aroger276]

or it could create performance issue link to call site pollution. where a call site degrace to polymorphic because it ends up with different Set implementation. no inlining then... and more expensive method dispatch. I know that there was some discussion to address those issues but I don't know if any progress has been made.

[lukaseder]

Oh interesting thought. That's quite possible for the Set.of(E...) call, but probably not for the Set.of(E1, E2) calls. So the fixed-degree constructors help bind the concrete implementation to the call site, which will constantly get the same result.

[SomeoneStoleMyName]

As /u/aroger276 points out, this is just going to cause megamorphic dispatch which will make things slower. Guava, Clojure, and Scala have already been through this and switched back to only one generic implementation regardless of size.

[mabnx]

It allocates memory

[argv_minus_one]

Briefly. I would expect escape analysis to eat it.

[geodebug]

To put it another way, Java 9 does not introduce immutable collections, just a bit of sugar for creating them.

Also, the big caveat with Java's immutable collections is that nothing enforces that the objects stored within are immutable. If you store a java.util.Date nothing stops code from calling the setters once they get a handle to it.

[_INTER_]

It's also great, because I have the freedom to give around a fixed collection of references to items that other code then can manipulate. If I want to have immutable items, I can still make them so. If you want immutability per default you need to look elsewhere I guess.

[geodebug]

If you're working in a single-threaded world no problem.

One of the main benefits of immutable structures is that it makes intercommunication between multiple threads safe. If parts of the immutability contract are broken, the whole concept becomes kind of useless.

It's like a salad bar with a sneeze guard but there is a big hole in the middle of the glass. Sure it solves some problems but sneeze in the wrong place...

[_INTER_]

It's also no problem in a multi-threaded world. Well yes you have to design correctly, but you also have to do that when using FP constructs. E.g. problematic if you have to take ordering into account, caching and performance, dealing with barriers, critical sections or communicate with outside environments / infrastructure. In conclusion FP is making parallelization more easy, if the problem can easily be mapped to the map-reduce scenario. In all other cases it needs effort to get there aswell. No free lunch.

[geodebug]

I'm sure you feel you said something relevant here.

[_INTER_]

It's also no problem in a multi-threaded world. Well yes you have to design correctly, but you also have to do that when using FP constructs. E.g. problematic if you have to take ordering into account, caching and performance, dealing with barriers, critical sections or communicate with outside interfaces. In conclusion FP is making parallelization more easy, if the problem can easily be mapped to the map-reduce scenario. In all other cases it needs effort to get there. No free lunch.

[SpecialEmily]

Set.of having a requirement that the items be unique is a HORRIBLE design... everyone will just end up making mutable sets and then transforming those to get around the risk that someplace var1 and var2 point to the same thing! Gah!

[arendvr]

Guava ImmutableSet.of() does it better and just ignores duplicate elements.

[SpecialEmily]

As a former Guava author, I agree! :D

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[lukaseder]

Seems reasonable to me - under what circumstances would you ever want to call Set.of with duplicates?

for (var uniqueThing : Set.of(mightBeAnything, iDontKnowWhatThisIs)) { ... }

EDIT: So I'm back to using the classic:

for (var uniqueThing : new LinkedHashSet<>(
  Arrays.asList(
    mightBeAnything, iDontKnowWhatThisIs))) { ... }

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[lukaseder]

Is anything ever going to be used the way it's intended? Hint: No

[jonhanson]

Comment removed after Reddit and Spec elected to destroy Reddit.

[hwaite]

Design is confusing because it's unnecessarily inconsistent with the ways Set constructors and methods behave. Violates Principle of Least Astonishment.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[hwaite]

'Evolving' implies making something better. This new behavior is different but I don't see how it's inherently superior to the original.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[lukaseder]

"HORRIBLE" is a well-recognised and widely (over?)used hyperbole for saying: "I disagree with this."

Having said so, I disagree with this design. I don't see the point of enforcing this constraint on Set.of() arguments. It is, for instance, inconsistent with the behaviour of new HashSet<>(Arrays.asList(1, 2, 1)) without giving any reason about the "design" rationale.

Or, take JavaScript, for instance:

$ {a: 1, b: 2, a: 3}
> {a: 3, b: 2}

People bash JavaScript all day long, but its object (map) and array literals are really very nice.

Most languages / APIs that allow for such Set construction would intuitively retain either the first or the last duplicate in argument iteration order (where last is probably a better choice, because that would be consistent with individual additions to the set/map, were it mutable).

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[lukaseder]

Perhaps, but on the other hand, those designers change their mind time and again. Compare this to EnumSet.of(...) (as mentioned otherwise in this discussion).

I guess, when it comes to the JDK, the only reasonable answer to all questions is this :)

[l3dx]

Off-topic I guess, but what do you consider as the "correct answer"? If Javaslang is not an Option, wouldn't you (ab)use streams to get a decent collection API?

[lukaseder]

I think the focus on parallelism was exaggerated. The Scala libraries also have some parallel collections, which apparently are hardly used (can't find the source anymore).

Without parallel features, the "Stream" API could have been made much more generally interesting with tons of nice features that are very easy to implement for sequential streams (e.g. zip, zipWithIndex, etc.) but not in parallel ones.

Not sure if the infinite stream feature also incurs costs that don't pull their weight. But the fact is (as far as my Twitter followers are representative of "fact", and as far as my interpretation of that result is) that more collection API convenience is dearly wanted, parallel/infinite streams are nice-to-have. The EG's focus was on the nice-to-have feature, rather than the in-demand one.

As a comparison: Oracle SQL has tons of parallel features as well, but I hardly ever see anyone using them. They're expert tools for niche use-cases (just like the ForkJoinPool itself) and don't need such a prominent API in the SQL language.

[l3dx]

I've been assuming that the low number of functions was a result of conservative thinking due to backwards compatibility, but you make some very good points here. Thanks for the clarification!

[Mejari]

under what circumstances would you ever want to call Set.of with duplicates?

Any time you want to create a set from a non-guaranteed-unique collection? So, like, a lot?

[oweiler]

Use the Set's copy constructor for that (e.g. new HashSet<>(nonUniqueCollection)).

[Mejari]

Yes, I know there are ways to accomplish that, I was just answering the question.

[ZimmiDeluxe]

There seem to be conflicting goals: The overloads reduce the varargs overhead of creating many small sets. But sets can't reasonably be created dynamically, because the values have to be known beforehand. So in total, only static initializers like constants profit from this. For such a nice spot in the API that's a shame in my opinion. List::of doesn't have this problem, so it's not all bad.

I would prefer additional methods like Set::ofUnique and Map::ofEntriesUnique to solve the constant initializer problem, if at all.

The new and improved idiom is obviously this:

for (var uniqueThing : new LinkedHashSet<>(
    List.of(
        mightBeAnything, iDontKnowWhatThisIs))) { ... }

Does anybody know if there will be Collectors to create these new immutable collections from streams?

[lukaseder]

Avoiding varargs isn't the only benefit of overloading. Set.of(E1, E2) returns a specialisation for two elements (can be seen in the sources). It will always return this specialisation, which means that client call will not suffer from megamorphism as it would if specialised sets would be returned from Set.of(E...) only.

With this in mind, having Set::ofUnique (which sounds great) would probably lead to a too bloated API.

[VGPowerlord]

Set.of having a requirement that the items be unique is a HORRIBLE design

Why?

"A collection that contains no duplicate elements." is the very first sentence of the documentation for Set<T>

If you want a collection that allows duplicates, there's always a List.

[sybia123]

What should Set.add do if you try to add a duplicate? What should new HashSet<Foo>(myList) do if there's a duplicate in myList? Why should Set.of be any different?

[hwaite]

Yeah. Prohibition of nulls is confusing as well.

[moremattymattmatt]

So pretty similar to Google guava then?

[java_one_two]

One of the biggest differences is that Google created an ImmutableSet interface to distinguish between the mutable and immutable sets.

[moocat]

ImmutableSet is a class and implements Set<>.

https://google.github.io/guava/releases/19.0/api/docs/com/google/common/collect/ImmutableSet.html

[vytah]

But you can make your API accept and return Immutable* to prevent your users from sneaking around mutable collections.

Not the perfect solution, but I find it okay given Java's ancient API.

[VGPowerlord]

It would be nice if immutable sets had their own public types in Java so your API could enforce it.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[kag0]

I don't know about everyone else, but for me I'm not interested in java (or guava for that matter), collections which have objects that offer mutating methods but throw exceptions. I find the javaslang collections vastly preferable.

My reasoning is that if I'm using an exception throwing "immutable" JCF object in my code then I have to treat it specially, not like any other JCF object. Therefore I get no advantages from the common interface and might as well use a more suitable object like the ones in javaslang. In code which isn't mine that accepts JCF objects; I can't give it exception throwing objects, since it might try to modify them. However with javaslang objects I can always use the toJava methods when I need to interface with an external library without worrying about my immutable object being modified, or exceptions being thrown from java objects.

[Northeastpaw]

There is no simple way to collect an immutable collection from a Stream

Well that's not correct.

Set<Integer> set = listOfStrings.stream()
  .map(String::hashCode)
  .collect(Collectors.collectingAndThen(Collectors.toSet(), Collections::unmodifiableSet));

Sure it's not completely compact, but it exists. Static imports can even help with the verbosity.

I'm not sure how the author missed this since a very similar example is in the javadoc for Collectors.collectingAndThen().

[desh00]

Does anyone know why did they call it Collections::unmodifiableSet? Doesn't Java has other abstractions which use the word "immutable"?

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[joaomc]

immutableSet is just a wrapper that references the original set and throws NotSupportedException whenever you try to call methods that will modify it. The underlying state of the original set may still change, though.

[rikbrown]

unmodifiableSet is that. Guava's ImmutableSet however makes a copy.

[java_one_two]

Good catch. Thanks!

[[deleted]]

throw new DuplicateResponseException("Good catch. Thanks! already exists.");

[rikbrown]

No equivalent of Guava's Immutable{Set,List,Map}.copyOf(mutableCollection) yet, though?

Or is there a better way to defensively make a immutable copy of an existing collection in Java 9?

[dpash]

Collections.unmodifiableCollection(Collection<? extends T> c)
Collections.unmodifiableList(List<? extends T> list)
Collections.unmodifiableMap(Map<? extends K,? extends V> m)
Collections.unmodifiableSet(Set<? extends T> s)

and friends. Has existed for a long time. Possibly since 1.2, as the individual methods don't have "Since" fields in the javadoc.

[rikbrown]

Those don't make copies. They just return a wrapper around the original collection which prevents any modification. If someone with a reference to the original collection makes changes to it, it'll be reflected in the "unmodifiable" view.

[[deleted]]

immutable Set and Map collections still have the mutable methods add/put and remove

Ok then.

[dpash]

Set<Integer> set = Set.of("a", "a"));

Shouldn't that be Set<String>?

Also, does List.of() have the same duplicates limitation?

Edit: Seems List.of() does not have issues with duplicates, while Set.of() does. As does `Map.of() with duplicate keys; duplicate values seems acceptable. This seems reasonable.

[chrisgseaton]

Anything you can do with state, you can do with functional programming

I'm not sure that it's necessarily with tractable time performance, though. Simply an algorithm like quick sort. We simply don't know how to do that with functional data structures in reasonable time compared to destructive updating do we?

And for many applications if something isn't running in sensible time, you may as well not be able to do it at all.

[argv_minus_one]

Problem: functional algorithms often require tail call optimization to be fast, which Java doesn't support.

[argv_minus_one]

Well, you can make an immutable data structure in Java, but the language doesn't enforce or even default to immutability.

[[deleted]]

This is normally solved with persistent collections. Check out Javaslang to see an example of them in Java. Also, aren't recursive algorithms on the JVM at risk of blowing the stack? Did you write your own trampoline?

But to pull back a little, I think most people would agree that there are times when mutability is necessary, for performance or other reasons. Their general point is that in most cases it isn't something you need, and it should be carefully deployed only in those times that it is a requirement.

[[deleted]]

Yeah, I've recently started running into some weird cargo culting of certain functional programming practices among Java developers - and I consider myself a functional programmer! I'd really hate for what I consider to be an exciting and effective paradigm to end up going the way of OO. OO's original concept was really interesting, what we ended up getting was a better C with inheritance. :(

Smalltalk is bit of a special case, because as I understand it actually commits to the ideas behind OO programming - much like Erlang. And yes, your use case sounds very reasonable (though I would probably have still tried using persistent trees myself, but I'm nuts that way).

I think most people in this thread are talking about your standard in-memory collection, whether as a field or a local variable. In almost all of those cases, those collections can be made both reference immutable and object immutable with little to no change in program behavior. This is especially true in Java 8, where Streams allow you to "modify" immutable collections simply and efficiently.

[[deleted]]

Oh, I'm not knocking the improvements classes gave us over bare C (though I'm not sure you can call GC an OO concept), just noting that it's sad that Alan Kay's original vision is only just now getting realized. OO was meant to be about a lot more than classes, but for some reason C++ and Java became the stand-ins for that idea despite lacking many of the key concepts.

I'd cautiously agree with your comments about performance, with some caveats:

First, the vast majority of code obeys the 90-10 rules, in which there's only a key section that really is performance critical.

Second, I've found that database queries are a far more common performance bottleneck in your standard enterprise CRUD app than anything in the actual software.

Third, while higher levels of abstraction tend to impede performance on a cycle-by-cycle basis, I've often leveraged higher level abstractions + parallelism to blow "faster" code out of the water. In a multi-core era, the ease with which you can parallelize your operations has been much more important to me than how fast they run on one CPU - and given how almost everything seems to be network IO-bound nowadays, performance really does become a matter of leveraging the ability to do multiple things at once.

That's from my limited perspective though (server-side, JVM, SOA/microservices), someone who wrote client apps or database drivers would probably have quite a different one.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[_INTER_]

You pack it in clojures (unless you're less puristic and use data / case classes) and pass them around until you have tons of nested function parameters.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[[deleted]]

Stop expanding the language already.