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