Many thanks Ernest! Actually, I reached the same conclusion independently too :-) What I did is adapt the old TimeZone and TimeZoneData classes, creating my own (say XxxTimeZone and XxxTimeZoneData), and use XxxTimeZone.getDefault() rather than TimeZone.getDefault(). The Xxx- classes explicitly return SimpleTimeZone objects, which is what I want(actually my client wants it :-). This way, I am able to resist technological progress and mimic a 1.3.1 (and 1.2.2 too) TimeZone-generating situation, while running my server on 1.4.2...
So it seems that unlike 1.1.8-1.2.2, 1.1.8-1.3.1, and 1.2.2-1.3.1 client-server pairs (the former two pairs with some tweaks), you can't simply take your 1.2.2 or 1.3.1 server code and put it to run on 1.4.2 without any code modifications. At least I hope that there will not be many such issues.
Thanks again.
Panagiotis.
Originally posted by Ernest Friedman-Hill:
It's not the JDK version that matters so much as what classes you're trying to send over the wire. It looks like there's a problem with exchanging objects of type "sun.util.calendar.ZoneInfo," which sounds like it's part of the Date or Calendar implementation, and indeed, looking down the stack I see the server method is named getServerTime�zone(); you must be exchanging TimeZone objects. Can you modify the code to just exchange timezone names as Strings instead of TimeZone objects?