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
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
