Adding constant for line.separator and friends

Rémi Forax forax at univ-mlv.fr
Tue Nov 10 07:46:04 UTC 2009


Le 10/11/2009 08:07, Martin Buchholz a écrit :
>
>
> On Mon, Nov 9, 2009 at 21:54, Mark Reinhold <mr at sun.com 
> <mailto:mr at sun.com>> wrote:
>
>     > Date: Mon, 09 Nov 2009 20:29:51 -0800
>     > From: Martin Buchholz <martinrb at google.com
>     <mailto:martinrb at google.com>>
>
>     > ...
>     >
>     > Since line.separator is the most popular system property,
>     > and other system properties like
>     > java.home have vague security implications
>     > that would suggest they must be protected by
>     > a security manager, we might consider just
>     > making the one system property available.
>     > Perhaps very simply
>     >
>     > String System.lineSeparator()?
>
>     This seems like a much better solution than adding a whole static
>     inner
>     class to java.lang.System.
>
>     Yet ... how much of a problem is this outside of the JDK itself and,
>     more generally, for new code rather than old?
>
>     If there are n (for n <= 43) problematic uses in the JDK then we could
>     just fix those without defining any new public API.  For new code we
>     should encourage people to use String.format("...%n...") rather than
>     access the line.separator property explicitly.
>
>
> Hacking on Formatter is how I got here.
>
> String.format("%n")" is both at risk of throwing SecurityException
> (because Formatter does not use doPrivileged;
> my proposal here is a step to fixing that)
> and is rather slow.
> Too slow for performance-sensitive uses.
>
> Martin
>

Yes, printf is awfully slow.
I am in favor of something like that:

public class System {
   public String lineSeparator() {
     return StandardProperties.LINE_SEPARATOR;
   }
}

With StandardProperties private and LINE_SEPARATOR with a default 
visibility.

Rémi



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091110/42335b17/attachment.html>


More information about the core-libs-dev mailing list