Re: debug output problem in ObjectInputStream

[Warren Levy]

Per Bothner wrote:
> I've appended one fix, but I'm not sure what the best approach is.
> The simplest would be to just rip out all the dumpElement code.

Well, I'd hesitate to just rip it out.  The dumping code is extremely
helpful when dealing with serialization issues.

> Next simplest is to move all the Configuration.DEBUG && dump
> tests out of dumpElement[ln] and to the call sites.

I'd rather go with this approach than losing the capability to dump.

> Having dumpElement[ln] as separate
> methods has the advantage that it could over overridden, but
> it seems like poinles generality.

It wasn't so much an issue of it being overridden, as it seemed like
a much cleaner approach than having separate conditionals and println's
spread throughout the code.  I found it very helpful when debugging to
just set a breakpoint for dumpElement; if we get rid of the method and
sprinkle the code with the conditional and prints, we'll lose that ease
in debugging.  Having a separate dumpElement method also certainly improved 
readability of the code (at least IMO).  I'm fine though with readability 
and ease of debugging suffering a little bit, if it avoids needless 
processing in the typical case.

> So if we want to keep the
> debugging printout, I suggest:
> 
>    if (Configuration.DEBUG && dump)
>      for (int i=0, len=Array.getLength(array); i < len; i++)
>        System.out.println("  ELEMENT[" + i + "]=" + Array.get(array, i));

This seems cleaner than also breaking it out into multiple print calls.

I'd offer to make the changes myself but I'm not in a position to get
them in on the 3.1 branch at this time (nor the trunk for that matter).
I'm updating my paperwork with the GNU Project and then I'll be able to 
get my cvs access updated to allow me to commit changes to both gcj and 
Classpath.
--warrenl