Yes, it fits into a long, but by default constants like
1000 * 60 * 60 * 24 * 30
are ints, so the arithmetic is done using int math. Inconveniently, the
value of that expression is (slightly) greater than Integer.MAX_VALUE so
overflow occurs. Thus the negative value which gets assigned to
millisInMonth.
The fix is to force long math:
long millisInMonth = (long)1000 * 60 * 60 * 24 * 30;
This should probably go in some sort of Java-puzzle magazine article.
:-)
Jeff
>-----Original Message-----
>From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 01, 2001 1:09 AM
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>Jeff, about the bug you mention... that sounds very strange to
>me and it
>sure should not have anything to do with byte size, I think. The value
>millisInMonth easily fits into a long... So if you have a long
>representing
>the current time milliseconds and subtract one month of
>milliseconds, yes,
>that should definately produce a time last month.
>
>I would like to know if I am wrong in this assumption or what
>the bug REALLY
>was about (?)
>
>R.
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
>Schnitzer
>Sent: 1. marts 2001 02:38
>To: Orion-Interest
>Subject: RE: Database schema type mappings
>
>
>You're thinking C++.
>
>In Java:
>
>A long is 8 bytes, always.
>An int is 4 bytes, always.
>
>The byte-orders are fixed independent of the hardware, too.
>
>Speaking of byte size, here's something I found amusing (and annoying):
>
> long millisInMonth = 1000 * 60 * 60 * 24 * 30;
> Date thirtyDaysAgo = new Date();
> thirtyDaysAgo.setTime(thirtyDaysAgo.getTime() - millisInMonth);
>
>This actually produces a date in the FUTURE!
>
>It took me a while to hunt down this bug because it had really wierd
>effects on my application.
>
>Jeff
>
>>-----Original Message-----
>>From: Michael A Third [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, February 28, 2001 11:02 AM
>>To: Orion-Interest
>>Subject: RE: Database schema type mappings
>>
>>
>>Randahl,
>>
>>We use the primitive long for all of our primary keys for a couple of
>>reasons:
>>* primary keys can't be null so there isn't a need for Long
>>(or Integer)
>>* long's are always 4 bytes no matter what the CPU (32bit vs
>>64bit), which
>>is currently not a problem but could be when Itanium platforms
>>come out.
>>int's depend on the CPU's native integer type which happens to
>>be 32bits on
>>ix86 architectures.
>>
>>Michael Third
>>Chief Software Architect
>>parts.com
>>
>>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink
>>Isaksen
>>Sent: Wednesday, February 28, 2001 10:02 AM
>>To: Orion-Interest
>>Subject: Database schema type mappings
>>
>>
>>If you look at the database schema in
>>"orion/config/database-schemas/hypersonic.xml" it looks as if
>>it is mapping
>>between the primitive java type "int" and the corresponding
>>database type
>>"int":
>><type-mapping type="int" name="int" />.
>>
>>In my EJBs my primary keys and other attributes are of type
>>Integer. Since
>>there is no mapping for class Integer one could think that
>>Integers would be
>>mapped to VARBINARY. Luckily my integers are mapped to the
>>database type
>>"int", but this makes me ask two questions:
>>
>>1. Why is Integers automatically converted to int by Orion -
>>and is this a
>>standard EJB convention?
>>2. Would it be legal to have a primary key of the primitive type "int"
>>instead of Integer?
>>
>>
>>Yours
>>
>>Randahl
>>
>>
>>
>
>
>
