GWT 1.5: Get Ready to Fix All of Your JSNI that Uses long

Dietrich Kappe, Thursday, April 3, 2008 @ 12:58 pm

I've been humming along with GWT 1.5, reading the release notes and compiling from trunk. Today I had a nasty little surprise. All of my JSNI code that used long as either a parameter or return value stopped working. So, something like the following...

public native long method(long param) /*-{
   // do something useful
}-*/;

...would throw a nice little exception in hosted mode:

Return value of type 'long' is an opaque, non-numeric value in JS code
Parameter 'value': 'long' is an opaque, non-numeric value in JS code

The reason for this is that internally, GWT stores longs as an array of
two JavaScript numbers (doubles, essentially) -- the high bits and the
low bits -- to retain precision. When you add those two quantities
together to convert to a single number, you may lose precision. The
code for dealing with long's is in com.google.gwt.lang.LongLib.

The
change is that rather than converting long's back and forth with
possible loss of precision, GWT 1.5 now sends and expects that
array of two numbers. I had some longs in JSNI flying around to deal
with some squirrelly browser date logic and had to retool to work
without JSNI. A discussion of the issue can be found here.

Anyhow,
make sure to go through all of your library and other code to search
for use of longs in JSNI, otherwise this may come and bite you. One naive workaround is to pass in and return doubles. Do make sure to write tests so that date logic, for example, doesn't break (you do know about the 2038 Problem, evil cousin of the Y2K problem, don't you?).

Technorati Tags: ajax, gwt, jsni, long, java

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment