Demoting and Promoting Serialised Objects

Discussion in 'Java' started by Roedy Green, Jul 5, 2005.

  1. Roedy Green

    Roedy Green Guest

    I see a general problem I call demoting and promoting objects.

    A Dog gets promoted to a Dalmatian object by gaining extra
    Dalmatian-specific fields.

    A Dalmatian gets demoted to Dog object by stripping off its Dalmatian
    specific fields.

    The object itself is unchanged. You create a new modified object and
    discard the old one.


    Why would you do such a thing?

    1. to strip and object down for export, serialisation, or RMI
    transport.

    2. to strip an object of confidential information before handing in
    on.

    3. to avoid having to give confidential code used to process, edit or
    construct your objects when all they will do is view them.

    The way you did the equivalent thing in COBOL was a MOVE CORRESPONDING
    that copied field by field. In Java traditionally you do the same
    thing writing code guaranteed to stop working the instant any of the
    class structure changes.

    How might you handle this more elegantly?

    1. a class parser then generates code to do the move-corresponding.

    2. Java gain some feature to easily create copy constructor so you
    could say:

    something like:

    /**
    * cloning constructor
    * Makes a Dog out of any Dog object including a Dalmatian object.
    * The new object will have only the Dog fields and methods, even if
    * cast back to the original type.
    */
    Dog ( Dog ) { Magic.copy(); }

    Where copy is some magic JNI or new Java feature.

    The assembler code theoretically could be just a block byte move of
    dog's object size bytes -- extremely fast compared with field by field
    copy.
    ..



    --
    Bush crime family lost/embezzled $3 trillion from Pentagon.
    Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
    http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
     
    Roedy Green, Jul 5, 2005
    #1
    1. Advertising

  2. "Roedy Green" <> schreef in bericht
    news:...
    >I see a general problem I call demoting and promoting objects.
    >
    > A Dog gets promoted to a Dalmatian object by gaining extra
    > Dalmatian-specific fields.
    >
    > A Dalmatian gets demoted to Dog object by stripping off its Dalmatian
    > specific fields.
    >
    > The object itself is unchanged. You create a new modified object and
    > discard the old one.
    >
    >
    > Why would you do such a thing?
    >
    > 1. to strip and object down for export, serialisation, or RMI
    > transport.


    Isn't this where readObject and writeObject would come in handy?

    > 2. to strip an object of confidential information before handing [it]
    > on.
    >
    > 3. to avoid having to give confidential code used to process, edit or
    > construct your objects when all they will do is view them.
    >
    > The way you did the equivalent thing in COBOL was a MOVE CORRESPONDING
    > that copied field by field. In Java traditionally you do the same
    > thing writing code guaranteed to stop working the instant any of the
    > class structure changes.
    >
    > How might you handle this more elegantly?
    >
    > 1. a class parser then generates code to do the move-corresponding.
    >
    > 2. Java gain some feature to easily create copy constructor so you
    > could say:
    >
    > something like:
    >
    > /**
    > * cloning constructor
    > * Makes a Dog out of any Dog object including a Dalmatian object.
    > * The new object will have only the Dog fields and methods, even if
    > * cast back to the original type.
    > */


    You cannot 'cast back to the original type', because it was lost in the
    conversion object.

    > Dog ( Dog ) { Magic.copy(); }
    >
    > Where copy is some magic JNI or new Java feature.


    Why not reflection?

    > The assembler code theoretically could be just a block byte move of
    > dog's object size bytes -- extremely fast compared with field by field
    > copy.


    Field by field copy bytecode could be automagically optimized into just that.
     
    Boudewijn Dijkstra, Jul 5, 2005
    #2
    1. Advertising

  3. Roedy Green

    Roedy Green Guest

    On Tue, 5 Jul 2005 18:19:48 +0200, "Boudewijn Dijkstra"
    <> wrote or quoted :

    >You cannot 'cast back to the original type', because it was lost in the
    >conversion object.


    Cached information in the object might be restored by accessing a
    database to refresh it. Some might be recomputed. It is just a more
    general problem of reconsituting transient fields.

    In most cases an object has one of three life cycle patterns:

    1. Starts out as a Dalmatian and gets stripped for export.

    2. Starts out as a Dog. Later your find out the breed and want to add
    that breed-specific information. You did not know it was going to be a
    Dalmatian to start so all you could do is temporarily create a dog.
    As you find out more information, you promote the object.

    3. You compress fat objects by demoting them, stripping them of their
    unused fields. If they ever need those fields again you promote them.
    Think here of situation where you have millions of objects and every
    byte counts in your Persistent Store.

    Think in terms of converting a record from a married to unmarried
    person and back.

    You want the convenience of treating Married as a subclass of Person,
    rather than as a separate Object of relevant-to-married fields.



    --
    Bush crime family lost/embezzled $3 trillion from Pentagon.
    Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
    http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
     
    Roedy Green, Jul 6, 2005
    #3
  4. "Roedy Green" <> schreef in bericht
    news:eek:...
    > On Tue, 5 Jul 2005 18:19:48 +0200, "Boudewijn Dijkstra"
    > <> wrote or quoted :
    >
    >>You cannot 'cast back to the original type', because it was lost in the
    >>conversion object.

    >
    > Cached information in the object might be restored by accessing a
    > database to refresh it. Some might be recomputed. It is just a more
    > general problem of reconsituting transient fields.
    >
    > In most cases an object has one of three life cycle patterns:
    >
    > 1. Starts out as a Dalmatian and gets stripped for export.
    >
    > 2. Starts out as a Dog. Later your find out the breed and want to add
    > that breed-specific information. You did not know it was going to be a
    > Dalmatian to start so all you could do is temporarily create a dog.
    > As you find out more information, you promote the object.


    Promoting an object may cause it to get a bigger heap segment, so it won't be
    much less an expensive operation than doing new Dalmation(dog).

    > 3. You compress fat objects by demoting them, stripping them of their
    > unused fields. If they ever need those fields again you promote them.
    > Think here of situation where you have millions of objects and every
    > byte counts in your Persistent Store.
    >
    > Think in terms of converting a record from a married to unmarried
    > person and back.
    >
    > You want the convenience of treating Married as a subclass of Person,
    > rather than as a separate Object of relevant-to-married fields.


    As we all know, wanting and getting are two very different things...
     
    Boudewijn Dijkstra, Jul 9, 2005
    #4
  5. Roedy Green

    Roedy Green Guest

    On Sun, 10 Jul 2005 00:13:40 +0200, "Boudewijn Dijkstra"
    <> wrote or quoted :

    >Promoting an object may cause it to get a bigger heap segment, so it won't be
    >much less an expensive operation than doing new Dalmation(dog).


    That is what promoting an object is. new Dalmatian( dog ), with some
    cleverness so you don't have to spell out a field by field copy in
    writing the constructor.

    Dog ( Dog d )
    should not require any more field-sensitive code than Dog.clone().

    Dalmatian ( Dog d, String extra )
    {
    super ( d );
    ....

    --
    Bush crime family lost/embezzled $3 trillion from Pentagon.
    Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
    http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
     
    Roedy Green, Jul 10, 2005
    #5
    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. Roedy Green

    renaming fields in serialised objects

    Roedy Green, Jul 2, 2005, in forum: Java
    Replies:
    5
    Views:
    362
    Roedy Green
    Jul 4, 2005
  2. Roedy Green
    Replies:
    7
    Views:
    526
    Roedy Green
    Feb 13, 2006
  3. Wladimir Borsov
    Replies:
    1
    Views:
    501
    Kimberly Lauren
    Aug 10, 2004
  4. Thomas Hawtin
    Replies:
    2
    Views:
    393
    Thomas Hawtin
    Dec 3, 2006
  5. Rob Nicholson

    StateServer - when is the session serialised?

    Rob Nicholson, Jul 3, 2008, in forum: ASP .Net
    Replies:
    2
    Views:
    377
    Rob Nicholson
    Jul 4, 2008
Loading...

Share This Page