Hi Jason,
Looking at the diff for 6244047 - I see that, as you pointed
out, the unwanted behavior described comes from the fact that
the new code is using CREATE_NEW - which prevents the 'zombie
lock files' from being reused.
I am not an expert in file locks - but I wonder whether we
could
Daniel,
My understanding is that changing CREATE_NEW to use CREATE would make it work
like does in JDK7. Closing the lock files when the FileHandler is unreferenced
I is probably the fix for JDK-6774110: lock file is not deleted when child
logger is used.
If we could prove that system
Hi Jason,
On 6/23/14 2:51 PM, Jason Mehrens wrote:
Daniel,
My understanding is that changing CREATE_NEW to use CREATE would make it work
like does in JDK7. Closing the lock files when the FileHandler is unreferenced
I is probably the fix for JDK-6774110: lock file is not deleted when child
Hi,
I wonder whether the following patch would solve the
issue. In the case where the lock file already exists,
we check whether it's writable, and whether its directory
is writable, and if so, we open it for 'write+append',
otherwise, we continue with the next lock name.
I we have manage to
On 23/06/2014 10:48, Daniel Fuchs wrote:
:
All in all - I feel our best options would be to revert to using
CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
and live with the issue.
Hopefully some nio experts will chime in ;-)
The logging use of FileLock is a bit unusual but
On 6/23/14 4:53 PM, Alan Bateman wrote:
On 23/06/2014 10:48, Daniel Fuchs wrote:
:
All in all - I feel our best options would be to revert to using
CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
and live with the issue.
Hopefully some nio experts will chime in ;-)
The
Thanks again Daniel and Lance!
Joe
On 6/21/2014 3:32 AM, Lance @ Oracle wrote:
Agree this is better and cleaner!
http://oracle.com/us/design/oracle-email-sig-198324.gifLance
Andersen| Principal Member of Technical Staff | +1.781.442.2037
tel:+1.781.442.2037
Oracle Java Engineering
1
I would prefer that JCE1.2 be pulled out completely in the Cipher*
classes. I will be sending you a separate note about JCE logistics.
Thanks for doing this cleanup.
Brad
On 6/20/2014 11:46 AM, Henry Jen wrote:
Hi,
Please review a trivial webrev to add JDK version to @since in a format
as
I've spun a new webrev based on the comments for webrev-03:
http://cr.openjdk.java.net/~ntoda/8042469/webrev-04/
Changes are:
1) java.c
a) add free(envName) line 1063
b) change from malloc() to JLI_MemAlloc() @ lines 1048 and 1056
Thanks
-neil
On 6/20/2014 4:45 PM,
Martin,
Thanks for filing. I was positive there was already a bug for this, but
for the life of me I can't find it now. There's some other more minor
cleanup that needs to take place, but seems like I've been in
escalation/firefighting mode for more than a year now and it hasn't
bubbled to
Hi,
We're planning on a jaxp project to address usability issues in the JAXP
API. One of the complaints about the JAXP API is the number of lines of
code that are needed to implement a simple task. Tasks that should take
one or two lines often take ten or twelve lines instead. Consider the
The loadLibrary implementation is missing to wrap the call
to File.getCanonicalPath method with doPrivileged block.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/
thanks
Mandy
OK, I'll remove all @since JCE line, as the class already has @since 1.4
as Joe pointed out earlier.
Uodated webrev at
http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/
Cheers,
Henry
On 06/23/2014 10:04 AM, Bradford Wetmore wrote:
I would prefer that JCE1.2 be pulled out
Looks good to me; thanks,
-Joe
On 06/23/2014 01:50 PM, Henry Jen wrote:
OK, I'll remove all @since JCE line, as the class already has @since
1.4 as Joe pointed out earlier.
Uodated webrev at
http://cr.openjdk.java.net/~henryjen/jdk9/8047721/2/webrev/
Cheers,
Henry
On 06/23/2014 10:04 AM,
JCE (Cipher) changes look good to me.
Let me know if there's any problem with the point I mentioned in the
other email.
Brad
On 6/23/2014 1:50 PM, Henry Jen wrote:
OK, I'll remove all @since JCE line, as the class already has @since 1.4
as Joe pointed out earlier.
Uodated webrev at
What's the rationale for removing the secondary version? Or I guess the
question should really be: when are secondary versions useful? At least in
the EE specs, the EE version plus the spec version are listed in many
places like this.
Cheers,
Paul
On Mon, Jun 23, 2014 at 3:50 PM, Henry Jen
Except for these two classes, none of the JCE APIs ever contained @since
until the JCE was put into JDK 1.4 back in 2002. The unbundled JCE
hasn't been shipped in probably almost a decade. None of the unbundled
JSSE/JGSS should have them either.
Carrying around this old information is just
Please review a change to the JDK code for adding classLoader field to
the instances of java/lang/Class. This change restricts reflection from
changing access to the classLoader field. In the spec,
AccessibleObject.setAccessible() may throw SecurityException if the
accessibility of an
Hi,
Please review another webrev to clean up rawtypes and unchecked warning,
this time for sun.applet.
The webrev applied to both jdk9/dev and jdk9/client cleanly, I am not
sure which repo should the webrev go once pass review.
Webrev can be found at
Hello all;
This changeset corrects a reported problem with the lists returned by
Collections.checkedList(). Since Java 8 the replaceAll() method on checked
lists has erroneously allowed the operator providing replacements to provide
illegal replacement values which are then stored, unchecked
Hi Henry,
The changes look good to me; thanks,
-Joe
On 06/23/2014 05:31 PM, Henry Jen wrote:
Hi,
Please review another webrev to clean up rawtypes and unchecked
warning, this time for sun.applet.
The webrev applied to both jdk9/dev and jdk9/client cleanly, I am not
sure which repo should
Coleen,
On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
Please review a change to the JDK code for adding classLoader field to
the instances of java/lang/Class. This change restricts reflection
from changing access to the classLoader field. In the spec,
AccessibleObject.setAccessible() may
On 6/23/14, 9:36 PM, Mandy Chung wrote:
Coleen,
On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
Please review a change to the JDK code for adding classLoader field
to the instances of java/lang/Class. This change restricts
reflection from changing access to the classLoader field. In the
On 24/06/2014 11:44 AM, Coleen Phillimore wrote:
On 6/23/14, 9:36 PM, Mandy Chung wrote:
Coleen,
On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
Please review a change to the JDK code for adding classLoader field
to the instances of java/lang/Class. This change restricts
reflection from
24 matches
Mail list logo
