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" <[EMAIL PROTECTED]> > (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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
