I know Integers are immutable in Java. But why it is designed this way?
I went through other answers before asking this question:
But I couldn’t find the use case which mandates the Integer to be immutable.
Are there any technical reasons like there are for String?
- String is used as parameter in network connection, database URLs etc. It could easily be compromised if it was mutable.
- To support StringPool facility.
- To support class loading mechanism in which Strings are used as arguments. String being mutable results in a wrong class being loaded.
I understand there are wrappers like
AtomicInteger for mutable.
From the conversation, there is no universal reason that could mandate the Integers being immutable. However by doing immutable it provides some bonus as mentioned in the answers.
Such as this quote from Andrey
possibility to cache.
Others are reducing global state
You won’t find a mandatory reason why
java.lang wrappers must be immutable. Simply because it’s a design decision. They could have decided otherwise. The language designers had to choose between mutable and immutable. And they chose immutable. That’s it.
There are some compelling (IMO) reasons though to make them immutable:
It’s consistent with
String. The same reasoning you provided for
String to be immutable applies to
Integer etc. as well (e.g. think of a port number in a property map). This generally applies to any mutable type.
Immutable types rule out a plethora of hard to find mistakes one can make where one involuntarily changed an objects member value by modifying the value obtained through a getter. It saves a lot of defensive copying when the type is immutable. The most infamous example is
java.util.Date, which is generally a pain to use because it’s mutable (API issues aside).
Also immutable types allow for the use of shared instances, like e.g.
Integer does for commonly used values (see