Re: [Classpath-inetlib] Problems in gnu.inet.util.LineInputStream and gnu.inet.util.CRLFInputStream

[Robert Mitchell]

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.

 

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.

 

Bob Mitchell.

>>> Chris Burdess <address@hidden> 4/4/2005 1:24 PM >>>

Robert Mitchell wrote:
> On giving you a patch, I unfortunately do not have an easy access to
> diff:  unfortunately I do my development on Windows and do not have a
> Windows version of diff at this point.  I am attaching a version of
> the file with Unix style end of lines.

Looks good.

Revisiting this code, I feel convinced that another approach could work
more efficiently. Basically we ensure that the underlying stream
supports mark and reset, and use these to return only CRLF delimited
chunks of bytes in any one read (there may be reads that don't hit a
boundary). In this way we save a lot of array copying.

What do you think? If you have reasonable doubts, I am happy to apply
your patch.
--
Chris Burdess