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
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
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
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
-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
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.
, 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
