Re: Classpath / GCJ java.io Merge

[Tom Tromey]

>>>>> "Aaron" == Aaron M Renn <address@hidden> writes:

[ DataOutputStream ]

Aaron> Those shared methods can die, IMO.  They don't do much.  The
Aaron> allocation is an interesting point.  Classpath does it to avoid
Aaron> doing what gcj does: namely do tons of single byte writes.
Aaron> This would be hideously expensive in the JNI world.  Is
Aaron> allocation still a problem?

For me the swaying argument is that if there is a lot of allocation
inside the class, the user can't do anything about it.  But if there
are too many short writes, he can add a buffer.

In private mail (Aaron and I have had a conversation about this
off-list) I said that the performance of DataInputStream and
DataOutputStream probably doesn't matter.  But while looking elsewhere
today I found that serialization uses these classes.  So maybe
performance here is important.

We could always add a `byte[8]' buffer to these classes.
Synchronization isn't that expensive.  Or, for DataInputStream, we
could just leave it unsynchronized, like libgcj currently does -- I
don't know when it would make sense for two threads to read from a
DataInputStream.

>> For PrintStream it looks like there were conflicting goals.  From
>> libgcj:

Aaron> Hmm.  I kinda liked the Classpath approach, assuming it's
Aaron> actually a valid implementation strategy, because I'm lazy by
Aaron> nature.

Yeah, me too.  And I dislike duplication.

I notice the libgcj implementation routes everything through the
print(...,boolean) methods in PrintStream.  Presumably this is to make
it easier to subclass.  I haven't looked to see whether this behavior
is specified.

Tom