How to make Date Immutable

[Vijay jai Singh]

Hi,

Date in java is mutable. Is there any way to make it Immutable other than creating an object with final key word.

Thanks and Regards
Vijay

[Christophe Verré]

Is there any way to make it Immutable other than creating an object with final key word.

This would not make it immutable anyway. Its content would still be mutable.

You could make a wrapper class, but is is really necessary to go through all that pain ? Why do you want to make it immutable ?

[Vijay jai Singh]

Christophe Verré wrote:

Is there any way to make it Immutable other than creating an object with final key word.

This would not make it immutable anyway. Its content would still be mutable.

You could make a wrapper class, but is is really necessary to go through all that pain ? Why do you want to make it immutable ?

Hi Christophe,

Thanks for your reply. It is not my project requirement. Just thinking about how to implement this. Could you please help:
a) Why it would not be immutable if i use final while creating object of Date.
b) How to make wrapper class.

Thanks and Regards
Vijay

[Jesper de Jong]

Vijay jai Singh wrote:a) Why it would not be immutable if i use final while creating object of Date.

Because making a variable final only means that you cannot change the value of the variable itself; you can still change the state of the object that the variable refers to. For example:

final Date date = new Date();
date.setYear(2010); // allowed!

b) How to make wrapper class.

Write a class yourself that has the same methods as class Date, except the set...() methods and other methods that might change the state. Put a private member variable of type Date in your class, and forward all calls to the Date object. For example:

import java.util.Date;

public class ImmutableDate {
	private Date realDate;

	public ImmutableDate() {
		realDate = new Date();
	}

	public ImmutableDate(long date) {
		realDate = new Date(date);
	}

	// ...

	public boolean after(ImmutableDate when) {
		return realDate.after(when.realDate);
	}

	public boolean before(ImmutableDate when) {
		return realDate.before(when.realDate);
	}

	// ...
}

[Maneesh Godbole]

Search the forums.
I remember reading an article on this in the Journal by Illja Preuss if I am not mistaken.

[Maneesh Godbole]

Maneesh Godbole wrote:..by Illja Preuss if I am not mistaken.

I was mistaken indeed. It was authored by David O'Meara. (I hope he is on vacation and doesn't see this)

Here you go. http://www.javaranch.com/journal/2003/04/immutable.htm

[Christophe Verré]

I hope he is on vacation and doesn't see this

I'll tell him anyway

[Vijay jai Singh]

thanks Christophe, Jesper, Maneesh for your responses

Thanks and Regards
Vijay

[G.Sathish kumar]

Jesper Young wrote:

Vijay jai Singh wrote:a) Why it would not be immutable if i use final while creating object of Date.

Because making a variable final only means that you cannot change the value of the variable itself; you can still change the state of the object that the variable refers to. For example:

final Date date = new Date();
date.setYear(2010); // allowed!

b) How to make wrapper class.

Write a class yourself that has the same methods as class Date, except the set...() methods and other methods that might change the state. Put a private member variable of type Date in your class, and forward all calls to the Date object. For example:

import java.util.Date;

public class ImmutableDate {
	private Date realDate;

	public ImmutableDate() {
		realDate = new Date();
	}

	public ImmutableDate(long date) {
		realDate = new Date(date);
	}

	// ...

	public boolean after(ImmutableDate when) {
		return realDate.after(when.realDate);
	}

	public boolean before(ImmutableDate when) {
		return realDate.before(when.realDate);
	}

	// ...
}

i feel when the state of the object change there should be new object for the immutable object so wht code which you mentioned i think will not give immutable object when there is situvation like

data+20 days should be new date object so we need to extend the date class and use super to call the parent instance and the result need to be returned as new date object(i have seen that same thing implemented in string class in java).

[Campbell Ritchie]

Yes, that is the standard method for new values for immutable classes. Simple example

public final class Point /* Notice that a truly immutable class should be labelled final */
{
  private final int x;
  private final int y;
  private int hash;

  public Point(int x, int y)
  {
     this.x = x;
     this.y = y;
     hash = 0;
  }//end constructor

  public int getX()
  {
     return x;
  }

  public int getY()
  {
     return y;
  }

  /**
   * @param distance How far to move in the x-direction (horizontally). Negative values permitted.
   */
  public Point moveX(int distance)
  {
     return new Point(x + distance, y);
  }

  public Point moveY(int distance)
  {
     return new Point(x, y + distance);
  }

  public Point move(int distanceX, int distanceY)
  {
     return new Point(x + distanceX, y + distanceY);
  }

/*
 * Uses lazy initialisation and caching; eager initialisation or no caching
 * would also work.
 */
  @Override
  public int hashCode()
  {
     if (hash == 0)
     {
         hash = (getClass().getName().hashCode() * 31 + x) * 31 + y; 
     }
     return hash;
   }

  @Override
  public String toString()
  {
     return "Point at x = " + x + ", y = " + y + "."; // This value could have been cached, like the hash code.
  }

  @Override
  public boolean equals(Object obj)
  {
     return obj == this ||
             (obj instanceof Point &&            /* instanceof works reliably for a final class */
                 ((Point)obj).x == this.x &&     /* cast always works after instanceof */
                 ((Point)obj).y == this.y);
  }
}// end class Point

Note:

Use final modifier to prevent anybody creating mutable subclasses.

All "real" fields are final too.

No set methods.

If there were any mutable reference type fields, they would be copied before being returned by a get method. You could do that with a copy constructor in the field . . . return newFoo(this.foo);

No need for copy constructors in immutable objects

The hash code (or the return value for toString) can be calculated when required, or at construction time, and cached, if you prefer.