Sorry for the slow reply here, but in Java, “final” variables can’t be updated to reference a different object, but the underlying object can be modified with m

Sorry for the slow reply here, but in Java, “final” variables can’t be updated to reference a different object, but the underlying object can be modified with method calls (e.g. you can append things to a “final” ArrayList, whereas in C++ you can’t append to a const vector. In C++, you mark methods const to indicate that they don’t mutate the underlying object, and only cost methods can be called on const variables). The Guava docs give an example of the defensive copying: https://github.com/google/guava/wiki/ImmutableCollectionsExplained https://github.com/google/guava/wiki/ImmutableCollectionsExp.... Any time an Immutable collection is created from another collection, the elements are deep-copied to avoid the possibility that they’re modified elsewhere, even if there’s no possibility of that happening. Even if you’re using e.g. an ImmutableList.Builder, the elements are copied when they’re Add()ed to the Builder, so that they’re the same when you call build(). I’m not sure but I think even some mutable collections make defensive copies of their arguments. I believe that Josh Bloch (who was in charge of Java at Google when I joined) also advocates for this in his book. On writing this, it occurs to me that some kind of move constructor into these mutable collections might also do the job? Though you’d have to make sure there were no mutating references outside the mutable collection as well, which might require some kind of ownership model, so you might just wind up with Rust. Finally, this is dumb but it’s killing me: I meant to type 400qps to 1200qps/core.