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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] SystemUtils.JAVA_IO_TMPDIR
Hello, When I use SystemUtils.JAVA_IO_TMPDIR, I really need File file = new File(SystemUtils.JAVA_IO_TMPDIR) Any thoughts/allergic reactions to providing a SystemUtils.JAVA_IO_TMPDIR_FILE? Gary
Re: [lang] SystemUtils.JAVA_IO_TMPDIR
Gary Gregory wrote: Hello, When I use SystemUtils.JAVA_IO_TMPDIR, I really need File file = new File(SystemUtils.JAVA_IO_TMPDIR) Any thoughts/allergic reactions to providing a SystemUtils.JAVA_IO_TMPDIR_FILE? Gary Would proving a static File instance create any strangeness with regard to system resources? I'm not sure. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] SystemUtils.JAVA_IO_TMPDIR
It would definitely need to be protected in construction to avoid exceptions and set the value to null if it fails. Are there other values in systemutils that this could apply to? Stephen From: __matthewHawthorne [EMAIL PROTECTED] Gary Gregory wrote: Hello, When I use SystemUtils.JAVA_IO_TMPDIR, I really need File file = new File(SystemUtils.JAVA_IO_TMPDIR) Any thoughts/allergic reactions to providing a SystemUtils.JAVA_IO_TMPDIR_FILE? Gary Would proving a static File instance create any strangeness with regard to system resources? I'm not sure. - 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]
RE: [lang] SystemUtils.JAVA_IO_TMPDIR
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 15:30 To: Jakarta Commons Developers List Subject: Re: [lang] SystemUtils.JAVA_IO_TMPDIR It would definitely need to be protected in construction to avoid exceptions and set the value to null if it fails. Are there other values in systemutils that this could apply to? Stephen (1) The system properties (and examples) that point to a (one, 1) directory: 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 These could be mapped to java.io.File. This I could use. For all others below, I have no use for today. (2) The system properties that point to a directory list are: java.endorsed.dirs = C:\java\sun\1.4.2_03\jre\lib\endorsed java.ext.dirs = C:\java\sun\1.4.2_03\jre\lib\ext java.library.path = C:\java\sun\1.4.2_03\bin;.;C:\WINDOWS\System32;C:\WINDOWS;C:\java\sun\1.4.2_ 03\bin;C:\Perl\bin\;C:\Program Files\IBM\WebSphere MQ\Java\lib;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\PROGR AM FILES\THINKPAD\UTILITIES;C:\Program Files\IBM\IBM CICS Universal Client\BIN;c:\bin;C:\java\apache\apache-ant-1.6.0\bin;C:\Program Files\IBM\WebSphere MQ\bin;C:\Program Files\IBM\WebSphere MQ\tools\c\samples\bin;C:\Documents and Settings\ggregory\My Documents\bin;C:\Program Files\4NT;C:\java\javacc-3.2\bin;C:\java\sun\jwsdp-1.2\jwsdp-shared\bin;C:\P rogram Files\Apache Software Foundation\Maven 1.0-rc1\bin sun.boot.class.path = C:\java\sun\1.4.2_03\jre\lib\endorsed\xalan.jar;C:\java\sun\1.4.2_03\jre\lib \endorsed\xercesImpl.jar;C:\java\sun\1.4.2_03\jre\lib\endorsed\xml-apis.jar; C:\java\sun\1.4.2_03\jre\lib\rt.jar;C:\java\sun\1.4.2_03\jre\lib\i18n.jar;C: \java\sun\1.4.2_03\jre\lib\sunrsasign.jar;C:\java\sun\1.4.2_03\jre\lib\jsse. jar;C:\java\sun\1.4.2_03\jre\lib\jce.jar;C:\java\sun\1.4.2_03\jre\lib\charse ts.jar;C:\java\sun\1.4.2_03\jre\classes sun.boot.library.path = C:\java\sun\1.4.2_03\jre\bin (3) These could be mapped to java.io.File[]. Other interesing properties that could map to a java.net.URL: java.vendor.url = http://java.sun.com/ java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi Gary From: __matthewHawthorne [EMAIL PROTECTED] Gary Gregory wrote: Hello, When I use SystemUtils.JAVA_IO_TMPDIR, I really need File file = new File(SystemUtils.JAVA_IO_TMPDIR) Any thoughts/allergic reactions to providing a SystemUtils.JAVA_IO_TMPDIR_FILE? Gary Would proving a static File instance create any strangeness with regard to system resources? I'm not sure.
Re: [lang] SystemUtils.JAVA_IO_TMPDIR
Stephen Colebourne wrote: It would definitely need to be protected in construction to avoid exceptions and set the value to null if it fails. I think that static methods may be a cleaner approach, instead of a static block which much catch IOExceptions when constructing the static File objects. This would elminate the convenience of having static fields, but the possibility of receiving NullPointerExceptions instead of IOExceptions after an error doesn't seem favorable to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] SystemUtils.JAVA_IO_TMPDIR
Note that the current implementation already does some of this catch and set to null business WRT SecurityExpections. The additional layer needed to create a File object would be wrapped in a method that checks for null. What I like about the static final idea is that it does convey the idea that the value will not change, unlike a method call. OTOH, calling System.getProperty does not say anything about the value not changing, so I guess I'd be fine with a method or a field. Gary -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 16:56 To: Jakarta Commons Developers List Subject: Re: [lang] SystemUtils.JAVA_IO_TMPDIR Stephen Colebourne wrote: It would definitely need to be protected in construction to avoid exceptions and set the value to null if it fails. I think that static methods may be a cleaner approach, instead of a static block which much catch IOExceptions when constructing the static File objects. This would elminate the convenience of having static fields, but the possibility of receiving NullPointerExceptions instead of IOExceptions after an error doesn't seem favorable to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
