commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <>
Subject Re: SystemUtils methods vs. fields vs. new class [WAS: [lang] SystemU tils.JAVA_IO_TMPDIR]
Date Tue, 30 Dec 2003 19:52:22 GMT
I feel that all of the methods which deal with system properties aren't 
very useful.

Here's the choice:

1) new File(SystemUtils.JAVA_IO_TMPDIR)
- may throw a NullPointerException if a secret SecurityException occurs

2) new File(System.getProperty(""))
- may throw a SecurityException

I just don't think that adding code to SystemUtils to accomplish this 
task is worth the effort.  What's the problem with option 2 above?

Gary Gregory wrote:
> I was not wild about the current impl when I saw it but the fix was
> backwards compatible, that part was nice.
> (1) So perhaps the question becomes: Should all of the fields be turned
> (deprecated?) into methods and the exceptions not caught? For example:
> SystemUtils.getJavaIoTmpDir();
> SystemUtils.getJavaRuntimeName();
> If the exceptions are not caught, it is possible that the class then becomes
> unusable in certain contexts.
> The CVS comment for that change from Stephen was: "Reworked class to avoid
> security exceptions from Michael Becke". Is that really appropriate? It
> seems a bit nasty that the class is quietly initialized with nulls. 
> (2) Should there be instead an isAvailable() kind of method instead?
> (3) Or what about a class that deals /specifically/ with all of this, a nice
> and focused job: SystemProperties, a singleton, or static
> SystemPropertiesUtils.
> SystemProperties.getInstance().getClassPath();
> SystemPropertiesUtils.getClassPath();
> SystemProperties would define only methods and object versions of the
> appropriate methods. For example
> File file = SystemProperties.getInstance().getJavaIoTmpDirFile();
> String dirName = SystemProperties.getInstance().getJavaIoTmpDir();
> ?
> Gary

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message