[jdom-interest] end-of-line character

[Elliotte Rusty Harold]

At 1:11 AM -0700 7/6/00, Alex Chaffee wrote:
>On Wed, Jul 05, 2000 at 01:06:11PM -0700, Jason Hunter wrote:

>Let's make it an option.  XMLOutputter should have a
>"setLineEnding(String)" method; that should extract a char[] and stash
>it in an instance var like the code I posted, for efficiency.
>

That's reasonable, though I'd prefer to store it as a string.

>Now the only debate becomes: what should the *default* line ending
>sequence be.  Here my reasoning is clear (and hopefully sound):
>
>* JDOM is all about Java
>

True.

>* Java has a system property called "line.separator"
>

True.

>* The value of "line.separator" is used in every java.io class that
>has a concept of outputting line endings (to wit, PrintStream and
>PrintWriter).
>

PrintStream and PrintWriter are both EVIL. They cause major problems 
for network programs, and should not be used on the network. For that 
matter, outside of debugging to System.out I don't use them at all. I 
discuss this extensively in Java I/O, and even more in the upcoming 
second edition of Java Network Programming. If you like I'll send you 
a copy.

>* Therefore, more people will expect JDOM to use "line.separator" when
>outputting lines.

No, they won't. Most Java developers don't know line.separator 
exists. That's why there's so much code written with \n.

>
>Those who are paranoid, or have platform-independent file
>requirements, can say outputter.setLineEnding("\r\n") and everything's
>cool and explicit.
>

I am totally and completely opposed to making JDOM output platform 
dependent. A JDOM program that builds a simple document from string 
literals and stuffs it in a byte array should produce the identical 
byte array regardless of what platform it's run on.

>The alternative is for those needing platform-dependent files (the
>majority IMHO) will have to say
>outputter.setLineEnding(System.getProperty("line.separator")) which
>seems a little more inelegant to me.
>

Only if that's what most people want to do. Most people don't want to 
do that. They'll be happy with any line separator we give them. Of 
those who care, 90%+ will want \r\n anyway. I see no reason to make 
anything else the default. Remember XML files are about 
interoperability. The platform on which an XML document is created is 
not necessarily the platform on which the document will be viewed, 
edited, or otherwise manipulated. line.separator only tells me on 
what platform the VM was running when it built a file. That's not 
necessarily the system that uses the file.

The default case should shield the ignorant from their ignorance. The 
best way to do that is to pick \r\n as the line separator. I am not 
aware of any cases where this choice of line ending will do anything 
worse than look bad when loaded into a text editor, and even that 
problem is rare. However, picking either \r or \n alone as the line 
separator will cause network programs to hang unexpectedly when 
talking to some servers and servlets (as well as making files look 
bad when loaded into text editors on a far greater percentage of 
machines). This problem is very hard to debug if you don't already 
know what the problem is. If somebody chooses to set \r or \n as the 
line separator, then presumably they have a good reason for doing so 
and know what they're doing. But until somebody makes an explicit 
choice, we should pick \r\n.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+