You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <gg...@seagullsw.com> on 2003/12/30 20:39:02 UTC
SystemUtils methods vs. fields vs. new class [WAS: [lang] SystemU
tils.JAVA_IO_TMPDIR]
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>
Re: SystemUtils methods vs. fields vs. new class [WAS: [lang] SystemU
tils.JAVA_IO_TMPDIR]
Posted by __matthewHawthorne <ma...@phreaker.net>.
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("java.io.tmpdir"))
- 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org