Re: Patch: Code to dump serialized objects

[Warren Levy]

On Fri, 3 Nov 2000, Bryce McKinlay wrote:

> Warren Levy wrote:
> 
> > I've instrumented java.io.ObjectInputStream to work as a serialized object
> > dumper by reworking the commented out debug statements in the module.
>
> This sounds cool! However, since we're trying to create a _compatible_ Java 
> implementation, adding new public methods to the
> standard classes is a bad idea!
>
> Instead, I would suggest that this stuff gets activated via a system property 
> (eg "gcj.dumpobjects") that can be set either by
> calling "System.setProperty()" or by using the -D option at compile-time.

Yeah, I thought about the issue with adding a new public method but
hadn't considered about using system properties as a way to get around it.
Thanks!  I'll try to rework that next week, but I've got to take care
of some other responsibilities first (so I may not get to it for a little
bit).
 
> Even better, why not make a small utility (ala 'jcf-dump') that hooks into 
> ObjectInputStream and gets installed with libgcj, ie
> 'ser-dump' or something?

I thought about this, but decided I preferred instrumenting the code this
way to get the benefit of being able to trace/debug as the object is being
deserialized.  I figured that there would be times when this is valuable
and just having a small utility that understood the format might not
always cut it (e.g. esp. in cases where the data is being massaged by the
object or with special read*() methods called directly from the
serializable class's readObject() ).

Also, I think I've run into a couple things in the
ObjectInputStream.readObject code that I don't think quite work right, so
I figured instrumenting it this way would be helpful in fixing those (as
well as helping out if/when there are additions to the Object
Serialization spec and new code has to be added/debugged/maintained).

I suppose it wouldn't hurt to have both.
--warrenl