How to create an immutable class in Java without using final keyword [duplicate]

This question already has answers here: 开发者_运维百科 Closed 11 years ago.

Possible Duplicate:

Implement a final class without the “final” keyword

I want to create an immutable class in Java without using the final keyword.

---

I think smt like should work fine

class Immutable {
    private int i;
    public static Immutable create(int i){
        return new Immutable(i);
    }
    private Immutable(int i){this.i = i;}
    public int getI(){return i;}
}

But final is preferable.

---

The final keyword won't make your class inmutable. It will avoid your class to be extended from another class.

public final class Foo {
   //....
}

public class Bar extends Foo {
   //COMPILATION ERROR!
}

An adecuated class design is what will make you class inmutable, as you can see at duffymo answer.

Note that you can declare as final the fields that you will initialize at the constructor:

class Foo {
    private final int state

   public Foo(int v) {
      this.state=v;
   }

   //....
}

The difference is that, while at duffymo example, the value ccould be changed from inner routines (i.e, a method adds one to the value, kind of a counter), at my example you wouldn't be able to do so.

Let's try to avoid absolutely the use of the final keyword:

public class Foo {

   private int state;


   private Foo(int v) {
       this.state=v;
   }

   public static Foo getInstance(int value) {
      return new Foo(value);
   }

}

You only can get an instance of Foo accesing the Foo.getInstance method.

But anyway, you can extend the Foo class and make it mutable I was wrong here. I won't compile, as you can acceess the Foo constructor.

public class Bar extends Foo {
    private int ohNopes;

    //COMPILATION ERROR!
    public Bar(int v) {
        this.ohNopes=v; 
    }
}

So, it seems it can be done, after all.

---

The problem with an immutable class not being final is that, subclasses may not be immutable.

Here is an example from the Java API, java.lang.String is immutable and final, if a string is passed to one of your methods you can be sure that it will remain in a consistent state.

the following will not compile because String is final:

public class MyString extends java.Lang.String {
    public MyString(String original) {
        Super(original);
    }

    @Override
    public String toString() {
        return String.valueOf(System.currentTimeMillis());
}

On the other hand, java.ma.BigDecimal itself is immutable, but it is not final and allowed to be subclassed. This opens up a range of issues. If a BigDecimal is passes to one of your methods you can't rely on the fact that no one has overridden BigDecimal like you can with String. subclasses of BigDecimal could potentially replace its methods with others which give unpredictable results.

The following will compile because BigDecimal is not immutable:

public class MyBigDecimal extends java.math.BigDecimal {
    public MyBigDecimal(double val) {
        super(val);
    }

    private int count = 0;
    // override intValue which changes the state of this instance
    @Override
    public int intValue() {
        return count++; 
    }

    // rinse and repeat for the rest of the BigDecimal methods... 
}

You cannot rely on he state of BigDecimal instances passed into your code, you should make Defensive copies of non final classes if you need to rely on their immutability.

---

I can't imagine why you object to using final, but here's a class that will get the job done. I know there are subtleties regarding serialization and reflection, but this can't be changed without special shenanigans:

public class Immutable
{
    private int value;

    public Immutable(int v)
    { 
        this.value = v;
    }

    public int getValue() { return this.value; }
}

---

The class should set all its values in the constructor, and provide no setters (methods that modify class members).

---

You can create a class then create a .jar and use the jar as resource.