persistent object?

Discussion in 'Java' started by SpreadTooThin, Apr 27, 2009.

  1. 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.
     
    SpreadTooThin, Apr 27, 2009
    #1
    1. Advertising

  2. SpreadTooThin wrote:
    > 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.

    --

    Knute Johnson
    email s/nospam/knute2009/

    --
    Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
    ------->>>>>>http://www.NewsDemon.com<<<<<<------
    Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
     
    Knute Johnson, Apr 27, 2009
    #2
    1. Advertising

  3. 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)
     
    Thomas Kellerer, Apr 27, 2009
    #3
  4. SpreadTooThin

    Arne Vajhøj Guest

    SpreadTooThin wrote:
    > 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, Apr 28, 2009
    #4
  5. SpreadTooThin

    Arne Vajhøj Guest

    Knute Johnson wrote:
    > SpreadTooThin wrote:
    >> 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.


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

    Arne
     
    Arne Vajhøj, Apr 28, 2009
    #5
  6. SpreadTooThin

    Arne Vajhøj Guest

    Thomas Kellerer wrote:
    > 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)


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

    Arne
     
    Arne Vajhøj, Apr 28, 2009
    #6
  7. On Apr 28, 10:15 am, Arne Vajhøj <> wrote:
    > SpreadTooThin wrote:
    > > 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.


    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>

    --
    Andrew T.
    pscode.org
     
    Andrew Thompson, Apr 28, 2009
    #7
  8. SpreadTooThin

    Lew Guest

    Knute Johnson wrote:
    > 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.

    --
    Lew
     
    Lew, Apr 28, 2009
    #8
  9. SpreadTooThin

    Mark Space Guest

    Thomas Kellerer wrote:
    > 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)



    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/>
     
    Mark Space, Apr 28, 2009
    #9
  10. SpreadTooThin

    Lew Guest

    Mark Space wrote:
    > 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".

    --
    Lew
     
    Lew, Apr 28, 2009
    #10
  11. SpreadTooThin

    Roedy Green Guest

    On Mon, 27 Apr 2009 14:34:48 -0700 (PDT), SpreadTooThin
    <> wrote, quoted or indirectly quoted someone who
    said :

    >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
     
    Roedy Green, Apr 28, 2009
    #11
  12. Lew wrote:
    > Knute Johnson wrote:
    >> 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.


    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, Apr 29, 2009
    #12
  13. SpreadTooThin

    Arne Vajhøj Guest

    Andrew Thompson wrote:
    > On Apr 28, 10:15 am, Arne Vajhøj <> wrote:
    >> SpreadTooThin wrote:
    >>> 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.

    >
    > 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
     
    Arne Vajhøj, Apr 29, 2009
    #13
  14. On Apr 29, 10:03 am, Arne Vajhøj <> wrote:
    > Andrew Thompson wrote:
    > > On Apr 28, 10:15 am, Arne Vajhøj <> wrote:
    > >> SpreadTooThin wrote:
    > >>> I need a list of objects that can survive from one invocation of the
    > >>> application to the next.

    ....
    > >> 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.  

    ....
    > 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 T.
    pscode.org
     
    Andrew Thompson, Apr 29, 2009
    #14
  15. On Apr 29, 10:03 am, Arne Vajhøj <> wrote:
    ....
    > > Java applets (1.4+) have the AppletContext.getStreamKeys()*/
    > > getStream()/setStream() methods, ...for
    > > persistence.  

    ....
    > 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.

    --
    Andrew T.
    pscode.org
     
    Andrew Thompson, Apr 29, 2009
    #15
  16. SpreadTooThin

    Lew Guest

    Arne Vajhøj wrote:
    > Lew wrote:
    >> Knute Johnson wrote:
    >>> 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.

    >
    > 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.

    --
    Lew
     
    Lew, Apr 29, 2009
    #16
  17. Lew wrote:
    > Arne Vajhøj wrote:
    >> Lew wrote:
    >>> Knute Johnson wrote:
    >>>> 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.

    >>
    >> 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.


    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
     
    Arne Vajhøj, May 3, 2009
    #17
  18. SpreadTooThin

    Lew Guest

    Lew wrote:
    >> 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 wrote:
    > 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.

    --
    Lew
     
    Lew, May 3, 2009
    #18
    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. Marc Floessel
    Replies:
    0
    Views:
    439
    Marc Floessel
    Jul 9, 2004
  2. =?Utf-8?B?QWxleCBNYWdoZW4=?=

    Accessing a Persistent Object throughout a user session

    =?Utf-8?B?QWxleCBNYWdoZW4=?=, Apr 10, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    517
    Steven Cheng[MSFT]
    Apr 14, 2006
  3. Replies:
    5
    Views:
    456
  4. gk
    Replies:
    7
    Views:
    978
    Tom Anderson
    Oct 12, 2010
  5. Abe Vionas_MailingList
    Replies:
    1
    Views:
    127
    George Moschovitis
    Oct 26, 2004
Loading...

Share This Page