On Tue, Nov 10, 2009 at 03:05, Stephen Colebourne <scolebou...@joda.org>wrote:
> 2009/11/10 Mark Reinhold <m...@sun.com>:
> > 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:
>
> http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/SystemUtils.html
> 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
user.name have privacy/security implications,
which someone must surely be depending on.
System.lineSeparator() is a small step,
but it's achievable.
Martin
