Robert Mitchell wrote: > It sounds like it would work OK, and it would eliminate the single array > copy my implementation has. You would have to worry about the special > case where your first CR is at the end of the buffer. You would also > have to implement something like what I wrote or read one byte at a > time for the case where mark is not supported. > > By the way, after thinking about it some more, it seems to me that the > only "safe" way to implement mark in CRLFInputStream is to double the > parameter before passing it to the "in" InputStream. For its current > uses the current implementation is probably safe, but for mark/resets > that enclose an arbitrary number of lines being read, it will not be > safe.
OK, I'll have a go bearing this in mind. > Personally, if re-architecting the inetlib/javamail design were > possible, I would eliminate CRLFInputStream and incorporate the CR > dropping into LineInputStream. I might also do what I expect Sun's > implementation does and where appropriate, require that the data use > CRLF as the end of line character. The problem is that some message sources will definitely not use CRLF as a line delimiter, e.g. the mbox and Maildir stores. Note that these stores are not supported by Sun's implementation either. -- Chris Burdess _______________________________________________ Classpath-inetlib mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-inetlib
