Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited
Michael McMahon
michael.x.mcmahon at oracle.com
Mon Apr 18 13:43:49 UTC 2011
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 default. I
>>> think this approach
>>> is the most flexible.
>>>
>>> http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/
>> This looks much better - thanks Ulf for the improved loop and
>> changing it to use nameComparator. It will be good to get this one
>> fixed.
>>
>
> Thanks for the partial acceptance.
>
> 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 generated code. And imo, there is more
space for the comment there.
> I still don't see the advantage, having the SYSTEMROOT insertion code
> at 2 call sites. One would be shorter and much clearer as shown in my
> code. Then we too could save addToEnvIfSet(..) and the call to it.
>
Shorter doesn't always mean clearer. I think this way is clearer.
> Additionally: Why instantiating, initializing and processing a fat
> j.u.List object, if a simple array would fulfil all needs?
>
I don't see a compelling reason to change it from a List (which is what
it was). I think any additional overhead
is inconsequential in the context of creating an OS process. Or if it
is, then we should be looking at
our List implementations.
> You have removed the 'Ensure double NUL termination' code. I guess,
> you have approved, that String->CString already handles this, right?
>
Actually no. That shouldn't have been omitted. Thanks for finding that!
- Michael.
More information about the core-libs-dev
mailing list