commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: SystemUtils methods vs. fields vs. new class [WAS: [lang] Sys temU tils.JAVA_IO_TMPDIR]
Date Tue, 30 Dec 2003 20:08:06 GMT
(I presume that your 2 choices are user code choices.) My thinking in adding
a method/field to SU which returns a File is about creating the proper
object, the proper abstraction. 

System.getProperty() gives us a very thin layer over the JVM/OS to access
properties but it is flexible. There is a known set of properties always
returned as Strings in known formats. What I am saying is that in the case
of Strings that represent directories, I want an object that says "I am a
directory" (-> java.io.File) not "I am a String" which I must convert
myself. 

I can code "new File" myself of course. But it seems good to say: we know
this system property is a directory, so here it is as a proper Object, a
File you can work with.

Currently SU is more like a macro, hiding System.getProperty calls. I am
proposing of giving it a little more brains ;-)

Gary

> -----Original Message-----
> From: __matthewHawthorne [mailto:matth@phreaker.net]
> Sent: Tuesday, December 30, 2003 11:52
> To: Jakarta Commons Developers List
> Subject: Re: SystemUtils methods vs. fields vs. new class [WAS: [lang]
> SystemU tils.JAVA_IO_TMPDIR]
> 
> 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

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