Dead Horse (was Re: Calendar.MONTH returns 2 its March now)

• Subject: Dead Horse (was Re: Calendar.MONTH returns 2 its March now)
• From: Paul Roebuck <email@hidden>
• Date: Thu, 24 Mar 2005 18:17:33 -0600
• Delivered-to: email@hidden
• Delivered-to: email@hidden

Glen Ezkovich <email@hidden> wrote:

On Mar 24, 2005, at 1:06 PM, Greg Guerin wrote:

Glen Ezkovich <email@hidden> wrote:

The point I'm trying to make is simply that its a mistake to assume
anything about constant values. These values are named so that should
we change the implantation of their class, clients will not need to
change their code. Once you assume their values will never change you
have made your code brittle.

If you think they're named so they can be changed in the future, then all
your compiled code is already brittleized (or would that be "embrittled"?).

All the named Calendar constants, not just months, are defined as:
  public final static int <NAME> = <int constant here>;

That means a Java compiler is free to inline them as literal constants into
any class that references them by name.  So if your class Foo has this:
  int bar = Calendar.FEBRUARY + 1;

The compiler will inline Calendar.FEBRUARY as the literal constant 1,
evaluate the sum of two constants, and compile in the literal constant 2.
There will be no symbolic reference at all to the static field
Calendar.FEBRUARY, and you can use 'javap' to observe this.

The consequence is that if Calendar.ANY_MONTH were ever assigned a new
value, all existing compiled code would break very badly.  Unless the new
values were carefully done in some kind of compatibility kluge.

Come on Greg. This is exactly my point. Why are you adding 1 to Calendar.February in the first place? Are you trying to have bar == Calendar.MARCH? If you are, you just hosed yourself by assuming the value of FEBRUARY would not change. By treating FEBRUARY as you would any other int, you've screwed up. FEBRUARY represents the month February not 1. To my mind the error is that FEBRUARY is of type int, The whole point is don't assume anything about the values of constants other then what is explicitly documented. The fields are there to use in the invocation of the classes methods, set(Calendar.MONTH, Calendar.FEBRUARY), etc. and to compare the equality of one month to another.

Since none of us gets to redesign java.util.Calendar and java.util.Date
anyway, it's utterly moot.  You can design replacements, but this isn't
the Java-Redesign list, so it's off-topic.

OK. but I thought this was about the proper use of constants.

Haven't this been hashed over long enough? The same inlining Greg
spoke of occurs in the cases of a switch statement, so addition is
not required. Sun has more than enough bugs in their other code to
worry about without changing the values of final public static month
constants.

Regardless of whether you think it's a boneheaded design, it's the
one Sun provided and it mirrors ANSI C/POSIX time struct. File a
documentation bug with Sun if you want a guarantee.

But let it go...

--
----------------------------------------------------------
Out of the 10Base-T, through the router, down the T1, over the
leased line, off the bridge, past the firewall... nothing but Net.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

• Prev by Date: Re: Calendar.MONTH returns 2 its March now
• Next by Date: Re: Using a custom classLoader
• Previous by thread: Re: Calendar.MONTH returns 2 its March now
• Next by thread: Re: Calendar.MONTH returns 2 its March now
• Index(es):
  • Date
  • Thread