Possible bug in Calendar

[Harold Yarmouth]

Of course it's not returning a singleton, since the javadoc of the
getInstance method explicitely says that "The Calendar returned is
based on the current time [...]".

Which could, perversely, be referring to the time the documentation
was being written. Stranger things have happened.

You will not get nominated twice !

Excuse me?

Since it stores time in milliseconds and need to convert to and
from Date with milliseconds then avoiding using milliseconds
would be difficult and inconsistent.

That's begging the question. You can't claim that including the
milliseconds isn't silly because it includes the milliseconds. Not with
a straight face, surely.

As I said previously, it could feed zero milliseconds to Date. Or have
its own milliseconds, but zero them out if you set everything that's
coarser-grained.

 

[Harold Yarmouth]

I have the feeling that Calendar.getInstance() is not returning a
singleton, and that it is also not zeroing out newly-created instances.

Of course it's not returning a singleton, since the javadoc of the
getInstance method explicitely says that "The Calendar returned is
based on the current time [...]".

That's ambiguous. Could have meant the current time from the viewpoint
of the guy writing the documentation, so, the time the documentation
got written.

I hereby nominate that argument for the title as the most lame
argument posted to cljp in 2008.

I hereby nominate you for the title of the rudest poster in cljp.

If you can't keep things professional instead of getting personal, it
may be time for you to hang up your modem and go on vacation for, oh,
say, a thousand years or so.

(And Arne has nothing constructive to say here, either, just more
personal attacks.)

 

[Harold Yarmouth]

No

Yes, it is.

I am trying to bring you from non-programmer to programmer-newbee

I am an experienced programmer and I'll thank you to stop badmouthing me
in public!

The readers would prefer

The readers can make up their own individual minds without any arrogant
presumption by you.

If you consider my posts a waste of time, DON'T READ THEM. Filter my
posts, or just plain ignore them. Don't reply to every one of them to
publicly tell lies about me or otherwise waste everyone ELSE's time.

Please tell me where in the Java API you see that practice ?

I didn't say in the Java API, I just said "any code". Or rather, *you* did.

Because it would be very bad OO design.

No, it wouldn't.

You do not let Calendar be GregorianCalendar and then ask all
other Calendars to overwrite most methods.

Who said anything about that?

Read up on

Stop being rude and condescending. Do not bark orders at me. Or I will
do the same to you. Got it?

Yes.

The other approach will result in a ton of if statements and switches
in the methods.

Nonsense. It will result in some pluses and minuses of the timezone
offset here and there, that's all.

 

[Harold Yarmouth]

Okay, should I be constructing a GregorianCalendar, BuddhistCalendar,
JulianCalendar, what? Constructors aren't polymorphic, Calendars are.

This is ludicrous. Only one of the above is in common use for business
purposes. The others are essentially fluff and shouldn't complicate the
core APIs used for getting actual serious work done.

Let me repeat: they're DOCUMENTED.

Let ME repeat: Just because something is documented does not make its
design automatically be without flaws.

This isn't something that's buried in
paragraph 9 of the 30th page, it's mentioned in paragraph 3 of the class
documentation at about the position my eyes naturally gravitate towards.

My IDE shows me the documentation for the method whose invocation I'm
writing. That would be the set method in this case.

Why is this argument getting so long and repetitive, anyway? You have
said your opinions and I have said mine. There's no point in your
repeating the same set of opinions a second time.

 

[Harold Yarmouth]

The answer, 99.99999% of the time, is going to be one particular one of
these.

Let ME repeat: Just because something is documented does not
automatically absolve it of a charge of having a flawed DESIGN.

And the IDEs tend to show the current method documentation (say, for
"set") only.

Furthermore, for anyone who has read /Effective Java/ by Joshua Bloch

Not relevant, since not everyone HAS read that or any other book.

it is well known that factories are often preferable to constructors,
in part for the reasons Joshua mentions.

I don't see any more need for a factory of date builders than I do for a
factory of StringBuilders. StringBuilder gets by with a straight
constructor.

See my other post about suspecting that they mixed multiple
responsibilities into one class, ending up with a boondoggle for their
efforts.

This might have been a more appropriate method name, given the present
implementation of the class.

See? No guarantee or convention that 'getInstance' return a singleton.

I never claimed otherwise. I said that in the absence of a strong reason
for the return value to be polymorphic, it tends to indicate a singleton
or otherwise a "bound" instance of some sort.

 

[Harold Yarmouth]

Yes.

But apparently SUN does not seem to think so. There are lots of
getInstance methods that return non singleton. I counted 44 classes
in the Java API.

But I never said that getInstance methods return only singletons! I said
that no-argument getInstance methods with no obvious reason to return
polymorphic values tend to indicate a singleton or some other "bound
instance", for example a per-thread instance.

 

[Harold Yarmouth]

I repeat: you can not instantiate an abstract class.

And I repeat: it should be concrete. We don't have an abstract
StringBuilder and a bunch of polymorphic StringBuilder subclasses, even
though string encodings and characters and presentation are often
heavily locale-dependent, so why an abstract and polymorphic date
builder type?

The only explanation I can think of, besides sheer perversity, is
because they gave one class multiple responsibilities.

But it is not.

Sure it is.

Its primary use are to get local specific interpretation and
modifications of date objects.

You can get that by adding the time zone offset to the time, for
Chrissake, and using a suitable DateFormat when converting to and from
user-visible or -supplied strings.

No. Everyone that read the documentation will of course set those
as well (if needed in the context).

Except that the set method doesn't let you. It only has the six
arguments years, months, days, hours, minutes, and seconds. So the natural

Calendar c = Calendar.getInstance();
c.set(yy,mm,dd,h,m,s);
Date d = c.getTime();

results in a date with a seemingly-random component when really the
above should suffice to yield a Date object dependent solely upon yy,
mm, dd, h, m, and s. Instead, to get such a Date object apparently
requires extra effort of some kind.

And that, by itself, is sufficient to demonstrate conclusively that a
design flaw exists.

So your continuing to argue with me (and even to get quite hostile!)
regarding whether or not such a flaw exists is pointless and stupid. It
exists. It is as plain as the nose on your face. I don't know why you
continue to deny it. A misguided knee-jerk impulse to defend Java
whenever it is criticized, however constructively?

I don't know and I don't really care, either. Please stop repeating
yourself, please stop attacking other people and not merely
dispassionately discussing Java, and please stop cluttering up this
thread and this newsgroup with pointless bickering.

 

[Harold Yarmouth]

There are.

No, there aren't.

Arab, Chines and Japanese calendars are very different from Gregorian
and Julian calendars.

Irrelevant. Nobody much uses pre-industrial calendars anymore, certainly
not for business applications and e-commerce.

 

[Harold Yarmouth]

Please provide a reference to which.

I can't. It's just the code that's out there. You get a feel for these
things working with, seeing, using, and writing large amounts of code.
So you will have your answer if and when you are sufficiently
experienced. If you don't have it yet, just keep working with Java and
the patterns will become apparent to you in the fullness of time.

 

[Harold Yarmouth]

I don't think so. That i a rather rare usage of Calendar.

No, it is the single most common usage of Calendar.

And note that even that usage is working fine

No, it is not. It violates the principle of least astonishment. (And no,
documenting surprising behavior does not negate its qualifying as
surprising, else the principle would become meaningless since then any
coder could trivially avoid violating it.)

 

[Harold Yarmouth]

Just name 10 libraries.

Just you stop pestering me and, especially, insinuating in public that
I'm some sort of liar or charlatan. It is exceptionally rude and
uncalled-for behavior that I shall not tolerate from you or anybody else!

(If you insist -- almost ANY ten.)

 

[Joshua Cranmer]

Irrelevant. Nobody much uses pre-industrial calendars anymore, certainly
not for business applications and e-commerce.

And since when is Java only for business applications? Nice to know that
you're so culturally sensitive in ignoring such major calendars as the
Chinese calendar, Arabic calendar, and Hebrew calendar.

 

[Joshua Cranmer]

Not relevant, since not everyone HAS read that or any other book.

It is relevant, since it is one of the best references for good Java
design. Heck, I haven't read it myself yet, but I still know many of the
most useful facts in there. Like this one, for example.

This might have been a more appropriate method name, given the present
implementation of the class.

This method name is internally consistent within Java's core APIs, in
particular locale-related APIs.

I never claimed otherwise. I said that in the absence of a strong reason
for the return value to be polymorphic, it tends to indicate a singleton
or otherwise a "bound" instance of some sort.

The Calendar class is obviously polymorphic from its API; this fact you
cannot deny, independent of whether or not it /should/ be. Since it /is/
polymorphic, that means that getInstance does not have to abide by a
general implied contract for non-polymorphic classes.

 

[Lew]

I can't. It's just the code that's out there. You get a feel for these
things working with, seeing, using, and writing large amounts of code.
So you will have your answer if and when you are sufficiently
experienced. If you don't have it yet, just keep working with Java and
the patterns will become apparent to you in the fullness of time.

This is what happens when you accidentally delete your kill file. You find a
complete redefinition of statistical analysis.

Statistics by definition involves objectivity and measurement. A "feel for
these things" is notoriously inaccurate. It's based on a non-random sample
and subject to subjectivity. The assertion requires evidence. Absent
evidence, we could debate both sides until the cows come home and never arrive
at truth.

I have ten years' Java experience and my "feel for these things" is quite
different. It also helps that I have authoritative evidence that 'getX'
factories don't necessarily imply singletons, /op. cit./.

<http://www.ddj.com/java/208403883>

When the gods speak, mortals should listen.

 

[Joshua Cranmer]

I am an experienced programmer and I'll thank you to stop badmouthing me
in public!

For an experienced programmer, you seem strangely unwilling to read the
documentation in question.

 

[Lew]

Not relevant, since not everyone HAS read that or any other book.

You had better.

How can anyone claim to be any good at any programming without reading any book?

Rhetorical question, don't bother answering. Kill file re-established.

 

[Lew]

I am an experienced programmer and I'll thank you to stop badmouthing me
in public!

Ancient Japanese saying: Only perfect practice makes perfect.

Ancd you aren't going to thank him for anything.

 

[John W Kennedy]

No, there aren't.


Irrelevant. Nobody much uses pre-industrial calendars anymore, certainly
not for business applications and e-commerce.

Well, I tried to give you the benefit of the doubt about being an
asshole, but you had to raise the ante by being an ignorant racist, too.

*PLONK*

--
John W. Kennedy
"Though a Rothschild you may be
In your own capacity,
As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
So you start another company to-morrow!"
-- Sir William S. Gilbert. "Utopia Limited"

 

[Daniel Pitts]

No, it is the single most common usage of Calendar.


No, it is not. It violates the principle of least astonishment. (And no,
documenting surprising behavior does not negate its qualifying as
surprising, else the principle would become meaningless since then any
coder could trivially avoid violating it.)

Bad design != bug
Bad design -> bug

Just because it is designed poorly, doesn't mean there is a bug. Poor
design might lead to a bug (as it did in your case), but a bug is
formally "not working to specification". Calendar works to its flawed
specification.

 

[Lew]

Just because it is designed poorly, doesn't mean there is a bug. Poor
design might lead to a bug (as it did in your case), but a bug is
formally "not working to specification". Calendar works to its flawed
specification.

Is it flawed? Is it really?