[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch: Code to dump serialized objects
From: |
Warren Levy |
Subject: |
Re: Patch: Code to dump serialized objects |
Date: |
Fri, 3 Nov 2000 01:25:52 -0800 (PST) |
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