commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject SystemUtils methods vs. fields vs. new class [WAS: [lang] SystemU tils.JAVA_IO_TMPDIR]
Date Tue, 30 Dec 2003 19:39:02 GMT
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

> -----Original Message-----
> From: __matthewHawthorne [mailto:matth@phreaker.net]
> Sent: Tuesday, December 30, 2003 09:57
> To: Jakarta Commons Developers List
> Subject: Re: [lang] SystemUtils.JAVA_IO_TMPDIR
> 
> Gary Gregory wrote:
> > Note that the current implementation already does some of this catch and
> set
> > to null business WRT SecurityExpections.
> 
> Ah, I didn't realize this.  Perhaps it isn't a big deal then -- although
> I think that providing the constants in this way, although convenient,
> circumvents some exception mechanisms which provide more explicit error
> messages.
> 
> My point is, if something goes wrong, you'll get a NullPointerException
> and have to look at System.err to see what happened.  I don't prefer
> this, but perhaps others do.
<snip>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message