• Post Reply Bookmark Topic Watch Topic
  • New Topic

RMI: JDK version interoperability

 
Panagiotis Varlagas
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Esmond Pitt, in his java.rmi book, mentions that "it is perfectly
possible to deploy systems where servers use a different version of the
JDK from clients".


Since the book is a 2001 one (no newer books on RMI exist), it
discusses JDK 1.3. Indeed, I have tested interoperability of a 1.2.2
client with a 1.3.1 server in two different environment and it works
just fine.


However, with a 1.4.2 server I get the following exception:


java.rmi.UnmarshalException: error unmarshalling return; nested
exception is:
java.lang.ClassNotFoundExcepti�on: sun.util.calendar.ZoneInfo
java.lang.ClassNotFoundExcepti�on: sun.util.calendar.ZoneInfo
at java.lang.Throwable.<init>(Thr�owable.java:96)
at java.lang.Exception.<init>(Exc�eption.java:44)
at
java.lang.ClassNotFoundExcepti�on.<init>(ClassNotFoundExcepti�on.java:7
1)
at
java.io.ObjectInputStream.inpu�tObject(ObjectInputStream.java�:1200)
at
java.io.ObjectInputStream.read�Object(ObjectInputStream.java:�479)
at
java.io.ObjectInputStream.read�Object(ObjectInputStream.java:�234)
at
sun.rmi.server.UnicastRef.unma�rshalValue(UnicastRef.java:304�)
at sun.rmi.server.UnicastRef.invo�ke(UnicastRef.java:96)
at
npmt.cli.common.base.NVNovaCom�monDataImpl_Stub.getServerTime�zone(NVNo
vaCommonDataImpl_Stub.java:157�)
at
npmt.cli.common.base.NovaCommo�nData.getTheTimezone(NovaCommo�nData.jav
a:639)
at
npmt.cli.common.NovaLogon.butt�onOk_ActionPerformed(NovaLogon�.java:76)


Could you please advise whether it is possible to have a 1.2.2 client /
1.4.2 server configuration?


Many thanks in advance!
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Panagiotis Varlagas
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!