complaint about readLine()

[Jon Dornback]

does anyone know why BufferedReader.readLine() does not return the end of line character(s)?? this is very aggravating because the function is very convenient for reading files and streams, but i often need to keep the endline chars in tact because the file could be from unix or windows, and if i try and send the input of one stream to the output of another, the server is often waiting for an endline before it reads the stream because it is using something akin to readLine. guess i should stop complaining and write my own function. thanks for putting up with my ranting - had to get that off my chest.

[Jim Yingst]

Well, I suppose the reason is that most of the people using BufferedReader don't care what the end of line is, and putting in a method to recover it would be a slight additional complication no one saw the need for. If you really need it, yes your best bet is to write your own. You might consider using the source code for BuffereReader as a starting point, and making your own modified version.
Note that in the event you're just copying a file without changing any of its contents, you don't really need readLine() anyway. You'd be best off with read(char[]) or the read(byte[]) of a BufferedInputStream. And I'm thinking that if you are altering the data in any way, chances are you should really know whether you want \n or \r\n (or just \r) in the target file before you write it, and just put that in for every line. It's true there are some applications where this either isn't true or isn't possible, but I believe that's relatively rare. YMMV.
Anyway, good luck...

[Jon Dornback]

i've been reading up on java 1.4 nio package, and i will definitely be switching to SocketChannels to take advantage of non-blocking io. since there is no readLine method, a custom method is the way to go! thanks for the tips - i will look in to the original readline method for guidance.

[Tim Holloway]

Actually the reason is that if you're using readLine, you not only shouldn't KNOW what the end-of-line character is, you shouldn't CARE! Write-once/Run-anywhere! You'll also get a rude shock if you expect println() to always put the same end-of-line sequence out. If you want binary-level fidelity, you have to use binary-level I/O.
In fact, readLine(), like most equivalent C library implementations isn't supposed to care whether the line ends with a nl or a cr/lf. Just as it's legal (not to mention safer!) to code Java File paths for Windows using the Unix-style forward-slash syntax. It's all supposed to be handled transparently by your runtime library.
Note that having an actual end-of-line character is a DOS/Unix/Macintosh characteristic. IBM mainframes historically used a record-length indicator and EBCDIC encoding.