Demoting and Promoting Serialised Objects

[Roedy Green]

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

 

[Boudewijn Dijkstra]

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.

 

[Roedy Green]

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

 

[Boudewijn Dijkstra]

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

 

[Roedy Green]

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