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 so
y, 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.
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.
> -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 avo
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 SystemUti
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 syst
