Oops, I was irritated by the internal int variables, but yes, they reside on stack, so no worry
about thread-safety.
-Ulf
Am 18.04.2011 20:16, schrieb David Schlosnagle:
On Mon, Apr 18, 2011 at 1:40 PM, Ulf Zibis<ulf.zi...@gmx.de> wrote:
Am 15.04.2011 15:43, schrieb Michael McMahon:
I have incorporated much of Ulf's approach into this version.
I agree with Alan about the spec. We could find other variables in the
future that need
to be set, but can have alternative values other than the default. I think
this approach
is the most flexible.
http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/
Additionally I see another problem:
Because the ProcessEnvironment.nameComparator is static, creating a new
Process will not be thread-safe!
Ulf,
I don't see a problem here. The ProcessEnvironment.nameComparator is a
static final field that is initialized to `new NameComparator()` in a
static initialization block for the ProcessEnvironment class. The
NameComparator has no instance state, and can be safely shared by
multiple threads.
> From
http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/src/windows/classes/java/lang/ProcessEnvironment.java.html:
191 private static final class NameComparator
192 implements Comparator<String> {
193 public int compare(String s1, String s2) {
194 // We can't use String.compareToIgnoreCase since it
195 // canonicalizes to lower case, while Windows
196 // canonicalizes to upper case! For example, "_" should
197 // sort *after* "Z", not before.
198 int n1 = s1.length();
199 int n2 = s2.length();
200 int min = Math.min(n1, n2);
201 for (int i = 0; i< min; i++) {
202 char c1 = s1.charAt(i);
203 char c2 = s2.charAt(i);
204 if (c1 != c2) {
205 c1 = Character.toUpperCase(c1);
206 c2 = Character.toUpperCase(c2);
207 if (c1 != c2)
208 // No overflow because of numeric promotion
209 return c1 - c2;
210 }
211 }
212 return n1 - n2;
213 }
214 }
...
227 private static final NameComparator nameComparator;
...
233 static {
234 nameComparator = new NameComparator();
...
- Dave
