Actually, a more proper way is to indicate to the compiler that you want
long arithmetic by writing:
long millisInMonth = 1000L * 60L * 60L * 24L * 30L
Oh, and by the way, this is not really correct since you're assuming 30 days
in a month. You should use the Calendar to figure out how many millis a
given month actually has since this varies by month and year.
----- Original Message -----
From: Jeff Schnitzer <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 3:50 AM
Subject: RE: Database schema type mappings
> 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
> >>
> >>
> >>
> >
> >
> >
>
>
