Adding constant for line.separator and friends

Martin Buchholz martinrb at
Tue Nov 10 17:30:03 UTC 2009

On Tue, Nov 10, 2009 at 03:05, Stephen Colebourne <scolebourne at>wrote:

> 2009/11/10 Mark Reinhold <mr at>:
> > 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.
> Commons Lang defines the class SystemUtils:
> This has constants for all the main system properties.
> Within my work 1.4MLOC codebase, SystemUtils.LINE_SEPARATOR is used 65
> times, with a further 7 cases within other parts of Commons Lang
> itself. This is a commonly used value.
> SystemUtils contains many more constants though. This is beneficial
> for code clarity, and avoiding "magic" property names that are
> difficult to find when you want them. While most are rarely used, all
> will be used occasionally (otherwise why make them available). Asking
> developers to use "magic" names for the well-defined common cases
> seems non-sensical.
> As such I'm definitely in favour of line separator, but would also
> want to see others (including common directory locations like IO
> home).

I agree - I would also like to see a class that provides cheap and
compile-time-checked access to standard system properties,
like SystemUtils, but also guaranteeing to use doPrivileged
to avoid security manager problems.  But I don't think
this would be accepted in core jdk,
since some of the system properties like have privacy/security implications,
which someone must surely be depending on.

System.lineSeparator() is a small step,
but it's achievable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the core-libs-dev mailing list