JDK-6529790 : Please add LINE_SEPARATOR constant into System or some other class
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6
  • Priority: P5
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-03-01
  • Updated: 2012-06-13
  • Resolved: 2012-06-13
Related Reports
Duplicate :  
Relates :  
There is well-known system property: System.getProperty("line.separator"). It is often necessary while creating different text files, logging, printing debug messages by System.out.println, etc. The simplest example:

StringBuilder sb = new StringBuilder();
for (int i=0; i<100000; i++) {
   ...some complex calculations....
   sb.append("Some debug information: ..." + System.getProperty("line.separator"));
   // It is too slow to call here logging/printing methods
myLogger.fine(sb.toString()); // or System.out.println(sb);

I think it would be good to add the corresponding constant to some standard Java class, as String or System. Why do you offer File.pathSeparator constant but do not offer any constant for line separator string?

Of course, we can use the expression "System.getProperty("line.separator")". But here are, at least, two problems.

1) This expression is not syntactically protected against a mistake while typing. If I'll write "line.separato", the compiler will not warn and this bug can be not detected for a long time, if this string is used for debug messages only.

2) According Java documentation, System.getProperty method can throw SecurityException. It is theoretically possible that this exception will be thrown while the call "System.getProperty("line.separator")": your documentation allows this situation. To avoid this problem, I'm forced to create the code alike the following one in my libraries:

    public static final String LINE_SEPARATOR = getLineSeparator();
    private static String getLineSeparator() {
        java.io.ByteArrayOutputStream byteArrayOutputStream = new java.io.ByteArrayOutputStream(8);
        java.io.PrintStream printStream = new java.io.PrintStream(byteArrayOutputStream);
        byte[] bytes = byteArrayOutputStream.toByteArray();
        char[] chars = new char[bytes.length];
        for (int k = 0; k < bytes.length; k++)
            chars[k] = (char)(bytes[k] & 0xFF);
        return String.valueOf(chars);

I include such a code for almost all my libraries that require non-trivial debug messaging.

I offer to include the simple and safe constant LINE_SEPARATOR into System, String or another standard public class.

  Too complex code allowing to safely create a multi-line text with standard system line separator between lines.

I would like to be able to write:
    String s = "My first line" + System.LINE_SEPARATOR + "My second write";
Another possible solution is to add the method, for example into String class, that replaces all \n characters with standard system line separator. For example:
    String s = "My first line\nMy second write";
It may be better solution because such method can preserve all existing system-oriented line separators (as \r\n in Windows) but correct only single \n characters.

EVALUATION I beg to differ that the frequency of usage for this property is "very low". My experience contradicts this; ${line.separator} is used in all sorts of situations, especially preparation of multiline String's to be written to console or a file later. It is quite awkward to access this as a system property. A quick grep shows the system property being accessed in 261 (!) different places in the main source repository for NetBeans. At least 21 of these usages involve a class defining its own constant to avoid having to repeat the method call, e.g. public static final String LINE_SEPARATOR = System.getProperty("line.separator");

EVALUATION This request needs more consideration that will have to wait but here are a few initial remarks. The most likely explanation for why File.pathSeparator exists but no corresponding line separator does is that the frequency of usage seems hugely different (in favor of path separator). And it's the frequency of a specific constant for the line separator most likely being very low that tends to make it hard to justify additional JDK complexity. Also, the constant would have be dynamically initialized via the underlying property anyway, otherwise users couldn't override the value (as can be done with File.pathSeparator, for example). The default security policy file explicitly gives read permission for property line.separator and it seems unlikely that this permission would ordinarily be withdrawn. But the submitter's code could even take this into account with an optimization by trying getProperty first and using the much more involved code if an exception is caught. But the basic question to is whether the extra complexity of code and documentation of the JDK is justified by the expected utility. And a secondary, but not insignificant question is whether this request would naturally become more general to ask why all properties are not more conveniently available? See CR 6370159 for an example of this.