• 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

Saving state of an object

 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I just want to figure out that is there any way to save the state of an object of a class which does not implement Serializable or Extenalizable?.

If yes, how can i do that? please help me out.

Thanx
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is it a JavaBean (or JavaBean object graph)? What about XML serialization - i.e. java.beans.XML(En|De)coder?

- Peter
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perhaps something like XStream ("XStream is a simple library to serialize objects to XML and back again.") more at: http://xstream.codehaus.org/

There is a short tutorial on its use here: http://xstream.codehaus.org/tutorial.html but nice to know you can de/serialize custom objects without the need for mapping files etc, check out the features list on the project homepage (first linked above).

XStream is an open source project (BSD Style License)
 
Vicky Jain
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello guys,

Thanks for your posts, meanwhile i have found that the state of the object can be saved by writing the value of each and every instance variable into the persistent storage.

Am I going to the right direction....

Chao..
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think you are on the right track, because - unless you are using reflection with access checking off - you cannot get at the field values unless they are something other than private. Opening fields up like that is generally bad OO.

If you expose them using JavaBean style getters and setters, they you can just as well use the standard serialization mechanism for that: XML serialization.

- Peter
 
Vicky Jain
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Peter,

Well the class I'm talking about is not the JavaBean. Its a plain Java class having some instance members...

Is it possible now..?
 
Dan Pollitt
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vicky,

Perhaps if you are allowed you could give us some more information about your class (source code if not too big) then we could suggest approaches that might be most suitable.

Things that will affect which method to choose are whether you have control of the interface (to add public gettXXX() and setXXX(x) methods) being a java bean is basically having a no argument constructor and getter and setter methods for each instance property. If however you want to maintain "good" object orientation then exposing these properties (the internal state of the object) violates encapsulation. Some of the persistance frameworks will use reflection to access the state of an object but without you having to reveal or use these accessors in your code.

Of course you can construct/deconstruct your object by hand - but the joy of using some of the open source persistence frameworks is that you aren't reinventing the wheel and being open-source the solutions are usually of very high quality. Also if you change your class later then you will alsoo have to update your bespoke persistance methods whereas a 3rd party framework will usually adapt as it relies on reflection to interrogate an object and so no updates would be necessary.

Dan
[ July 26, 2004: Message edited by: Dan Pollitt ]
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can use classes like java.lang.reflect.Field to recursively get the primative fields from the class object and save those. This could be written so that it works with any class object - might have already been done.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rovas Kram:
You can use classes like java.lang.reflect.Field to recursively get the primative fields from the class object and save those. This could be written so that it works with any class object - might have already been done.

It has been done... it's called "serialization" The thing is that you cannot in general do this blindly; for example, some of the state may refer to resources such as sockets or files that cannot be externalised. That is where infrastructure such as Serializable, Externalizable and "transient" comes in.

- Peter
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peter den Haan:
Is it a JavaBean (or JavaBean object graph)? What about XML serialization - i.e. java.beans.XML(En|De)coder?

- Peter



if it were a proper bean it would implement Serializable which is a requirement according to the Java Beans API.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeroen Wenting:
Is it a JavaBean (or JavaBean object graph)? What about XML serialization - i.e. java.beans.XML(En|De)coder?
if it were a proper bean it would implement Serializable which is a requirement according to the Java Beans API.

Ok. Let me rephrase that.

Is it a Java class with a zero-argument constructor and property accessors following the JavaBean method naming patterns, or with an associated BeanInfo object facilitating access to the properties, but not necessarily Serializable or Externalizable and therefore not necessarily formally a JavaBean[tm]; or an object graph of Java classes with zero-argument constructors and property accessors following the JavaBean method naming patterns, or with BeanInfo objects, but not necessarily Serializable or Externalizable and therefore not necessarily formally an object graph of JavaBean[tm]s? What about XML serialization - i.e. java.beans.XML(En|De)coder?

You're right, it's so much better now that we've cleared that up.

- Peter
[ July 29, 2004: Message edited by: Peter den Haan ]
 
Rovas Kram
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

It has been done... it's called "serialization" The thing is that you cannot in general do this blindly; for example, some of the state may refer to resources such as sockets or files that cannot be externalised. That is where infrastructure such as Serializable, Externalizable and "transient" comes in.



Why don't we ask Vicky if the data that she wants to save includes either a socket connection or a file(yah right). She can't use XMLEncoder if here class does not implement Serializable - whether it really can be serialized or not.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rovas Kram:
She can't use XMLEncoder if here class does not implement Serializable [...]

Why not? As long as the public property accessors are sufficient to save and restore the bean's state - and do return either primitives or objects that can be persisted in the same way - things are fine. And even where this is not the case all is not lost: you can provide your own PersistenceDelegate for a bean to customise XML persistence.

- Peter
[ July 31, 2004: Message edited by: Peter den Haan ]
 
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you are encountering problems using the language mechanisms for saving object state due to limitations of the design itself, you might find the Memento design pattern useful. Of course, once you create a Memento, objects of that class would have to be serializable/externalizable/XMLizable/save-able just the same...

sev
 
Rovas Kram
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Why not? As long as the public property accessors are sufficient to save and restore the bean's state



You're right. The class object does not have to implement Serializable in order to be encoded by XMLEncoder.

My vote is for XMLEncoder - very simple.
reply
    Bookmark Topic Watch Topic
  • New Topic