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
On 4/15/11 3:57 PM, Rémi Forax wrote:
Hi Mandy,
Minor nit, initializing available when declaring it is not necessary
because both
path (with or without exception) initialize it later.
Sure. Will fix that before the push.
otherwise, I'm Ok with the patch.
Thanks
Mandy
Changeset: 131ed7967996
Author:valeriep
Date: 2011-04-15 15:56 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/131ed7967996
7035115: sun/security/pkcs11/Provider/ConfigShortPath.java compilation failed
Summary: Updated the test to use reflection and skip when SunPKCS11 provide
On 04/15/2011 10:55 PM, Mandy Chung wrote:
On 04/15/11 13:41, Daniel D. Daugherty wrote:
On 4/15/2011 1:12 PM, Mandy Chung wrote:
Hi Remi,
On 04/15/11 11:05, Rémi Forax wrote:
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a
try
On 04/15/11 13:41, Daniel D. Daugherty wrote:
On 4/15/2011 1:12 PM, Mandy Chung wrote:
Hi Remi,
On 04/15/11 11:05, Rémi Forax wrote:
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a try/catch(IOException).
That's a good point.
On 4/15/2011 1:12 PM, Mandy Chung wrote:
Hi Remi,
On 04/15/11 11:05, Rémi Forax wrote:
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a try/catch(IOException).
That's a good point. I think it should throw IOException if anything
Hi Eamonn
The javadocs for Timestamp have always specifically called the following blurb
out in the class description. Based on some side discussions, it was best to
also copy this blurb to the added hashCode method (you will see the text at the
top of Timestamp) for additional clarity.
Regar
Hi Remi,
On 04/15/11 11:05, Rémi Forax wrote:
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a try/catch(IOException).
That's a good point. I think it should throw IOException if anything
goes wrong with fc.close(). Revised the
Hi all,
Need a reviewer for the following minor change which adds hasCode() to
Timestamp to address a Findbugs warning.
Regards
Lance
hg diff
diff -r d9248245a88c src/share/classes/java/sql/Timestamp.java
--- a/src/share/classes/java/sql/Timestamp.java Wed Apr 13 11:21:36 2011 -0400
+++ b/src
On 04/15/2011 07:55 PM, Daniel D. Daugherty wrote:
Thumbs up.
Dan
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a try/catch(IOException).
Rémi
On 4/15/2011 11:01 AM, Mandy Chung wrote:
Fix for 7032589: FileHandler leaking fi
Thumbs up.
Dan
On 4/15/2011 11:01 AM, Mandy Chung wrote:
Fix for 7032589: FileHandler leaking file descriptor of the file lock
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.00/
When a log file is currently being used, tryLock() will fail and it
has to close the file
Fix for 7032589: FileHandler leaking file descriptor of the file lock
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.00/
When a log file is currently being used, tryLock() will fail and it has
to close the file channel of the lock file
Thanks
Mandy
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
23 matches
Mail list logo
