hg: jdk7/tl/jdk: 7032589: FileHandler leaking file descriptor of the file lock

2011-04-16 Thread mandy . chung 
Changeset: 54d9513f87a4
Author:mchung
Date:  2011-04-15 23:42 -0700
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54d9513f87a4

7032589: FileHandler leaking file descriptor of the file lock
Reviewed-by: forax, dcubed

! src/share/classes/java/util/logging/FileHandler.java

Re: Review Request (1-line fix): 7032589 FileHandler leaking file descriptor of the file lock

2011-04-16 Thread Alan Bateman 

Mandy Chung wrote:

:
I created a CR 7037134: Potential writing to the same log file by 
multiple processes
I don't see anything in the logging API that requires the log file to be 
locked but my guess is that this code is there for cases where the log 
file is on a NFS server and the lock daemon isn't running.


-Alan.

Auto Reply: core-libs-dev Digest, Vol 48, Issue 41

2011-04-16 Thread roger . riggs 
Roger is out of the office until 4/19 with limited access to email.

Re: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited

2011-04-16 Thread 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.


-Alan

Re: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited

2011-04-16 Thread David Schlosnagle 
On Sat, Apr 16, 2011 at 6:48 AM, Alan Bateman alan.bate...@oracle.com 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 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.

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 constructing
another StringBuilder and the extra copying overhead;

 336 private static void addToEnv(StringBuilder sb, String name,
String val) {
 337 sb.append(name).append('=').append(val).append('\u');
 338 }

- Dave

7036582: Improve test coverage of java.math.BigDecimal

2011-04-16 Thread Alan Bateman 


This is webrev with new tests for BigDecimal that have been contributed 
by Sergey Kuksenko. The motive is to improve the test coverage to 
facilitate improvements to BigDecimal in the future. Joe Darcy has 
already reviewed the tests so I'm okay for a reviewer.

  http://cr.openjdk.java.net/~alanb/7036582/webrev/

-Alan.