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.
Note that all primitive types, along with Strings, having 'static
final'
qualifiers can be compile-time literals and thus subject to inlining.
And
there's no way to tell the compiler to NOT inline such constants. It
arguably has to, in order for 'case' to work (see JLS on 'case'-value
constraints).
right no problem with this.
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.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
_______________________________________________
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
