Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Any type which doesn't give you any means to change the data within it is immutable - it's as simple as that. Yes, all the primitive wrapper types are immutable<sup>1</sup>, as is <code>String</code>. <a href="http://download.oracle.com/javase/6/docs/api/java/util/UUID.html" rel="noreferrer">UUID</a>, <a href="http://download.oracle.com/javase/6/docs/api/java/net/URL.html" rel="noreferrer">URL</a> and <a href="http://download.oracle.com/javase/6/docs/api/java/net/URI.html" rel="noreferrer"><code>URI</code></a> are other examples.</p> <p>Although <code>Calendar</code> and <code>Date</code> in the built-in Java API are mutable, many of the types within <a href="http://joda-time.sf.net" rel="noreferrer">Joda Time</a> are immutable - and to my mind, this is <em>one</em> reason why Joda Time is easier to work with. If an object is immutable, you can keep a reference to it somewhere else in your code and not have to worry about whether or not some other piece of code is going to make changes - it's easier to <em>reason</em> about your code.</p> <hr> <p><sup>1</sup> by which I mean <code>java.lang.Integer</code> etc. As noted elsewhere, the <code>Atomic*</code> classes are mutable, and indeed <em>have</em> to be in order to serve their purpose. There's a difference in my mind between "the standard set of primitive wrapper classes" and "the set of classes which wrap primitive values".</p> <p>You can write your own mutable wrapper class very easily:</p> <pre><code>public class MutableInteger { private int value; public MutableInteger(int value) { this.value = value; } public int getValue() { return value; } public void setValue(int value) { this.value = value; } } </code></pre> <p>So as you can see, there's nothing <em>inherently</em> immutable about wrapper classes - it's just that the standard ones were <em>designed</em> to be immutable, by virtue of not providing any way to change the wrapped value.</p> <p>Note that this allows for the same object to be used repeatedly when boxing, for common values:</p> <pre><code>Integer x = 100; Integer y = 100; // x and y are actually guaranteed to refer to the same object Integer a = 1000; Integer b = 1000; // a and b *could* refer to the same object, but probably won't </code></pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload