• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RMI: JDK version interoperability

 
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?

 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic