My gut feeling is that this is an unusual case. Certainly, adding javadoc to
say that the values are set when the class is class loaded is a good idea.
Extra set/get methods are troublesome though, and I don't really want to
expose more constants for the extra keys.
Do people really change these values? (other than in tests, which kinda
don't count...)
Stephen
From: "Gary Gregory" <[EMAIL PROTECTED]>
> Context: I am writing some unit tests for our product that require system
> properties (like java.ext.dirs) to be temporarily fiddled with. Now my
code
> looks like this:
>
> public void testJavaExtDirDoesNotExist() {
> String saveJavaExtDirs = SystemUtils.JAVA_EXT_DIRS;
> try {
> String testJavaExtDirs = "...";
> System.setProperty("java.ext.dirs", testJavaExtDirs);
> // The real test starts here...
> } finally {
> System.setProperty("java.ext.dirs", saveJavaExtDirs);
> }
> }
>
> Issue #1: Add SystemUtils.setX?
> --------
>
> Instead of:
>
> System.setProperty("java.ext.dirs", testJavaExtDirs);
>
> I wonder if this would be better:
>
> SystemUtils.setJavaExtDirs(testJavaExtDirs);
>
> Seems nicer, yes?
>
> Issue #2: SystemUtils out of sync.
> --------
>
> As soon you do:
>
> System.setProperty("java.ext.dirs", testJavaExtDirs);
>
> Then SystemUtils.JAVA_EXT_DIRS lies.
>
> Proposal 2a:
> At least, the Javadoc has to be updated to something nasty like: "The
value
> of this constant is set when this class is first loaded."
>
> Proposal 2b:
> Add SystemUtils.getJavaExtDirs() and other APIs which do not cache and
make
> JAVA_EXT_DIRS and others use such APIs.
>
> Proposal 3b:
> Add constants for the property names like: JAVA_EXT_DIRS_KEY =
> "java.ext.dirs".
>
> ?
> Gary
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
