persistent object?

[SpreadTooThin]

I need a list of objects that can survive from one invocation of the
application to the next.
Is this doable in Java or does that break sand box rules?
In my case I simply need a list of structures to exist and be reloaded
if the application is quit and restarted.

 

[Knute Johnson]

I need a list of objects that can survive from one invocation of the
application to the next.
Is this doable in Java or does that break sand box rules?
In my case I simply need a list of structures to exist and be reloaded
if the application is quit and restarted.

Make them Serializable and write them to a file.

 

[Thomas Kellerer]

SpreadTooThin wrote on 27.04.2009 23:34:

I need a list of objects that can survive from one invocation of the
application to the next.
Is this doable in Java or does that break sand box rules?
In my case I simply need a list of structures to exist and be reloaded
if the application is quit and restarted.

Use XMLDecoder and XMLEncoder. Your objects must be JavaBeans though (default
constructor and a pair of set/get methods for each property that needs to be
persisted)

 

[Arne Vajhøj]

I need a list of objects that can survive from one invocation of the
application to the next.
Is this doable in Java or does that break sand box rules?
In my case I simply need a list of structures to exist and be reloaded
if the application is quit and restarted.

A Java application does typical not run in a sand box and are
therefore capable of writing and reading local files.

Java applets is another story.

Arne

 

[Arne Vajhøj]

Make them Serializable and write them to a file.

Just be aware that in case the class is changed then the
object may not be readable.

Arne

 

[Arne Vajhøj]

SpreadTooThin wrote on 27.04.2009 23:34:

Use XMLDecoder and XMLEncoder. Your objects must be JavaBeans though
(default constructor and a pair of set/get methods for each property
that needs to be persisted)

And Java 1.6 has JAXB which in many ways are doing a better
job than those two 1.4 classes.

Arne

 

[Andrew Thompson]

A Java application does typical not run in a sand box and are
therefore capable of writing and reading local files.

Java applets is another story.

Java applets (1.4+) have the AppletContext.getStreamKeys()*/
getStream()/setStream() methods, which might seem at
first look to be for inter-applet communication (and
can be used for that) but also, apparently, for
persistence. They are limited to around 63-64Kb.

*
<http://java.sun.com/javase/6/docs/api/java/applet/
AppletContext.html#getStreamKeys()>

Apps. launched using JWS are also subject to a sandbox
unless they are digitally signed & request/are granted
all-permissions or j2ee-application-client-permissions
(a horrid name for limited extra permissions, IMO).

Even sandboxed JWS apps. can access the PersistenceService
Demo of the persistence service.
<http://pscode.org/jws/api.html#ps>

 

[Lew]

Make them Serializable and write them to a file.

Be sure, if you follow this advice, that you take full responsibility for the
consequent contract. Implementing "Serializable" is a commitment.

 

[Mark Space]

SpreadTooThin wrote on 27.04.2009 23:34:

Use XMLDecoder and XMLEncoder. Your objects must be JavaBeans though
(default constructor and a pair of set/get methods for each property
that needs to be persisted)

I was unhappy with the design constraints XMLEncoder/Decoder forced on
my design when I used it last. If you have Beans, fine, it works great
and is a big time saver. But if you don't have beans,
XMLEncoder/Decoder force you to implement Bean semantics -- getters and
setters for every piece of saved data.

I had private data that the user had no business mucking with in my
design, and exposing that was a real negative for me. I'd recommend
using the Serializable interface, and then just biting the bullet and
implementing your own write and read methods. Then you sure of the
format and it won't change, and you have a reasonable implementation for
your IO framework.

<http://java.sun.com/developer/technicalArticles/Programming/serialization/>

 

[Lew]

I had private data that the user had no business mucking with in my
design, and exposing that was a real negative for me. I'd recommend
using the Serializable interface, and then just biting the bullet and
implementing your own write and read methods. Then you sure of the
format and it won't change, and you have a reasonable implementation for
your IO framework.

<http://java.sun.com/developer/technicalArticles/Programming/serialization/>

Serializable imposes restrictions on private attributes and makes them part of
the object's contract also. All of chapter 11 of Joshua Bloch's /Effective
Java/ is devoted to serialization. Right away it gets into that a class's
"serialized form ... becomes part of its exported API" and that "if you accept
the default serialized form, the class’s private and package-private instance
fields become part of its exported API".

 

[Roedy Green]

I need a list of objects that can survive from one invocation of the
application to the next.
Is this doable in Java or does that break sand box rules?
In my case I simply need a list of structures to exist and be reloaded
if the application is quit and restarted.

There are various way to do it. Have a look at
http://mindprod.com/jgloss/preferences.html for small amounts of data.

--
Roedy Green Canadian Mind Products
http://mindprod.com

"Nationalism is an infantile disease. It is the measles of mankind."
~ Albert Einstein

 

[Arne Vajhøj]

Be sure, if you follow this advice, that you take full responsibility
for the consequent contract. Implementing "Serializable" is a commitment.

The requirement was to be able to persist an object.

That is a commitment.

There are really not that much extra commitment by implementing
the Serializable interface to achieve that goal.

It just makes the commitment more visible, which is a good thing.

Arne

 

[Arne Vajhøj]

Java applets (1.4+) have the AppletContext.getStreamKeys()*/
getStream()/setStream() methods, which might seem at
first look to be for inter-applet communication (and
can be used for that) but also, apparently, for
persistence. They are limited to around 63-64Kb.

*
<http://java.sun.com/javase/6/docs/api/java/applet/AppletContext.html#getStreamKeys()>

According to http://forums.java.net/jive/thread.jspa?messageID=314755
then these streams are not really persisted but lost when the browser
is closed.

Arne

 

[Andrew Thompson]

....
According to http://forums.java.net/jive/thread.jspa?messageID=314755
then these streams are not really persisted but lost when the browser
is closed.

I see your right. That linked applet will lose the
changes after the browser is closed and reopened.

That is a pity for real world deployment (but handy to
know, since it was going to be a hassle to implement in
Appleteer*).

* <http://pscode.org/appleteer/>

I suppose that only leaves 'cookies' for persistence
in a sandboxed embedded applet that is pre 1.6.0_10.
<http://www.rgagnon.com/javadetails/java-0180.html>

Or, as you mentioned, the JNLP API for 1.6.0_10+
embedded applets.

 

[Andrew Thompson]

....
According tohttp://forums.java.net/jive/thread.jspa?messageID=314755
then these streams are not really persisted but lost when the browser
is closed.

Right you are. The linked applet supports it does
not work in FF 3..ish.

So that leaves (for a sandboxed, embedded applet)
cookies* or, for 1.6._10+, hooking into the JNLP API.

*
<http://www.rgagnon.com/javadetails/java-0180.html>

P.S. thought I'd already responded to this, but could
not see it in the group.

 

[Lew]

The requirement was to be able to persist an object.

That is a commitment.

There are really not that much extra commitment by implementing
the Serializable interface to achieve that goal.

It just makes the commitment more visible, which is a good thing.

Joshua Bloch disagrees with you, a little.

I agree with you, a lot. I wasn't claiming "extra" commitment, just the
commitment that serialization imposes. The problem is that many folks
implement 'Serializable' and think they're done and are not responsible for
the commitment that entails. Furthermore, 'Serializable' imposes some gotchas
that might not be obvious to some practitioners.

If it's not new news that you're taking on a lot of responsibility to use
'Serializable', so much the better. It is enough of a surprise to enough
people that it's worth mentioning. Joshua Bloch's major chapter on the
subject goes into the details. He also outlines many ways to lessen the burden.

 

[Arne Vajhøj]

Joshua Bloch disagrees with you, a little.

I agree with you, a lot. I wasn't claiming "extra" commitment, just the
commitment that serialization imposes. The problem is that many folks
implement 'Serializable' and think they're done and are not responsible
for the commitment that entails. Furthermore, 'Serializable' imposes
some gotchas that might not be obvious to some practitioners.

If it's not new news that you're taking on a lot of responsibility to
use 'Serializable', so much the better. It is enough of a surprise to
enough people that it's worth mentioning. Joshua Bloch's major chapter
on the subject goes into the details. He also outlines many ways to
lessen the burden.

But practically all the problems would be the same no matter how
the objects were persisted. If the objects need to be completely
reconstructed when read again then all implementation information
somehow has to be there.

I have a rather pragmatic view on that. Serialization is OK for
short term transfer like write to a socket. Serialization is bad for
long term transfer like saving in a file. If an object has to
be saved in a file, then I usually suggests XML. Sure it is possible
to make incompatible changes to the class later on, but with an
XML format it is much easier to convert a file from old to new
format.

Arne

 

[Lew]

But practically all the problems would be the same no matter how
the objects were persisted. If the objects need to be completely
reconstructed when read again then all implementation information
somehow has to be there.

I have a rather pragmatic view on that. Serialization is OK for
short term transfer like write to a socket. Serialization is bad for
long term transfer like saving in a file. If an object has to
be saved in a file, then I usually suggests XML. Sure it is possible
to make incompatible changes to the class later on, but with an
XML format it is much easier to convert a file from old to new
format.

XML serialization is serialization still. However, my comments are more
specific to the use of 'java.io.Serializable'. Because of the built-in
support in Java for that type, there are special considerations for it. I
agree with your points about short-term persistence and the advantages of XML
serialization. In addition, there are advantages to XML being human-readable
and cross-platform.