Problems retrieving object through rmi

Discussion in 'Java' started by steen, Jun 15, 2007.

  1. steen

    steen Guest

    Hey,

    I've just started a job at a company maintaining their existing
    applications.
    They have a swing application which retrieves an object through rmi
    and this is where I've run into a problem.

    If I run the client code through Eclipse I get a
    Caused by: java.rmi.UnmarshalException: Error deserializing return-
    value: java.io.InvalidClassException:
    dk.company.core.shared.security.User; local class incompatible: stream
    classdesc serialVersionUID = 9118414514559389810, local class
    serialVersionUID = 5591922392715427412

    but if I run it through IDEA it works just fine.

    I'm thinking there is a problem with the java versions, but as far as
    I can see both eclipse and idea run with the same settings :
    Eclipse: jdk1.6.0_01 as compiler and 1.4 as "Generated .class files
    compatibility" and "Source compatibility"
    IDEA: same jdk1.6.0_01 as compiler and 1.4 as "Project language level"

    I'd prefer to use Eclipse for this but if I cant resolve this I guess
    I'll have to go with IDEA.

    Anyone got any ideas what setting in Ecilpse I'm missing ?

    /Steen
     
    steen, Jun 15, 2007
    #1
    1. Advertising

  2. steen

    Roedy Green Guest

    On Fri, 15 Jun 2007 03:26:03 -0700, steen <> wrote,
    quoted or indirectly quoted someone who said :

    >If I run the client code through Eclipse I get a
    >Caused by: java.rmi.UnmarshalException: Error deserializing return-
    >value: java.io.InvalidClassException:
    >dk.company.core.shared.security.User; local class incompatible: stream
    >classdesc serialVersionUID = 9118414514559389810, local class
    >serialVersionUID = 5591922392715427412


    The class files don't match. Makes sure the source is identical then
    Try a rebuild of the universe. You may just have some old class
    files. Make sure both Idea and Eclipse are pointing to the same
    version of the RMI libraries.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Jun 15, 2007
    #2
    1. Advertising

  3. steen

    steen Guest

    On Jun 15, 12:50 pm, Roedy Green <>
    wrote:

    > The class files don't match. Makes sure the source is identical then
    > Try a rebuild of the universe. You may just have some old class
    > files. Make sure both Idea and Eclipse are pointing to the same
    > version of the RMI libraries.


    I've dug around a bit and noticed that there was a slight difference
    in the class files for the object
    I'm trying to transfer, so if I on the server put the class file
    compiled by Eclipse it works,
    but why is there such a change? The jar-file for the server part was
    built using ant through Eclipse.
    I have a vague memory of someone telling me that Eclipse used its own
    compiler and not the default javac
    is this so? If so, is it possible to make Eclipse use the same javac
    as my ant build script does ?
    (I'm guessing here that compiling the same class twice with the same
    compiler would produce identical class-files)

    /Steen
     
    steen, Jun 15, 2007
    #3
  4. steen wrote:
    > On Jun 15, 12:50 pm, Roedy Green <>
    > wrote:
    >
    >> The class files don't match. Makes sure the source is identical then
    >> Try a rebuild of the universe. You may just have some old class
    >> files. Make sure both Idea and Eclipse are pointing to the same
    >> version of the RMI libraries.

    >
    > I've dug around a bit and noticed that there was a slight difference
    > in the class files for the object
    > I'm trying to transfer, so if I on the server put the class file
    > compiled by Eclipse it works,
    > but why is there such a change? The jar-file for the server part was
    > built using ant through Eclipse.
    > I have a vague memory of someone telling me that Eclipse used its own
    > compiler and not the default javac
    > is this so? If so, is it possible to make Eclipse use the same javac
    > as my ant build script does ?
    > (I'm guessing here that compiling the same class twice with the same
    > compiler would produce identical class-files)
    >
    > /Steen
    >


    Make sure that all the classes being serialised specify an explicit
    serialVersionUID, then it won't matter which compiler is used.

    Mark Thornton
     
    Mark Thornton, Jun 15, 2007
    #4
  5. steen

    steen Guest

    On Jun 15, 10:39 pm, Mark Thornton <mark.p.thorn...@ntl-spam-
    world.com> wrote:

    > Make sure that all the classes being serialised specify an explicit
    > serialVersionUID, then it won't matter which compiler is used.
    >


    Ah, of course. *slaps himself for not thinking of that!*
    I'm gonna try that monday morning, thanks..:)

    /Steen
     
    steen, Jun 15, 2007
    #5
  6. steen

    Nigel Wade Guest

    steen wrote:

    > On Jun 15, 10:39 pm, Mark Thornton <mark.p.thorn...@ntl-spam-
    > world.com> wrote:
    >
    >> Make sure that all the classes being serialised specify an explicit
    >> serialVersionUID, then it won't matter which compiler is used.
    >>

    >
    > Ah, of course. *slaps himself for not thinking of that!*
    > I'm gonna try that monday morning, thanks..:)
    >
    > /Steen


    But don't forget that you are now responsible for maintaining the UID. If you
    change the class in any meaningful way (such that the data which is serialized
    will be different) then you should update the serialVersionUID. The prevents a
    class with one UID attempting to de-serialize objects with a different UID, and
    hence incompatible contents.

    --
    Nigel Wade, System Administrator, Space Plasma Physics Group,
    University of Leicester, Leicester, LE1 7RH, UK
    E-mail :
    Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
     
    Nigel Wade, Jun 18, 2007
    #6
  7. steen

    Esmond Pitt Guest

    Nigel Wade wrote:
    > But don't forget that you are now responsible for maintaining the UID. If you
    > change the class in any meaningful way (such that the data which is serialized
    > will be different) then you should update the serialVersionUID. The prevents a
    > class with one UID attempting to de-serialize objects with a different UID, and
    > hence incompatible contents.


    No no no. That will break your downward compatilibity. Serialization
    already supports versioning to a great extent. As long as you stay
    within the rules there is no need to change the serialVersionUID at all
    and it is a practice to be actively discourage. The applicable rules are
    defined in the Serialization Specification but they amount basically to
    not deleting fields, not changing inheritance, and not change the types
    of fields. There's an awful lot you can accomplish within those limits.
    If you have to go outside them you should then use one of the available
    serialization mechanisms to render the new class
    serialization-compatible with the old one, and there is an awful lot
    more you can do within these mechanisms.

    If you *want* to break backwards compatibility, and lose contact forever
    with any persistent serializations you may have done, then change the
    serialVersionUID. Not otherwise.
     
    Esmond Pitt, Jun 19, 2007
    #7
  8. steen

    Nigel Wade Guest

    Esmond Pitt wrote:

    > Nigel Wade wrote:
    >> But don't forget that you are now responsible for maintaining the UID. If you
    >> change the class in any meaningful way (such that the data which is

    serialized
    >> will be different) then you should update the serialVersionUID. The prevents

    a
    >> class with one UID attempting to de-serialize objects with a different UID,

    and
    >> hence incompatible contents.

    >
    > No no no. That will break your downward compatilibity.


    Yes, yes, yes. If you break the backwards compatibility then you must change the
    UID, or face the consequences.

    > Serialization
    > already supports versioning to a great extent. As long as you stay
    > within the rules there is no need to change the serialVersionUID at all
    > and it is a practice to be actively discourage. The applicable rules are
    > defined in the Serialization Specification but they amount basically to
    > not deleting fields, not changing inheritance, and not change the types
    > of fields. There's an awful lot you can accomplish within those limits.
    > If you have to go outside them you should then use one of the available
    > serialization mechanisms to render the new class
    > serialization-compatible with the old one, and there is an awful lot
    > more you can do within these mechanisms.


    What I said was that if you change the contents of the serialized object then
    you must manually alter the UID. That remains valid no matter how many rules
    and tools you use to try to circumvent it.

    >
    > If you *want* to break backwards compatibility, and lose contact forever
    > with any persistent serializations you may have done, then change the
    > serialVersionUID. Not otherwise.


    Like I said...

    --
    Nigel Wade, System Administrator, Space Plasma Physics Group,
    University of Leicester, Leicester, LE1 7RH, UK
    E-mail :
    Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
     
    Nigel Wade, Jun 19, 2007
    #8
  9. steen

    Esmond Pitt Guest

    Nigel Wade wrote:

    > Yes, yes, yes. If you break the backwards compatibility then you must change the
    > UID, or face the consequences.


    But if you don't, don't. And please read the Serialization/Versioning
    spec carefully before you decide that you have broken backwards
    compatibility. Better still, design so that you don't ever do this.

    > What I said was that if you change the contents of the serialized object then
    > you must manually alter the UID.


    And this is still not correct. See the Serialization/Versioning spec, or
    my hasty summary of it. You can change a serializable class in lots of
    ways without breaking serialization-compatibility. In a practical
    production system it behoves you to keep compatibility in mind at all
    times, and to have an *accurate* view of what that actually means in
    practice. This means reading the Serialization specification, the
    section on Versioning, no two ways about it.
     
    Esmond Pitt, Jun 20, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?ZG90bmV0dGVzdGVy?=

    Retrieving mailbox information through ADSI

    =?Utf-8?B?ZG90bmV0dGVzdGVy?=, Aug 31, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    446
    =?Utf-8?B?ZG90bmV0dGVzdGVy?=
    Aug 31, 2005
  2. Buu Nguyen

    RMI, JINI or RMI/IIOP

    Buu Nguyen, Aug 25, 2004, in forum: Java
    Replies:
    1
    Views:
    595
    Sudsy
    Aug 25, 2004
  3. Sri Ramaswamy

    File copy through RMI

    Sri Ramaswamy, Dec 13, 2004, in forum: Java
    Replies:
    2
    Views:
    5,584
  4. JScoobyCed

    RMI Vs RMI over IIOP

    JScoobyCed, Jan 28, 2005, in forum: Java
    Replies:
    1
    Views:
    768
    Dag Sunde
    Jan 28, 2005
  5. Jan Schulze
    Replies:
    1
    Views:
    594
    Esmond Pitt
    Mar 26, 2005
Loading...

Share This Page