Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Problems retrieving object through rmi

Reply
Thread Tools

Problems retrieving object through rmi

 
 
steen
Guest
Posts: n/a
 
      06-15-2007
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

 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      06-15-2007
On Fri, 15 Jun 2007 03:26:03 -0700, steen <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
steen
Guest
Posts: n/a
 
      06-15-2007
On Jun 15, 12:50 pm, Roedy Green <(E-Mail Removed)>
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

 
Reply With Quote
 
Mark Thornton
Guest
Posts: n/a
 
      06-15-2007
steen wrote:
> On Jun 15, 12:50 pm, Roedy Green <(E-Mail Removed)>
> 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
 
Reply With Quote
 
steen
Guest
Posts: n/a
 
      06-15-2007
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

 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      06-18-2007
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 : http://www.velocityreviews.com/forums/(E-Mail Removed)
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
 
Reply With Quote
 
Esmond Pitt
Guest
Posts: n/a
 
      06-19-2007
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.

 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      06-19-2007
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 : (E-Mail Removed)
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
 
Reply With Quote
 
Esmond Pitt
Guest
Posts: n/a
 
      06-20-2007
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Object creation - Do we really need to create a parent for a derieved object - can't the base object just point to an already created base object jon wayne C++ 9 09-22-2005 02:06 AM
Why does java.rmi.Naming not implement interface java.rmi.Registry? Jan Schulze Java 1 03-26-2005 07:45 AM
RMI Vs RMI over IIOP JScoobyCed Java 1 01-28-2005 09:54 AM
File copy through RMI Sri Ramaswamy Java 2 12-15-2004 02:07 AM
RMI, JINI or RMI/IIOP Buu Nguyen Java 1 08-25-2004 11:28 AM



Advertisments