Thursday, July 23, 2020

Re: java.sql.Date - java.util.Date serialization issue

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+unsubscribe@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.

No comments:

Post a Comment