-
Notifications
You must be signed in to change notification settings - Fork 10.9k
TenThingsAboutImmutableCollections
Colin Decker edited this page Oct 17, 2017
·
4 revisions
(In progress. rough outline.)
- Memory efficiency. Without mutability, there's no need to leave space for elements that might be added later. Immutable collections are always more compact than mutable equivalents.
- Order is preserved. Every immutable collection (except the sorted ones, of course) iterates over elements in the order they were added to the builder.
- copyOf() short-circuiting. You can always call ImmutableXXX.copyOf defensively on collections passed to your methods, and it's smart enough that if the collection is already immutable, and the collection isn't a partial view of a larger collection, it won't actually do the copying.
- They're types, not implementations -- think of them like interfaces.
- ImmutableCollections have an asList() view
- They don't like null.
- How they're better than unmodifiable()
- ImmutableList has a reverse() view
- They have builders
- They don't try to protect you from your equals() or hashCode() method being slow.
- As with all immutable objects, no thread-safety concerns (as long as the contents are thread safe)
- Introduction
- Basic Utilities
- Collections
- Graphs
- Caches
- Functional Idioms
- Concurrency
- Strings
- Networking
- Primitives
- Ranges
- I/O
- Hashing
- EventBus
- Math
- Reflection
- Releases
- Tips
- Glossary
- Mailing List
- Stack Overflow
- Android Overview
- Footprint of JDK/Guava data structures