Re: Does java.util.Date.clone() return a new object?
Marcin Rze??nicki wrote:
On 15 Pa??, 16:11, laredotornado <laredotorn...@zipmail.com> wrote:
I'm using Java 1.5. If I have
java.util.Date newDate = (java.util.Date) origDate.clone();
newDate.setYear(50);
Will the value of origDate.getYear() be 1950? That is, did clone make
a new object or just return a reference?
Is it so hard to consult the documentation?
"By convention, the object returned by this method should be
independent of this object (which is being cloned)."
Probably not, but it does not provide an authoritative answer.
"By convention" and "should be" are not the same as "Required"
and "must be".
I think that all we can say is that if the java doc for clone for
the specific class does not mention anything about violating the
convention, then one should assume that it is indeed the case
and promise to beat up the author of the code and java doc with
a baseball bat, if it turns out to give problems. But it is an
assumption with a risk of being wrong.
I will strongly recommend treating Date as immutable and never
call a set method on it. This will both give better code and
avoid this problem completely.
(all set methods except one is deprecated anyway)
Is it so hard to see the code of this method if still in doubt?
public Object clone() {
Date d = null;
try {
d = (Date)super.clone();
if (cdate != null) {
d.cdate = (BaseCalendar.Date) cdate.clone();
}
} catch (CloneNotSupportedException e) {} // Won't happen
return d;
}
Probably not, but rather pointless.
If one is interested in writing a correct Java program then relying
on implementation from vendor X version Y is not good.
Arne