Re: SystemUtils methods vs. fields vs. new class [WAS: [lang] SystemU tils.JAVA_IO_TMPDIR]

[Stephen Colebourne <sc...@btopenworld.com>]

I am +1 to adding new methods (not fields) for the following variables.

java.home = C:\java\sun\1.4.2_03\jre
java.io.tmpdir = C:\DOCUME~1\ggregory\LOCALS~1\Temp\
user.dir = C:\cvs-store\transidiom\deve
user.home = C:\Documents and Settings\ggregory

It is a sesnsible extension to a useful class. The current static fields are
perfectly fine for their task, and null values is acceptable as early JDKs
don't support some properties anyway.

Stephen

----- Original Message -----
From: "Gary Gregory" <gg...@seagullsw.com>
> (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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org