Re: JDK-8011653: Upgrade to JAXP 1.5

Hi Alan, Lance, This is an update that reflects the spec change, and also fixes for JDK-8013232 and JDK-8013484. Please review: http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ Thanks, Joe On 4/18/2013 2:43 AM, huizhe wang wrote: On 4/15/2013 2:22 AM, Alan Bateman wrote: On 15/04/20

RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit

Hi, Please review the patch below for some minor fixes to the Spltierator JavaDoc and a tweak to the spec of Spliterator.trySplit. http://bugs.sun.com/view_bug.do?bug_id=8013334 Paul. # HG changeset patch # User psandoz # Date 1367571917 -7200 # Node ID fda6ca78a7c299349f201c310ec480351a855ed1

Re: Please review changes for JDK-8012975: Remove rhino from jdk8

On 03/05/2013 07:47, A. Sundararajan wrote: Thanks. Looks like the first one has not been removed. But second one was removed: hg stat shows R make/sun/org/mozilla/javascript/Makefile (also the webrev shows it as removed). Perhaps patch does not take care of deleted files?? I am not sure. A

Re: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit

Hi Paul, Maybe the JavaDoc could also suggest that the trySplit producing N+0 result should converge so that returned Spliterator eventualy produces either null+N or n+m (nnumber of steps. Also I don't know why would any Spliterator implementation want to return 0+N from trySplit (the N+0 retu

RFR 8007073: Implement Core Reflection for Type Annotations on parameters

Hello all, Here is an update to core reflection for type annotations adding support for reflecting over annotated type use on parameters. http://cr.openjdk.java.net/~jfranck/8007073/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007073 cheers /Joel

RFR 8013541: Revise javadoc for Executable.getAnnotatedReturnType()

Hello all, Also a small update to the javadoc of Executable to make it more consistent for type annotations. http://cr.openjdk.java.net/~jfranck/8013541/webrev.00/ For oracle reviewers, CCC is filed. cheers /Joel

Re: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

On 03/05/2013 00:08, Dan Xu wrote: Hi All, Thanks for all your comments. Based on the previous feedback, I have moved to the other approach, i.e., to fail file operations if the invalid NUL characher is found in a file path. As you know, due to the compatibility issue, we cannot throw an exce

Re: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time

On 03/05/2013 05:29, Xueming Shen wrote: : An alternative is to really implement the singleton pattern in ECP, however given the existing mechanism we have in Charset.java and the "hacky" init() implementation we need in ECP, I go with the current approach. http://cr.openjdk.java.net/~sherma

Re: JDK-8011653: Upgrade to JAXP 1.5

On 03/05/2013 09:01, huizhe wang wrote: Hi Alan, Lance, This is an update that reflects the spec change, and also fixes for JDK-8013232 and JDK-8013484. Please review: http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ I've read through the javadoc/spec changes. One comment is that the

Re: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time

On 5/3/13 7:18 AM, Alan Bateman wrote: On 03/05/2013 05:29, Xueming Shen wrote: : An alternative is to really implement the singleton pattern in ECP, however given the existing mechanism we have in Charset.java and the "hacky" init() implementation we need in ECP, I go with the current appro

Re: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

On 5/3/13 6:48 AM, Alan Bateman wrote: On 03/05/2013 00:08, Dan Xu wrote: Hi All, Thanks for all your comments. Based on the previous feedback, I have moved to the other approach, i.e., to fail file operations if the invalid NUL characher is found in a file path. As you know, due to the comp

Re: RFR: 7150256: Add back Diagnostic Command JMX API

Hi all, After an intense work with Mandy, here's a new webrev which fix the issue with the PlatformManagedObject specification. The DiagnosticCommandMBean is not a PlatformManagedObject anymore, it's just a DynamicMBean registered to the platform MBean server. Many smaller fixes have also been do

hg: jdk8/tl/langtools: 8012728: Normalize @ignore comments on langtools tests

Changeset: abd153854f16 Author:jjg Date: 2013-05-03 09:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/abd153854f16 8012728: Normalize @ignore comments on langtools tests Reviewed-by: vromero, mcimadamore ! test/com/sun/javadoc/_template/Template.java ! test/com/sun/

hg: jdk8/tl/langtools: 8002387: Improve rendered HTML formatting for {@code}

Changeset: 38c4bade0ec1 Author:jjg Date: 2013-05-03 10:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/38c4bade0ec1 8002387: Improve rendered HTML formatting for {@code} Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javadoc/Comment.java + test/com/sun/javadoc

Re: JDK-8011653: Upgrade to JAXP 1.5

Hi Joe, I am not a JAXP expert - so I've been discovering most of this code as I read it. It would be impossible for me to assess whether there's some setFeature or setProperty missing somewhere for instance. So with my limited knowledge I have only these few remarks: == 1. XalanConsta

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, > > Hi Tomas, > > I don't know if this is the case here, but what if the > ReferenceHandler thread is interrupted while wait()-ing and the > construction of InterruptedException triggers OOME? I am sure this is the case - previously I thought InterruptedException is a preallocated exception

Re: RFR : 8013528 : (XS) Provide SharedSecrets access to String(char[], boolean) constructor

On Apr 30 2013, at 23:41 , Peter Levart wrote: > Hi Mike, > > Some comments about the test... > > 40 String benchmark = "exemplar"; > 41 String constructorCopy = new String(benchmark); > 42 String jlaCopy = jla.newStringUnsafe(benchmark.toCharArray()); > 43 >

Re: RFR: 7150256: Add back Diagnostic Command JMX API

Frederic, This looks good. Thanks for the update and also move the native method and implementations to DiagnosticCommandImpl.c and removing the check for rdcmd_support which is much cleaner. Minor comment: DiagnosticCommandImpl.Wrapper constructor - it'd be good to catch the exception causi

Re: JDK-8011653: Upgrade to JAXP 1.5

On 5/3/2013 10:13 AM, Daniel Fuchs wrote: Hi Joe, I am not a JAXP expert - so I've been discovering most of this code as I read it. It would be impossible for me to assess whether there's some setFeature or setProperty missing somewhere for instance. So with my limited knowledge I have only the

Re: JDK-8011653: Upgrade to JAXP 1.5

On 5/3/2013 7:49 AM, Alan Bateman wrote: On 03/05/2013 09:01, huizhe wang wrote: Hi Alan, Lance, This is an update that reflects the spec change, and also fixes for JDK-8013232 and JDK-8013484. Please review: http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ I've read through the jav

Re: RFR: 7150256: Add back Diagnostic Command JMX API

Hi, On 5/3/13 8:02 PM, Mandy Chung wrote: 2. Investigate what DiagnosticCommandImpl.getAttributes and setAttributes should do per DynamicMBean spec. The current implementation throws UOE which seem to be okay. It's good to confirm what is specified or not specified per DynamicMBean spec By a

Re: RFR: 7150256: Add back Diagnostic Command JMX API

On 5/3/2013 11:19 AM, Daniel Fuchs wrote: Hi, On 5/3/13 8:02 PM, Mandy Chung wrote: 2. Investigate what DiagnosticCommandImpl.getAttributes and setAttributes should do per DynamicMBean spec. The current implementation throws UOE which seem to be okay. It's good to confirm what is specified or

Re: RFR: 7150256: Add back Diagnostic Command JMX API

Thank you Mandy, I'll file the bugs and fix the exception cause. Fred On 03/05/2013 20:02, Mandy Chung wrote: Frederic, This looks good. Thanks for the update and also move the native method and implementations to DiagnosticCommandImpl.c and removing the check for rdcmd_support which is much

Re: RFR: 7150256: Add back Diagnostic Command JMX API

I'll fix it and file a new bug. Fred On 03/05/2013 20:30, Mandy Chung wrote: On 5/3/2013 11:19 AM, Daniel Fuchs wrote: Hi, On 5/3/13 8:02 PM, Mandy Chung wrote: 2. Investigate what DiagnosticCommandImpl.getAttributes and setAttributes should do per DynamicMBean spec. The current implementat

Re: RFR: 7150256: Add back Diagnostic Command JMX API

MBeanServer.setAttributes() returns an AttributeList but the return type of DynamicMBean.setAttributes() is void. Does it mean that in our case, setAttributes() should simply be a no-op method? Fred On 03/05/2013 20:19, Daniel Fuchs wrote: Hi, On 5/3/13 8:02 PM, Mandy Chung wrote: 2. Investig

Re: RFR: 7150256: Add back Diagnostic Command JMX API

DynamicMBean: public AttributeList setAttributes(AttributeList attributes); Maybe you looked at setAttribute method. It's easily misread with and without 's'. On 5/3/2013 11:40 AM, frederic parain wrote: MBeanServer.setAttributes() returns an AttributeList but the return type of DynamicM

Re: RFR: 7150256: Add back Diagnostic Command JMX API

You're right. I'll update setAttributes() to return an empty AttributeList. Fred On 03/05/2013 20:53, Mandy Chung wrote: DynamicMBean: public AttributeList setAttributes(AttributeList attributes); Maybe you looked at setAttribute method. It's easily misread with and without 's'. On 5/3/

Re: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit

Hi Peter, On May 3, 2013, at 12:07 PM, Peter Levart wrote: > Hi Paul, > > Maybe the JavaDoc could also suggest that the trySplit producing N+0 result > should converge so that returned Spliterator eventualy produces either null+N > or n+m (n don't know why would any Spliterator implementation

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 05/03/2013 07:47 PM, Thomas Schatzl wrote: Hi, Hi Tomas, I don't know if this is the case here, but what if the ReferenceHandler thread is interrupted while wait()-ing and the construction of InterruptedException triggers OOME? I am sure this is the case - previously I thought InterruptedE

Re: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit

On 05/03/2013 09:10 PM, Paul Sandoz wrote: Hi Peter, On May 3, 2013, at 12:07 PM, Peter Levart > wrote: Hi Paul, Maybe the JavaDoc could also suggest that the trySplit producing N+0 result should converge so that returned Spliterator eventualy produces eithe

hg: jdk8/tl/jdk: 8013528: Provide SharedSecrets access to String(char[], boolean) constructor

Changeset: fc156b925259 Author:mduigou Date: 2013-05-03 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc156b925259 8013528: Provide SharedSecrets access to String(char[], boolean) constructor Reviewed-by: martin, alanb, chegar, plevart ! src/share/classes/java/lang/Sy

hg: jdk8/tl/jdk: 8005922: TEST_BUG: There is no /tmp directory for windows system.

Changeset: d7f3d5659c46 Author:juh Date: 2013-05-03 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7f3d5659c46 8005922: TEST_BUG: There is no /tmp directory for windows system. Reviewed-by: weijun ! test/sun/security/tools/policytool/ChangeUI.html ! test/sun/security/

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Personally, I think I'd exit the VM in this case. The odds of hitting OOM while allocating TIE and having it be just a very unfortunate transient condition are quite low; most likely, the VM is going to have lots of trouble elsewhere anyway. Also, by swallowing the OOM there and continuing makes

hg: jdk8/tl/langtools: 8008768: Using {@inheritDoc} in simple tag defined via -tag fails

Changeset: d918b63a5509 Author:jjg Date: 2013-05-03 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d918b63a5509 8008768: Using {@inheritDoc} in simple tag defined via -tag fails Reviewed-by: jjg, mduigou Contributed-by: jonathan.gibb...@oracle.com, mike.dui...@ora

Re: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull

I have updated the webrev to include incorporate the feedback I have received. http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/ Regarding the naming of the "nonNull" method. I originally added this method in 2011 but I've forgotten since then why it has the name it does. As best as I c