Does java.util.Date.clone() return a new object?

L

laredotornado

Hi,

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?

Thanks, - Dave
 
M

Marcin Rze¼nicki

Hi,

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?

Thanks, - Dave

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)."

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;
}
 
R

Roedy Green

Will the value of origDate.getYear() be 1950? That is, did clone make
a new object or just return a reference?

Clone means clone. There would be no need of a clone method if it
didn't make a new object. You may have watched too many Star Trek
movies. You can always do an experiment if the docs don't make sense
to you on tell you IDE to show you the implementation. The computer
will definitely not explode.
--
Roedy Green Canadian Mind Products
http://mindprod.com

When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
~ Eric S. Raymond (born: 1957-12-04 age: 51) The Cathedral and the Bazaar
 
L

Lothar Kimmeringer

laredotornado said:
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?

It's creating a new instance and with setYear you are using
a method that is deprecated for about 10 years now. Use
java.util.Calendar instead please.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
D

David Lamb

Lothar said:
laredotornado wrote:

It's creating a new instance and with setYear you are using
a method that is deprecated for about 10 years now. Use
java.util.Calendar instead please.

I'd use Calendar myself, but the last discussion I'd heard about it
(admittedly long ago, possibly back in the 1.2 days) was grumbling about
how over-complex it was. Has the grumbling died down? Do most people
use Calendar now?
 
L

Lew

David said:
I'd use Calendar myself, but the last discussion I'd heard about it
(admittedly long ago, possibly back in the 1.2 days) was grumbling about
how over-complex it was.  Has the grumbling died down?  Do most people
use Calendar now?

Grumbling is not a reason to be afraid of the class. Consider that
those who grumble about Calendar being "over-complex" might have no
good reason behind that conclusion.

Forget about Calendar for a moment, and quickly answer this question:
How many hours will elapse in New York City between midnight, November
1, 2009, and midnight, November 2, 2009, local time? What is the date
in New York City twenty-tour and a half hours after midnight, November
1, 2009, local time?

This type of question was incorrectly answered in production systems
I've worked on. It messed up business rules involving time intervals.

How many days were in Gregorian calendar year 2000? 1900? 0?

If Calendar can handle such questions with simple method calls, how is
it "over-complex"?

You need more than vague grumbling overheard at the water cooler to
justify such a judgment.
 
N

Nigel Wade

I'd use Calendar myself, but the last discussion I'd heard about it
(admittedly long ago, possibly back in the 1.2 days) was grumbling about
how over-complex it was.

I don't think it's over-complex. Yes it's complex, but so are the issues
related to date/time/timezone, and any class which handles these
correctly is necessarily going to be complex. If you have a problem which
involves date/time/timezone and you think it's a simple problem then I'd
be fairly certain you haven't fully understood the problem or it's
implications.
Has the grumbling died down?

I doubt the grumbling will ever die down. Too few people properly
understand the issues involved, so they see Calendar as overly complex.
Do most people
use Calendar now?

There is little option. It's the class you need to handles dates, times
and timezones properly.
 
D

David Lamb

Lew said:
Grumbling is not a reason to be afraid of the class. Consider that
those who grumble about Calendar being "over-complex" might have no
good reason behind that conclusion. ....
You need more than vague grumbling overheard at the water cooler to
justify such a judgment.

I've been told I have "insufficient fear of complexity" so wasn't sure
how to interpret the grumbling.
 
L

Lew

David said:
I've been told I have "insufficient fear of complexity" so wasn't sure
how to interpret the grumbling.

Take the ill-founded basis for the grumbling, factor in that they resort to
insults instead of logic to defend their position, and you reach the
conclusion that there is no problem except that the grumblers are idiots and
fools.
 
A

Arne Vajhøj

David said:
I'd use Calendar myself, but the last discussion I'd heard about it
(admittedly long ago, possibly back in the 1.2 days) was grumbling about
how over-complex it was. Has the grumbling died down? Do most people
use Calendar now?

Yes.

Because it does the job.

It is not simple and I will not rule out that it could have been done
simpler, but the rules the class tries to represent are complex in
themselves.

Remember the famous quote: "For every complex problem, there is a
solution that is simple, neat, and wrong".

Arne
 
A

Arne Vajhøj

Marcin said:
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
 
D

Dave Searles

Marcin said:
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;
}

Eeeuw. I knew java.util.Date was fucked up, but I never realized it was
*this* bad.

Shouldn't there at least be an assert false; in the catch block, if not
a throw new Error(); or something? Just in case it ever DOES happen
despite the programmer being sure that it cannot.
 
L

Lothar Kimmeringer

Dave said:
Eeeuw. I knew java.util.Date was fucked up, but I never realized it was
*this* bad.

Shouldn't there at least be an assert false; in the catch block, if not
a throw new Error(); or something?

Why? BaseCalender.Date is Clonable and cdate is created on
demand, if not already set. In addition to that the JDK is
covered by testcases and I'd wonder if there isn't one for
the cloning of Date.
Just in case it ever DOES happen
despite the programmer being sure that it cannot.

So you prefer, that e.g. a server-application is coming to
a grinding halt instead of keep on running?


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
L

Lothar Kimmeringer

Leif said:
For a direct, logical error in the program flow? Yes.

We were talking about java.util.Date.clone(). Can we stick
with the topic please?
Once a "Won't happen"
happens, you have no idea where you are in the terrain any more: it's dark,
foggy and your map is wrong. The only sensible thing to do is to stop.

So if you can't copy a value you don't need and recreate
on demand you really would stop the server?


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
L

Lothar Kimmeringer

Leif said:
I am sticking to the topic: if an exception that you know will not
occur at a given point in your code nevertheless occurs, you have a
direct, logical error in the flow of your program.

With what consequence for java.util.Date in this case?
Not as a general rule, no, of course not. However, if this happens because
impossible exceptions starts cropping up, then, yes, the system should stop.

As we are talking about java.util.Date here, you really would
crash a server in such a case? This subthread is not about
a common rule but a very specific code in java.util.Date.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,578
Members
45,052
Latest member
LucyCarper

Latest Threads

Top