Alan Bateman wrote:
Michael McMahon wrote:
On Windows, we are ensuring that SystemRoot will at a minimum always
be set.
Don't you still have the corner case where Runtime.exec is invoked
with an empty array and SystemRoot is not in the environment (launched
by an older JDK for example)? In t
Michael McMahon wrote:
This issue occurs on some versions of Windows since we switched compiler
to VC 2010. The new C runtime library requires the "SystemRoot"
environment
variable to be set, when launching sub-processes via Runtime.exec() or
ProcessBuilder.
The problem occurs in instances wh
Ulf Zibis wrote:
Am 15.04.2011 14:15, schrieb Alan Bateman:
Ulf Zibis wrote:
:
Again I ask if we shouldn't disallow to user-define the "SystemRoot"
variable on Windows?
Imagine someone has set the variable to "C:\WINDOWS", but the
correct value is "D:\WINDOWS".
No, I don't think we should si
Ulf,
Ulf Zibis said the following on 04/15/11 04:02:
Oops, SystemRoot could be null theoretically. So forget my comment about
NUL termination.
But anyway, should we allow to have get("SystemRoot") !=
getEnv("SystemRoot")?
Is it correct to defaultly set the "SystemRoot" variable on non-Windo
Ulf Zibis said the following on 04/20/11 01:31:
Thanks for your feedback Michael.
One little nit:
I guess you have overseen to replace .append("=") by .append('=')
+1
Otherwise all looks good. Thanks Michael.
David
Am 19.04.2011 17:05, schrieb Michael McMahon:
Ulf,
On the usage of Lis
Thanks for your feedback Michael.
One little nit:
I guess you have overseen to replace .append("=") by .append('=')
Am 19.04.2011 17:05, schrieb Michael McMahon:
Ulf,
On the usage of List vs [], my point was that the clarity, simplicity and safety
provided by iterating over a Collection out-w
Ulf,
On the usage of List vs [], my point was that the clarity, simplicity
and safety
provided by iterating over a Collection out-weighs any performance cost
in this case,
as compared with using an array. It makes little difference to
the cost of creating an OS process.
On moving the SYSTEMRO
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 wrote:
Am 15.04.2011 15:43, schrieb Michael McMahon:
I have incorporated much
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 mo
Am 18.04.2011 15:43, schrieb Michael McMahon:
Ulf Zibis wrote:
I think, the comment in lines 295..297 more belongs to the code (lines 312..315 + 318..320 )
rather than to the constant SYSTEMROOT. Why defining it as class member, as it is only locally
referred?
It makes no difference to the g
On Mon, Apr 18, 2011 at 1:40 PM, Ulf Zibis 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 alternat
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 m
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 m
Ulf Zibis wrote:
Am 16.04.2011 12:48, schrieb Alan Bateman:
Michael McMahon wrote:
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 de
Am 16.04.2011 12:48, schrieb Alan Bateman:
Michael McMahon wrote:
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 thi
Hi David,
much thanks for your detailed effort.
-Ulf
Am 17.04.2011 22:50, schrieb David Schlosnagle:
On Sun, Apr 17, 2011 at 1:27 PM, Ulf Zibis wrote:
Am 16.04.2011 16:45, schrieb David Schlosnagle:
One minor nit in ProcessEnvironment.java
336 private static void addToEnv(StringBuild
David Schlosnagle wrote:
On Sun, Apr 17, 2011 at 1:27 PM, Ulf Zibis wrote:
Am 16.04.2011 16:45, schrieb David Schlosnagle:
One minor nit in ProcessEnvironment.java
336 private static void addToEnv(StringBuilder sb, String name,
String val) {
337 sb.append(name+"="+val+'\
On Sun, Apr 17, 2011 at 1:27 PM, Ulf Zibis wrote:
> Am 16.04.2011 16:45, schrieb David Schlosnagle:
>>
>> One minor nit in ProcessEnvironment.java
>>
>> 336 private static void addToEnv(StringBuilder sb, String name,
>> String val) {
>> 337 sb.append(name+"="+val+'\u');
>> 338
Am 16.04.2011 16:45, schrieb David Schlosnagle:
One minor nit in ProcessEnvironment.java
336 private static void addToEnv(StringBuilder sb, String name,
String val) {
337 sb.append(name+"="+val+'\u');
338 }
I think it should be as follows to avoid implicitly constructi
On Sat, Apr 16, 2011 at 6:48 AM, Alan Bateman wrote:
> Michael McMahon wrote:
>>
>> 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 tha
Michael McMahon wrote:
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://c
Ulf Zibis wrote:
I don't think about silently changing, I think about to *disallow to
set* it e.g. by the put() method, and instead retrieve it by default
from constructor, so it could be always read by the get() method.
Ah, you mean the environment returned by ProcessBuilder where the spec
Am 15.04.2011 14:15, schrieb Alan Bateman:
Ulf Zibis wrote:
:
Again I ask if we shouldn't disallow to user-define the "SystemRoot" variable
on Windows?
Imagine someone has set the variable to "C:\WINDOWS", but the correct value is
"D:\WINDOWS".
No, I don't think we should silently change the
Ulf Zibis wrote:
:
Again I ask if we shouldn't disallow to user-define the "SystemRoot"
variable on Windows?
Imagine someone has set the variable to "C:\WINDOWS", but the correct
value is "D:\WINDOWS".
No, I don't think we should silently change the value of this or other
variables.
-Alan.
Am 15.04.2011 11:45, schrieb Michael McMahon:
Ulf,
On "SystemRoot" vs "systemroot", I had thought that Windows required the sort
to be case-sensitive. But, I double-checked and it doesn't. So we can use
"SystemRoot".
If that would be true, we wouldn't need to sort by CASE_INSENSITIVE_ORDER or
Am 15.04.2011 11:54, schrieb Alan Bateman:
Michael McMahon wrote:
On Windows, we are ensuring that SystemRoot will at a minimum always be set.
Don't you still have the corner case where Runtime.exec is invoked with an empty array and
SystemRoot is not in the environment (launched by an older J
Michael McMahon wrote:
On Windows, we are ensuring that SystemRoot will at a minimum always
be set.
Don't you still have the corner case where Runtime.exec is invoked with
an empty array and SystemRoot is not in the environment (launched by an
older JDK for example)? In that case we can't mak
Michael McMahon wrote:
oops. This isn't correct. Sorry.
It seems the NameComparator class uses exactly the same algorithm as the
CASE_INSENSITIVE_ORDER comparator provided by the String class. So,
it probably makes sense to replace NameComparator with the one from
String
(one less class
Ulf,
It seems the NameComparator class uses exactly the same algorithm as the
CASE_INSENSITIVE_ORDER comparator provided by the String class. So,
it probably makes sense to replace NameComparator with the one from String
(one less class in rt.jar :) )
On "SystemRoot" vs "systemroot", I had thoug
Am 15.04.2011 10:50, schrieb Alan Bateman:
Ulf Zibis wrote:
IMHO there should be a big hint in this file:
//
// This is the Windows implementation of this class! //
/
Ulf Zibis wrote:
IMHO there should be a big hint in this file:
//
// This is the Windows implementation of this class! //
//
-Ul
Am 15.04.2011 01:44, schrieb David Holmes:
Ulf,
Ulf Zibis said the following on 04/15/11 04:02:
Oops, SystemRoot could be null theoretically. So forget my comment about NUL
termination.
But anyway, should we allow to have get("SystemRoot") != getEnv("SystemRoot")?
Is it correct to defaultly
Hi Michael,
Michael McMahon said the following on 04/15/11 00:06:
An updated webrev is available for this fix. I'll probably go ahead
with the CCC request for the spec. change anyway.
http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/
Based on Alan's comments I checked for and found webre
If you like, you can save 1 more line:
return sb.append('\u').toString();
;-)
-Ulf
Am 14.04.2011 22:55, schrieb Ulf Zibis:
sb.append('\u');
return sb.toString();
You can have the code much shorter (and faster):
// Only for use by ProcessImpl.start()
String toEnvironmentBlock() {
// Sort Unicode-case-insensitively by name
Map.Entry[] list = entrySet().toArray(new
Map.Entry<>[size()]);
Arrays.sort(list, entryComparator);
Oops, SystemRoot could be null theoretically. So forget my comment about NUL
termination.
But anyway, should we allow to have get("SystemRoot") != getEnv("SystemRoot")?
Is it correct to defaultly set the "SystemRoot" variable on non-Windows OS?
Why don't we inherit ProcessEnvironment from Tree
You need not to ensure double NUL termination, because now sb.length() is always
> 0.
-Ulf
Am 14.04.2011 16:06, schrieb Michael McMahon:
An updated webrev is available for this fix. I'll probably go ahead
with the CCC request for the spec. change anyway.
http://cr.openjdk.java.net/~michaelm/
Michael McMahon wrote:
An updated webrev is available for this fix. I'll probably go ahead
with the CCC request for the spec. change anyway.
http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/
The updated webrev looks much better. A couple of minor suggestions
- it might be useful to future
An updated webrev is available for this fix. I'll probably go ahead
with the CCC request for the spec. change anyway.
http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/
Thanks,
Michael.
Ulf,
Thanks for the comments. I think I will remove the @SuppressWarning for now,
and we can look at generifying CheckedEntrySet another time.
The environment block is required to be sorted when you call CreateProcess()
on Windows.
Yes, as per the earlier message to David Holmes, I'm looking a
First: please add some more description to the subject line.
ProcessEnvironment :
Line 146: There is a superfluous space between 'checkedEntry' and '(Object o)'.
Instead of suppressing the warnings, we could code:
public boolean contains(Map.Entry o) {return
s.contains(checkedEntry(o))
Michael McMahon wrote:
:
In toEnvironmentBlock does the getenv("SystemRoot") need to be done
in a privileged block (I'm just thinking of the case where you have
permissions to exec the process but not read the variable). Also do
you need to handle the case that it is null?
The permission che
Alan Bateman wrote:
Michael McMahon wrote:
This issue occurs on some versions of Windows since we switched compiler
to VC 2010. The new C runtime library requires the "SystemRoot"
environment
variable to be set, when launching sub-processes via Runtime.exec()
or ProcessBuilder.
The problem o
David Holmes wrote:
Spec change seems fine to me.
http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/
Is it possible to watch for the SystemRoot entry while iterating
through at line 322 (ProcessEnvironment.java) instead of doing the
iterative search before-hand? Or even doing the sort
Michael McMahon wrote:
This issue occurs on some versions of Windows since we switched compiler
to VC 2010. The new C runtime library requires the "SystemRoot"
environment
variable to be set, when launching sub-processes via Runtime.exec() or
ProcessBuilder.
The problem occurs in instances wh
Hi Michael,
Michael McMahon said the following on 04/13/11 21:33:
This issue occurs on some versions of Windows since we switched compiler
to VC 2010. The new C runtime library requires the "SystemRoot" environment
variable to be set, when launching sub-processes via Runtime.exec() or
ProcessBu
This issue occurs on some versions of Windows since we switched compiler
to VC 2010. The new C runtime library requires the "SystemRoot" environment
variable to be set, when launching sub-processes via Runtime.exec() or
ProcessBuilder.
The problem occurs in instances where the environment is sp
47 matches
Mail list logo
