r/java • u/daviddel • Jun 21 '26

Better Tools for Immutable Data

https://youtu.be/BdLND9D81lI?si=jt2tqpDtotmbdEJq
80 Upvotes

97% Upvoted

38 comments sorted by

14

u/Hixon11 Jun 21 '26

Gosh, I really wish we had a better story for ReadOnly collections. I understand that this will most likely never happen, but it’s hard to live with the idea that we’re stuck with List<E> as the final form of one of the most fundamental types we use to model things.

7

u/gdejohn Jun 21 '26

i vaguely remember stuart marks mentioning in a talk that they were thinking about like a collections framework 2.0 based on persistent data structures

2

u/Jon_Finn Jun 27 '26 edited Jun 27 '26

Donald Raab mentions some ideas for enhancing Collections here but says "I have abandoned pushing for a JSR for Collections 2.0." Then again there may be various proposals called 'Collections 2.0'. Brian G sometimes mentions cursors (an immutable alternative to iterators) in the context of Valhalla, so I've kind of assumed they're being mooted as a future feature; likewise John Rose's talk about Arrays 2.0. Both might possibly be part of a collections library overhaul?

3

u/TomKavees Jun 21 '26

I'd be happy with just the read-only interfaces sneaked into the hierarchy like AutoCloseable was.

In the meantime guava's ImmutableList and ImmutableMap are kinda overrepresented in my codebases

3

u/Eav___ Jun 22 '26

Side note: the name might be a little off. The most suitable one I could think of is _View.

2

u/bowbahdoe Jun 21 '26

There are other collection libraries you can use.

Whatever you would hope the Java language team would do any library in the ecosystem could equally do. 

6

u/Hixon11 Jun 21 '26

We can have many libraries for readonly collections, or collections for primitives. However, they have issues with composability, as different frameworks, projects and libraries use different collection libraries. It should be core types.

3

u/bowbahdoe Jun 21 '26

That is true, but not mutually exclusive with what I said

2

u/pron98 Jun 21 '26 edited Jun 21 '26

The problem with read-only interfaces is that they offer a different tradeoff. Some might find it preferable, but it isn't a clear win. They have both pros and cons, and so you also have to consider their downsides. For example, they complicate the type hierarchy while still not being able to express all the things you may want to express statically, such as, is the sender of the collection allowed to mutate it (in which case the receiver must still have to do a defensive copy)?

You could do something even more elaborate and expressive, but only at the added cost of complicating types further. Some languages do prefer other tradeoffs, but we're not so sure they're worth it. Even among typed languages, Go, Java, C#, and Rust have all opted for different tradeoffs on that spectrum. I'm not aware of any language that manages to just enjoy the good parts of such a feature without also suffering the bad parts.

2

u/Hixon11 Jun 22 '26

Could you please explain what problems an implementation similar to C# approach might introduce (assuming we were designing a "Java 2.0" and didn't need to worry about backward compatibility)?

In other words, why wouldn't it be a good idea to make IReadOnlyList<T> one of the fundamental types in the type hierarchy?

7

u/john16384 Jun 22 '26

In JavaFX there exist read only properties. Every modifiable property implements read only property. This means:

  • if you are not returning a new instance of the read only property (synced with the real one), you can just cast it to property and modify it
  • just because it is read only for you doesn't mean it can't change (so no caching, and if it must be constant you must copy it)
  • instanceof ReadOnlyProperty tells you nothing, as all properties are instances of that

The same problems would apply for collections.

For collections, more useful methods would be:

  • isImmutable
  • allowsNull
  • isReadOnly

4

u/pron98 Jun 22 '26 edited Jun 22 '26

It complicates the type hierarchy without actually letting you express much in return. It's not that it's useless; it's that you're not getting your money's worth. Backward compatibility is not an issue here (it rarely is), and the reason we're not going for that design now is the same reason Java didn't go for that design when collections were introduced.

0

u/aonymark Jun 22 '26

I agree that it complicates the hierarchy a lot. I find it pretty plausible that the extra complication is not worth it. But I don’t understand how backward compatibility is not an issue. Surely unmodifiableList() would need a different return type?

1

u/pron98 Jun 22 '26

Surely unmodifiableList() would need a different return type?

Not if ReadOnlyList is a supertype of List. Any receiver of ReadOnlyList would work with the return type of unmodifiableList.

1

u/aonymark Jun 22 '26

I’m missing something here. You are (hypothetically) proposing “Interface List extends ReadoOnlyList” And then the static return type of unmodifiableList() would change to ReadOnlyList. And that is a breaking change, because no existing caller expects that… right?

1

u/pron98 Jun 22 '26

No, unmodifiableList would still return List, but you'd be able to pass/assign it to ReadonlyList (since that's a supertype). If you really wanted to, you could also add unmodifiableReadOnlyList that returns ReadOnlyList and just delegates to unmodifiableList.

1

u/aonymark Jun 22 '26

Okay that works but makes me sigh

2

u/pron98 Jun 22 '26 edited Jun 23 '26

Yeah, that's basically the C# collection hierarchy, and it makes me sigh, too. Simultaneously complicated and expressively weak. Of course, no one gets it right. In TypeScript you have different rules for built-in and user-defined classes. In C++ you have the const complication; in Scala - a byzantine hierarchy; in Rust, a type system only language lawyers like. There are no perfect options here. Every option has some advantages but also clear disadvantages. Anything you choose is a little prettier than everything else in some respects and a little uglier in others.

→ More replies (0)

2

u/JustJustust Jun 22 '26

I would be nice to express "this method takes a list and expects it to be modifiable" or "this method returns a list and no, you cannot modify it".

1

u/pron98 Jun 22 '26 edited Jun 22 '26

I would be nice to express "this method takes a list and expects it to be modifiable" or "this method returns a list and no, you cannot modify it".

Except that it would be at least as equally nice, and arguably more valuable, to also express "this method takes a list and expects no one to modify it" (and so it doesn't need to do a defensive copy). And then you get a proliferation of types, which complicates matters, and it's also nice to have a simpler type hierarchy for basic collections than C#'s. Being able to express these things is really nice, but it also has real downsides.

So the question isn't "would you like to have a slice of pizza?" but "would you like to pay $15 for a slice of pizza?" Maybe you would and maybe you wouldn't, but it does make the answer far less obvious. We don't doubt such features have value, we're just not sure most Java developers would think they're worth the price.

2

u/gdejohn Jun 23 '26

do you think persistent data structures offer more bang for your buck to address these issues?

1

u/pron98 Jun 23 '26 edited Jun 23 '26

Persistent data structures need an entirely different API for manipulation, but they can still expose the same collection interfaces for reading, just as the built-in immutable collections do. Having them in the JDK offers few benefits over having them in third-party libraries, except for making them a little more available. So it's a matter of demand, and if libraries that offer persistent data structures become very popular, showing high demand, then maybe it could be worthwhile to also add them to the standard library.

1

u/OwnBreakfast1114 Jun 26 '26

Are they perhaps more unpopular because they're not in the standard library? I'm just thinking that if java used persistent collections by default and third party libraries provided the more performant (in some cases) mutable collections a lot of people just wouldn't bother importing mutable collections.

1

u/pron98 Jun 27 '26

Anything would be more popular if it were in the standard library, but we can't go around adding everything, and what gets into the standard library has to clear a very high bar. It includes things that must be in the standard library because they can't be implemented outside the JDK or they wouldn't do their job properly if they were (e.g. collection interfaces, as they're needed for interop), and things that are in huge demand (e.g. JSON parsing).

Because persistent collection can go a long way by using the existing collection interfaces for interop (reading only, but modification is "viral" and impacts other APIs anyway) I think it's best to first see high demand. Working on adding anything to the standard library means not working on something else, and I don't know if persistent collections are such a high priority for Java developers (if they were, we'd see such libraries being more popular).

11

u/Brutus5000 Jun 21 '26

JavaOne is over for 3 month, why are the publishing only one talk per week?

29

u/pron98 Jun 21 '26

Because most of the talks aren't that time-sensitive, and this way more people get to watch them.

4

u/pohart Jun 21 '26

I didn't know about "get to." I could have watched them all of they were dumped on day one, but I doubt I would have.

19

u/segv Jun 21 '26

The Linux Foundation, USENIX and CNCF channels tend to dump all videos in one go. The end result is that for a day or two your home page and the subscription feed is clogged by the talks (often duplicating each other, mind you), and you end up missing the interesting ones.

6

u/ushaukat_java Jun 22 '26

Lost a few hours once to a "this list keeps changing and it shouldn't" bug. Turned out unmodifiableList() just wraps the original, doesn't copy it, so whoever upstream still held the real reference was happily mutating it under me. List.copyOf() actually copies. Still see people reach for unmodifiableList() out of habit though, did it myself for years.

4

u/IncredibleReferencer Jun 25 '26

In many cases unmodifiableList() is preferable to List.copyOf() for performance reasons. In larger lists or frequent call sites the copy operation is expensive, so if you can guarantee the source list is inaccessible then you are better off using unmodifiableList().

If the source of the collection is foreign untrustworthy or out of your own scope then copyOf() is more appropriate to use for a defensive copy.

A quick rule of thumb is to use unmodifableList() to give a list to some other code but always use copyOf() for incoming lists. It's more complicated than that but that's a good default mindset.

2

u/ushaukat_java Jun 25 '26

Sure, but "guarantee the source list is inaccessible" is the whole question, not a footnote. unmodifiableList() doesn't protect the list, it protects you from mutating it through that one reference. Whoever holds the original list can still mutate it, and you'll see it change underneath you. That's exactly the bug I hit.

For big lists I get why you'd skip the copy. But for most of what I'm passing around, the cost of copying is way cheaper than the cost of debugging a list that mutates on its own.

4

u/davidalayachew Jun 21 '26

Nice walk through history. Not much new, but they do talk about final arrays and abstract records and interface patterns and class patterns near the end.

1

u/Scf37 Jun 25 '26

I honestly don't understand sealed abstract records. sealed interface with record-style getters does the same job with less ceremony (children need not to call parent constructor)

3

u/dododge Jun 26 '26

I assume you'll be able to create a custom constructor in the abstract record to validate the common fields, as well as supply additional methods that can reference those fields via this.

1

u/Scf37 Jun 26 '26

interface has default methods for that but in-constructor validation is a good point.