java.lang.Long problem

[seb]

Hello,
I have a problem when I use Long values:

example:

Long number = new Long("6216858393170145432");
Window.alert("" + number);

show me 6216858393170145000

I have the same problem when I serialize/deserialize my Long object:
The long object value in my servlet equals to 6216858393170145432 but
equals to 6216858393170145000 in my gwt client.

I am using gwt 1.3.3 (Windows)

[Sandy McArthur]

From the docs:
"Intrinsic types
byte, char, short, int, long, float, double, Object, String, and
arrays are supported. However, there is no 64-bit integral type in
JavaScript, so variables of type long are mapped onto JavaScript
double-precision floating point values. To ensure maximum consistency
between hosted mode and web mode, we recommend that you use int
variables."
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.JavaToJavaScriptCompiler.LanguageSupport.html

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

[seb]

...I didn't see that, thank you !

On Apr 3, 4:46 pm, "Sandy McArthur" <sandy...@gmail.com> wrote:
> From the docs:
> "Intrinsic types
> byte, char, short, int, long, float, double, Object, String, and
> arrays are supported. However, there is no 64-bit integral type in
> JavaScript, so variables of type long are mapped onto JavaScript
> double-precision floating point values. To ensure maximum consistency
> between hosted mode and web mode, we recommend that you use int

> variables."http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.De...

[mP]

It probably would be a good idea if the compiler reported any long
types as errors just like float/doubles are invalid types in J2ME.
Theres no point having a long that doesnt really work. It just opens
the opportunity for problems like this one.

On Apr 4, 12:46 am, "Sandy McArthur" <sandy...@gmail.com> wrote:
> From the docs:
> "Intrinsic types
> byte, char, short, int, long, float, double, Object, String, and
> arrays are supported. However, there is no 64-bit integral type in
> JavaScript, so variables of type long are mapped onto JavaScript
> double-precision floating point values. To ensure maximum consistency
> between hosted mode and web mode, we recommend that you use int

> variables."http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.De...

[Reinier Zwitserloot]

except, of course, that longs are frequently used for timestamp stuff.
So getting errors or even warnings on longs would get real annoying
real fast. It's an unfortunate issue though.

[mP]

Reiner

We all love our longs, but given they have precision problems some of
the time, wouldnt it be best not to support them at all ?

The google team already changed a few timestamp like values from long
to int (aka the Timer class). I think supporting longs causes problems
due to the lower order bits getting lost due to precision issues. This
same question has appeared a few times, and no doubt has hurt many
other users in terms of wasted time.

At best the javascript runtime should attempt to support longs
properly so that all 64 bits are kept rather than the behaviour that
happens now. There are many hacks to get around to holding all 64 bits
worth, and maybe they should be considered.