Support for java.util.Date

[Sanjiv Jivan]

Is java.util.Date supported as an intrinsic type? The "Language
Support" section of the docs doesn't explicitly state so but there are
some threads indicating that it might be supported. Can you clarify?

Thanks,
Sanjiv

[Bernard Choi]

Greetings,

java.util.Date is covered by the JRE emulation library. ( http://code.google.com/webtoolkit/documentation/java.util.html
 ) It should be supported. Where is this Language Support section that you are referring to ?

--
Well Wishes,
Bernard Choi

[Reinier Zwitserloot]

If you mean: Is Date a type like "String", "JavaScriptObject",
"Element", "Event", all java primitives (int, long, double, boolean,
etc), 'null', and arrays of aforementioned, in that it translates
seamlessly into JS objects when crossing the Java<->JSNI barrier?

In which case, I don't think so. Though in theory I guess it could be
turned into that. Not sure if it's worth the effort. A simple test
should suffice to figure this out if it's important to you.

If you were inquiring as to whether or not you can use it at all,
insert same incredulous "whatever makes you think it wouldn't? It's in
java.util.* and as a rule stuff in there is supported" reply in the
vein of Bernard's.

On May 29, 3:12 am, "Bernard Choi" <bch...@gmail.com> wrote:
> Greetings,
>

> java.util.Date is covered by the JRE emulation library. (http://code.google.com/webtoolkit/documentation/java.util.html

> ) It should be supported. Where is this Language Support section that you
> are referring to ?
>

[Amit Kasher]

Sanjiv,
java.util.Date is supported but the support is limited.
For instance, if you are assigning your entity with a date object from
the DB (that would be a java.sql.* (Date or Timestamp), which extend
java.util.Date), you will receive a serialization problem in the
client.
Also, SimpleDateFormatter is not available (yet), which makes it hard
to convert this date to a localized string.

I noticed many posts on this over time. Take a look; I'm sure you can
find more information.

[Sanjiv Jivan]

I should have been more clear in my original post. Yes, I'm referring
to the support of seamlessly passing Date objects across the Java -
JSNI layer. (http://code.google.com/webtoolkit/documentation/
com.google.gwt.doc.DeveloperGuide.JavaScriptNativeInterface.Marshaling.html)

I tried passing a Date across boundaries and got a NPE. I think it
would be very useful if GWT supported this. I was sorta expecting this
to work since there's a corresponding data type in each language. I am
using a calendar JS widget which returns a Date object. The widget
supports different formatting options but its API returns a Date
object. So in the absence of support of Date's across Java - JSNI, I
cannot retrieve the selection as a Date object and the String
representation of the date is not as useful as it could be formatted
for display differently.

I hope this makes sense.. support for Date's would definitely make the
JSNI API "less surprising".

Thanks,
Sanjiv

[Reinier Zwitserloot]

It's a one-liner to bridge this stuff. Just toss longs around
(millis). You can get them out of both java.util.Date and JS Date
objects, and you can create both java.util.Date and JS Date objects
with millis.

The only issue is granularity range. Where in java longs go into a
couple million years BC and AD, in javascript, because they are
secretly all doubles, they conk out at 30,000 AD or so. I mean, year
2k was a flub and all, but at the moment I'm not too worried about
apps that start skipping a couple of milliseconds about 30 thousand
years in the future :-P

I'm in tentative agreement that it would be nicer if they were bridged
automatically, and if you want you can take this up as an issue in the
issuetracker, but I suspect you'll have to provide the patch yourself
if you want any chance of this making it into GWT.

[Sanjiv Jivan]

I'll probably use your suggested workaround of passing dates as longs
but this is the kind of stuff you'd expect a library to do
transparently, especially from a high quality toolkit like GWT. I've
created an issue for this (Issue 1109).

The bridge would probably be a few more lines of boilerplate code
since JSNI doesn't support constructing a new Java object directly
(Issue 623). I'll probably toss in another factory method or chain two
method calls.

Thanks,
Sanjiv