There's a difference between specifying a unit of time to sleep vs defining a constant. The JRE APIs are inconsistent. The google search brings up:
http://java.sun.com/j2se/1.3/docs/api/java/awt/Robot.html
which accepts millisecond sleep times as ints.
Then there's:
http://java.sun.com/j2se/1.3/docs/api/java/net/Socket.htm
which accepts millisecond timeouts as defined by ints. Also:
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/AbstractButton.html#doClick(int)
All of these are examples where a value greater than integer.MAX_VALUE would not make sense (the first one in fact throws if the value is > 60,000). As indicated in the bug report, there are natural applications of the DateUtils constants where overflows will happen. The point is that it is expected that these contants will be used in computations.
So what is the verdict here, folks? I would like to either make the change (including deprecation) or close the ticket as WONTFIX. I am +1 for changing to longs and deprecating.
Phil
Gary Gregory wrote:
Brian: "I think that constant values should always be stored using the type
that best represents them"
Perhaps the best reason for switching [lang] to using a long to represent
milliseconds is that JRE APIs do so. For example:
http://java.sun.com/j2se/1.3/docs/api/java/lang/System.html#currentTimeMilli
s()
http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html#wait(long)
More:
http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf-8&as_qdr=all&q=millis
econds+site%3Ajava.sun.com+%2Fj2se%2F1.3%2Fdocs%2Fapi&btnG=Google+Search
Gary
-----Original Message----- From: Brian S O'Neill [mailto:[EMAIL PROTECTED] Sent: Sunday, December 21, 2003 10:02 To: Jakarta Commons Developers List Subject: Re: [lang] DateUtils constants should be long
The DateTimeConstants class in Joda-time originally defined these kinds of constants as ints. Then they switched to longs, however, some classes that depended on these constants were required to downcast to ints. Although it caused no harm since the values can fit in an int, I was concerned that some users might think that storing the value in a long is required.
As of now, the constants are defined as ints again. If you are using these constants for performing calculations, you may need to ensure that the constant is cast to a long. But if you're doing calculations, then you need to be careful anyhow, and Joda-time should contain enough functionality such that you won't need to perform your own calculations.
By storing the constant as a long, an assumption is made about how the user is going to be using it. What if the user needs to do some floating-point calculations? Maybe they'll forget to cast the int or long into a double? Should the constant be then stored as a double instead? It fits. Again then this gives the impression that the constants must be represented as this type, and downcasts may cause loss of precision.
Whenever doing calculations, you always need to be aware of the precision requirements. I think that constant values should always be stored using the type that best represents them, although don't bother using byte or short since the Java platform always casts those into ints. Users of these constants are responsible for upcasting them into a type that is required for their calculation.
Stephen Colebourne wrote:
Hmmm, I hadn't thought about deprecation. But I think we do have to.
Bother.
Stephen
----- Original Message ----- From: "Gary Gregory" <[EMAIL PROTECTED]>
Hm... I thought the proposal was just to change the types from int to
long
on the existing fields as opposed to creating new fields.
Obviously this would not be backwards compatible but if we are saying
that
the fact that they are ints is, in actuality, a "bug", then, maybe,
perhaps,
it would be acceptable to break call site... arg, probably not.
It certainly would fix the client code that is just expressions (as
opposed
to assignments to ints which would no longer compile). It's never nice
to
break client code of course and deprecation is just for that purpose.
So, all of that round and round to say I agree with you in the end! ;-)
Would anyone else care to comment?
Gary
-----Original Message----- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, December 20, 2003 15:47 To: Jakarta Commons Developers List Subject: Re: DO NOT REPLY [Bug 25627] - [lang] DateUtils constants
should
be long
Gary Gregory wrote:
Looking for a volunteer (Stephen? ;-) I as I in ultra-busy mode...
I will volunteer for this. I assume that since these are (2.0
released)
public fields, we need to deprecate and rename. I would use
MILLIS_PER_*
for the new names. Sound OK?
Phil
Gary
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 12:53
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 25627] - [lang] DateUtils constants should
be
long
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25627>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25627
[lang] DateUtils constants should be long
[EMAIL PROTECTED] changed:
What |Removed |Added
-----------------------------------------------------------------------
-
--
-- Status|NEW |ASSIGNED
------- Additional Comments From [EMAIL PROTECTED] 2003-12-18
20:52
-------
Indeed, since these values express milliseconds and APIs which take
or
return millisconds usually do so a longs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
