From experience here, passing java.sql.Date as java.util.Date is
opening a barrel of woe.
Weird timezone issues start cropping up as java.sql.Date is not
supposed to have an hour/minute/second component with meaning and
would be better if timezone agnostic like LocalDate or
LocalDateTime, but it isn't.
Keep in mind when getting back dates from the client, that the time
zone of the client can cause you to generate a sql date that is off
by a day + or -.
If you need to pass dates back and forth that are being used in
database operations, make sure you take this into account, or just
use wrapped strings that are parsed on the client and server to
each's local time zone as needed.
Casting a subclass to a superclass is pretty much a no-op.
On 7/23/20 9:46 AM, Ralph Fiergolla
wrote:
I know it is quite some time ago since you posted
this, but I just now (2020!) ran into the very same issue (using
the very same workaraound). Is there any real solution for this
by now?
On Tuesday, August 22, 2006 at 2:32:24 AM UTC+2, StudyBlue
wrote:
Casting
'non-serializable' objects to 'serializable' objects alone is
not enough!
1. According to the serialization documentation for the
GWT,
java.util.Date is serializable.
(
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.SerializableTypes.html
)
2. According to the java docs, java.sql.Date is a subclass
of
java.util.Date.
( http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Date.html
)
3. According to you-can-look-it-up-yourself you can validly
cast a
subclass to the type of the superclass.
Intuitively, you should be able to send java.sql.Dates
across the RPC
boundary simply by casting them. Unfortunately, the
reflection calls
appear to look for the most specific type possible, not
necessarily
whatever it was cast to last. (Maybe that's intended.
Maybe I'm
totally off on my blind guess for what's causing this.) No
matter how
I cast I java.sql.Date to java.util.Date, the call would
always throw
an exception claiming I was trying to send a java.sql.Date.
Eventually
I got fed up with that and created a new java.util.Date from
the
java.sql.Date's getTime() method. Creating an entirely new
object
solved the problem, but I'm assuming that's taking more time
and
processing than a simple cast. If there's any way to make a
sufficient
cast, I'd love to hear it.
--
You received this message because you are subscribed to the Google
Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f971938a-06f4-403f-b737-161835da1bf8o%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/34f86b72-5e32-062e-7dbe-6271c0b1f7ce%40newsrx.com.
|