«

On Wed, 10 Sep 2008 19:42:41 +0100, Tom Anderson wrote:

>>> Why not? It means that you can write a program which opens text files
>>> and reads them without having to know which platform it's on. Which,
>>> since java is supposed to be platform-neutral, is rather useful in
>>> practice.
>>
>> Doesn't the java.io API already give us that capability in a
>> platform-neutral way? I know that BufferedReader#readLine(), for
>> example, handles all three forms of line-end sequences.
>
> That was my point! Java provides this. I read Martin's post as saying he
> thought that feature was "not usually all that useful in practice", and
> i disagree.
>
Peace. I keep forgetting about JWS applications, applets and similar. My
main point is the one that we agree on: readLine() doesn't belong as a
BufferedReader method.

Almost everything I've written has been code that in practise never
changes platforms and, judging by the number of threads on this NG that
discuss embedding OS-specific code and/or shell commands in Java
applications, its pretty far from those people's minds too.

Even the related use reading DOS/Windows text files on Linux boxes or
vice versa doesn't feature very often in my requirements, but ymmv.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

On Wed, 10 Sep 2008, Martin Gregorie wrote:

> On Wed, 10 Sep 2008 19:42:41 +0100, Tom Anderson wrote:
>
>>>> Why not? It means that you can write a program which opens text files
>>>> and reads them without having to know which platform it's on. Which,
>>>> since java is supposed to be platform-neutral, is rather useful in
>>>> practice.
>>>
>>> Doesn't the java.io API already give us that capability in a
>>> platform-neutral way? I know that BufferedReader#readLine(), for
>>> example, handles all three forms of line-end sequences.
>>
>> That was my point! Java provides this. I read Martin's post as saying he
>> thought that feature was "not usually all that useful in practice", and
>> i disagree.
>
> Peace. I keep forgetting about JWS applications, applets and similar. My
> main point is the one that we agree on: readLine() doesn't belong as a
> BufferedReader method.

True.

> Almost everything I've written has been code that in practise never
> changes platforms and, judging by the number of threads on this NG that
> discuss embedding OS-specific code and/or shell commands in Java
> applications, its pretty far from those people's minds too.
>
> Even the related use reading DOS/Windows text files on Linux boxes or
> vice versa doesn't feature very often in my requirements, but ymmv.

You're right that many uses don't need the cross-platform capability. Many
do - think of developing a server-side app on a windows box, then
deploying it on unix. What's probably very rare is needing to deal with a
variety of line endings *within a single file*, which is where most of the
complexity of readLine in java comes in. I like having the ability to do
that, but i suppose because it's reassuring, rather than for any actual
practical reason!

tom

--
It involves police, bailiffs, vampires and a portal to hell under a
tower block in Hackney.

On Thu, 11 Sep 2008 13:16:56 -0700, Mike Schilling wrote:

> Tom Anderson wrote:
>> You're right that many uses don't need the cross-platform capability.
>> Many do - think of developing a server-side app on a windows box, then
>> deploying it on unix. What's probably very rare is needing to deal with
>> a variety of line endings *within a single file*, which is where
>> most of the complexity of readLine in java comes in. I like having the
>> ability to do that, but i suppose because it's reassuring, rather
>> than for any actual practical reason!
>
> It would be nice if it were raer than it is. On Windows, it occurs with
> regrettable frequency when files have been edited with more than one
> editor in their lifetime.

I've met it in the Linux world with JavaMail.

JavaMail is overly picky with message header syntax, e.g. it is case
sensitive when it should not be (Content encoding headers), so some
messages are rejected. My app writes these to files where they can be
edited and resubmitted. By definition mail messages use CRLF line
terminators, but common Linux editors use LF, so fixing a message and
resubmitting it may force JavaMail to deal with a mixture of line
terminators in the one message - which fortunately it does.

This is the only place I've had to deal with mixed line terminators in a
single file. In all other cases dos2unix or unix2dos solves the problem.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |