Re: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java

[Lance Andersen - Oracle]

I think this OK.

The comments with the o--o did not do much for me though and found them a bit 
confusing but perhaps I need more coffee this morning ?

Also, not sure we need the @author tag but I think its usage varies in the 
workspace

Best
Lance
On Mar 19, 2014, at 7:10 PM, David Li wrote:

 Hi,
 
 This is an update from Xerces for file impl/xpath/regex/TokenRange.java.  For 
 details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577.
 
 Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/
 
 Existing tests: JAXP SQE and unit tests passed.
 
 Test cases added for typo fix in RangeToken.intersectRanges.  Code also 
 updated to fix a bug where regular expression intersection returns incorrect 
 value when first range ends later than second range.   Example below. Test 
 cases have been added to cover any scenarios that the code changes affect.
 
 new RegularExpression((?[b-d][a-r])); - returns [b-d] (Correct)
 new RegularExpression((?[a-r][b-d])); - returns [b-de-r] (Incorrect)
 
 Thanks,
 David
 
 P.S. Notes on bug fixes.
 1) Line 404 removal of while loop.
 This fixes a new bug where incorrect results are given when first range ends 
 later than second range.  In the old code we got
 (?[a-r][b-d]) - returns [b-de-r]
 By removing the while loop, we get [b-d].
 This while loop looks like a copy-paste error from subtractRanges. In 
 subtractRanges we need to keep the leftover portion from the first range, but 
 this does not apply to intersection.
 
 2) Line 388, addition of src2 += 2;
 This code change affects anything of the form (?[a-r][b-eg-j]).  The code 
 execution is diagrammed below.
 oo  (src1)
  o--o o--o (src2)
 For the first match we get
 oo  (src1)
  o--o  (src2)
 Next we want to run src2+=2 to get the second pair of endpoints (since the 
 first two endpoints are already used).  Notice how src1begin has been updated 
 to this.ranges[src1] = src2end+1, which is directly from the code.
  o--o  (src1)
   o--o (src2)
 The src2+=2 statement was left out of the old code, and is added in this 
 webrev.  If we leave out the src2+=2 at line 388, on the next iteration of 
 the large while loop we will reach case } else if (src2end  src1begin) { 
 which also executes src2+=2.  This means the correct final result is 
 generated, but on a later loop. We want to add the new code because it's 
 better to have all associated variable updated in the sameloop.  In addition, 
 all the other conditions have similar src1 or src2 updates.
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java

[Lance Andersen - Oracle]

On Mar 5, 2014, at 3:37 PM, Xueming Shen wrote:

 nitpicking,
 
 (1) shouldn't the variable at #468 to be updated to lch instead of uch as 
 well?

I would agree given you are now calling Character.toLowerCase
 (2) StringBuilder can be used to replace the StringBuffer in toString().
Agree, but I think this could be considered optional for this putback...


 
 -Sherman
 
 On 03/05/2014 12:18 PM, David Li wrote:
 Hi,
 
 This is an update from Xerces for file impl/xpath/regex/TokenRange.java.  
 For details, please refer to: 
 https://bugs.openjdk.java.net/browse/JDK-8035577.
 
 Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/
 
 No new tests.  There were none added in Xerces.
 
 Existing tests: JAXP SQE and unit tests passed.
 
 Thanks,
 David
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java

[Lance Andersen - Oracle]

On Mar 5, 2014, at 5:10 PM, huizhe wang wrote:

 
 On 3/5/2014 12:46 PM, Lance Andersen - Oracle wrote:
 On Mar 5, 2014, at 3:37 PM, Xueming Shen wrote:
 
 nitpicking,
 
 (1) shouldn't the variable at #468 to be updated to lch instead of uch 
 as well?
 I would agree given you are now calling Character.toLowerCase
 
 Also, at line 463 and 464, it looks like 'uppers' meant to be 'lowers' 
 defined at 462.

I think we should add tests with this change it looks like we really need to 
test this if your suggestion above is correct.  
 
 (2) StringBuilder can be used to replace the StringBuffer in toString().
 Agree, but I think this could be considered optional for this putback...
 
 Yes, feel free to replace StringBuffer with StringBuilder, Vector to 
 ArrayList and etc.
 
 -Joe
 
 
 
 -Sherman
 
 On 03/05/2014 12:18 PM, David Li wrote:
 Hi,
 
 This is an update from Xerces for file impl/xpath/regex/TokenRange.java.  
 For details, please refer to: 
 https://bugs.openjdk.java.net/browse/JDK-8035577.
 
 Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/
 
 No new tests.  There were none added in Xerces.
 
 Existing tests: JAXP SQE and unit tests passed.
 
 Thanks,
 David
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering
 1 Network Drive
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR 9: 8032491: DateTimeFormatter fixed width adjacent value parsing does not match spec

[Lance Andersen - Oracle]

Looks Ok.  Kind of surprised the tck tests have no assertion details in the 
tests.  Minor nit would have been nice to have even a minor comment for the new 
method DateTimeFormatterBuilder though that seems to be the norm in some 
scenarios for the smaller methods.


On Feb 28, 2014, at 4:48 PM, roger riggs wrote:

 Please review this bug fix from Steve Colebourne for java.time parsing of
 fixed width adjacent values. The patch includes new tests.
 
 Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-parse-adjacent-8032491/
 
 Thanks, Roger
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR [4682009] Typo in javadocs in javax/naming

[Lance Andersen - Oracle]

Looks fine.  assume the code/code will be addressed as part of a full sweep 
of javax/naming
On Feb 14, 2014, at 2:48 PM, Ivan Gerasimov wrote:

 Hello!
 
 May I please have a review of the fix?
 
 It's not meant to be a proof reading, I only fixed some obvious typos.
 Some of them were reported at the time of java 1.4, so it is probably the 
 time to have them fixed.
 
 BUG: https://bugs.openjdk.java.net/browse/JDK-4682009
 WEBREV: http://cr.openjdk.java.net/~igerasim/4682009/0/webrev/
 
 Sincerely yours,
 Ivan


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Review request for JDK-8030010: cleanup native code warnings

[Lance Andersen - Oracle]

Hi Mandy

This looks OK to me

On Feb 12, 2014, at 12:46 PM, Mandy Chung wrote:

 This patch cleans up a few trivial native warnings (mainly remove local 
 unreferenced variable)
   https://bugs.openjdk.java.net/browse/JDK-8030010
 
 Webrev at:
 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8030010/webrev.00/
 
 This patch was contributed by Francis Andre [1] and I fixed a couple other 
 trivial ones.
 
 Mandy
 [1] http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011332.html


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR 8032221 Typo in java.util.date

[Lance Andersen - Oracle]

looks fine.  getting rid of tt and code, is something  I guess we  should 
look to do throughout all of our code?
On Jan 31, 2014, at 1:33 PM, roger riggs wrote:

 Please review a typo and javadoc cleanup for java.util.Date
 
 webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/
 
 Thanks, Roger
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP): 8032392 : Spec: javax.xml.stream.XMLEventFactory/XMLOutputFactory/XMLInputFactory.newFactory(String, ClassLoader) referring to ServiceLoader.load(Class, ClassLoader)

[Lance Andersen - Oracle]

+1
On Jan 24, 2014, at 3:31 PM, huizhe wang wrote:

 Hi,
 
 Please review a javadoc change to javax.xml.stream factories. This change 
 makes it clear that the two args ServiceLoader#load method is used when the 
 specified classLoader is not null.
 
 http://cr.openjdk.java.net/~joehw/jdk9/8032392/webrev/
 
 Thanks,
 Joe
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR JDK 9: 8032502: java.time add @param tags to readObject

[Lance Andersen - Oracle]

looks fine Roger as  am sure this will make the doclint warnings less 
On Jan 22, 2014, at 4:26 PM, roger riggs wrote:

 Please review this javadoc improvement to add @param tags to readObject
 
 Webrev:
 
   http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/
 
 Thanks, Roger
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 9 RFR of raw type lint fix to java.lang.management

[Lance Andersen - Oracle]

+1
On Jan 7, 2014, at 3:30 PM, Joe Darcy wrote:

 Hello,
 
 Please review another minor lint fix of a raw type issues in the core 
 libraries:
 
diff -r 2647b91dbc2a 
 src/share/classes/java/lang/management/ManagementFactory.java
 --- a/src/share/classes/java/lang/management/ManagementFactory.java Tue Jan 
 07 09:58:16 2014 -0800
 +++ b/src/share/classes/java/lang/management/ManagementFactory.java Tue Jan 
 07 12:29:22 2014 -0800
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -612,7 +612,7 @@
  is not an instance of  + mxbeanInterface);
 }
 
 -final Class[] interfaces;
 +final Class?[] interfaces;
 // check if the registered MBean is a notification emitter
 boolean emitter = connection.isInstanceOf(objName, NOTIF_EMITTER);
 
 
 Thanks,
 
 -Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 9 RFR of JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache}

[Lance Andersen - Oracle]

looks good Joe
On Jan 7, 2014, at 6:58 PM, Joe Darcy wrote:

 Hello,
 
 Please review the fix below to address
 
JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache}
 
 by a quick-and-dirty generification and deprecation of some very old classes
 
http://cr.openjdk.java.net/~darcy/8031369.0/
 
 Corresponding patch below.
 
 In the fullness of time, these classes should probably be removed from the 
 platform, but for the moment I'm more concerned with eliminating the several 
 dozen lint warnings in this code.
 
 Thanks,
 
 -Joe
 
 --- old/src/share/classes/sun/misc/Cache.java2014-01-07 
 15:51:32.0 -0800
 +++ new/src/share/classes/sun/misc/Cache.java2014-01-07 
 15:51:32.0 -0800
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1995, 1996, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -74,8 +74,9 @@
  * @see java.lang.Object#equals
  * @see sun.misc.Ref
  */
 +@Deprecated
 public
 -class Cache extends Dictionary {
 +class Cache extends DictionaryObject, Object {
 /**
  * The hash table data.
  */
 @@ -163,7 +164,7 @@
  * @see Cache#elements
  * @see Enumeration
  */
 -public synchronized Enumeration keys() {
 +public synchronized EnumerationObject keys() {
 return new CacheEnumerator(table, true);
 }
 
 @@ -173,7 +174,7 @@
  * @see Cache#keys
  * @see Enumeration
  */
 -public synchronized Enumeration elements() {
 +public synchronized EnumerationObject elements() {
 return new CacheEnumerator(table, false);
 }
 
 @@ -305,7 +306,7 @@
  * A Cache enumerator class.  This class should remain opaque
  * to the client. It will use the Enumeration interface.
  */
 -class CacheEnumerator implements Enumeration {
 +class CacheEnumerator implements EnumerationObject {
 boolean keys;
 int index;
 CacheEntry table[];
 --- old/src/share/classes/sun/misc/SoftCache.java2014-01-07 
 15:51:33.0 -0800
 +++ new/src/share/classes/sun/misc/SoftCache.java2014-01-07 
 15:51:33.0 -0800
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -101,8 +101,8 @@
  * @see java.lang.ref.SoftReference
  */
 
 -
 -public class SoftCache extends AbstractMap implements Map {
 +@Deprecated
 +public class SoftCache extends AbstractMapObject, Object implements 
 MapObject, Object {
 
 /* The basic idea of this implementation is to maintain an internal 
 HashMap
that maps keys to soft references whose referents are the keys' values;
 @@ -115,18 +115,18 @@
  */
 
 
 -static private class ValueCell extends SoftReference {
 +static private class ValueCell extends SoftReferenceObject {
 static private Object INVALID_KEY = new Object();
 static private int dropped = 0;
 private Object key;
 
 -private ValueCell(Object key, Object value, ReferenceQueue queue) {
 +private ValueCell(Object key, Object value, ReferenceQueueObject 
 queue) {
 super(value, queue);
 this.key = key;
 }
 
 private static ValueCell create(Object key, Object value,
 -ReferenceQueue queue)
 + ReferenceQueueObject queue)
 {
 if (value == null) return null;
 return new ValueCell(key, value, queue);
 @@ -154,10 +154,10 @@
 
 
 /* Hash table mapping keys to ValueCells */
 -private Map hash;
 +private MapObject, Object hash;
 
 /* Reference queue for cleared ValueCells */
 -private ReferenceQueue queue = new ReferenceQueue();
 +private ReferenceQueueObject queue = new ReferenceQueue();
 
 
 /* Process any ValueCells that have been cleared and enqueued by the
 @@ -189,7 +189,7 @@
  *   factor is less than zero
  */
 public SoftCache(int initialCapacity, float loadFactor) {
 -hash = new HashMap(initialCapacity, loadFactor);
 +hash = new HashMap(initialCapacity, loadFactor);
 }
 
 /**
 @@ -202,7 +202,7 @@
  *   or equal to zero
  */
 public SoftCache(int initialCapacity) {
 -hash = new HashMap(initialCapacity);
 +hash = new HashMap(initialCapacity);
 }
 
 /**
 @@ -210,7 +210,7 @@
  * capacity and the default load factor.
  */
 public SoftCache() {
 -hash = new HashMap();
 +hash = new HashMap();
 }
 
 
 @@ -348,13 +348,13 @@
 /* Internal class for 

Re: RFR java.time.Duration spec correction (8031103)

[Lance Andersen - Oracle]

looks fine Roger
On Jan 6, 2014, at 2:09 PM, roger riggs wrote:

 Please review this minor specification correction to the 
 java.time.Duration.toDays() and
 toHours() methods.  Only the javadoc is corrected, no code or tests are 
 affected.
 
 Webrev:
 http://cr.openjdk.java.net/~rriggs/webrev-duration-javadoc-8031103/
 
 Thanks, Roger
 
 JDK-8031103 https://bugs.openjdk.java.net/browse/JDK-8031103 
 java.time.Duration has wrong Javadoc Comments in toDays() and toHours()
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 9 RFR of JDK-8027063 SecurityManger.getClassContext returns a raw type

[Lance Andersen - Oracle]

+1
On Jan 6, 2014, at 3:53 PM, Joe Darcy wrote:

 Hello,
 
 Please review the simple change to fix JDK-8027063 
 SecurityManger.getClassContext returns a raw type, which changes a signature 
 of a protected method in SecurityManger to remove a use of raw types in the 
 core libraries:
 
 --- a/src/share/classes/java/lang/SecurityManager.javaMon Jan 06 11:48:32 
 2014 -0800
 +++ b/src/share/classes/java/lang/SecurityManager.javaMon Jan 06 12:51:52 
 2014 -0800
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1995, 2011, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -307,7 +307,7 @@
  *
  * @return  the execution stack.
  */
 -protected native Class[] getClassContext();
 +protected native Class?[] getClassContext();
 
 /**
  * Returns the class loader of the most recently executing method from
 
 A clean build succeeds and the SecurityManager tests pass after this change.
 
 Thanks,
 
 -Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 9 RFR of JDK-8031210 Remove serial warning from java.lang.Enum

[Lance Andersen - Oracle]

+1
On Jan 6, 2014, at 4:41 PM, Joe Darcy wrote:

 Hello,
 
 Please review the patch below to add a @SuppressWarning(serial) to 
 java.lang.Enum to resolve a lint warning in the core libraries.
 
 Thanks,
 
 -Joe
 
 --- a/src/share/classes/java/lang/Enum.javaMon Jan 06 11:48:32 2014 -0800
 +++ b/src/share/classes/java/lang/Enum.javaMon Jan 06 13:37:06 2014 -0800
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -52,6 +52,8 @@
  * @see java.util.EnumMap
  * @since   1.5
  */
 +@SuppressWarnings(serial) // No serialVersionUID needed due to
 +// special-casing of enum types.
 public abstract class EnumE extends EnumE
 implements ComparableE, Serializable {
 /**
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

[Lance Andersen - Oracle]

Dan,

Looks OK, but line 914 which you did not change, notice the comments not sure 
if that is common in this code but seemed a bit off to me:

914 //// If at first, you don't succeed...
On Jan 6, 2014, at 5:29 PM, Dan Xu wrote:

 Hi All,
 
 Please review the simple fix for JNI pending exceptions in 
 FileSystemPreferences.c. Thanks!
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8028726
 Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/
 
 -Dan


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package

[Lance Andersen - Oracle]

Hi Serge,
On Dec 20, 2013, at 9:16 AM, Serge wrote:

 Hi all.
 
 Please review a second fix
 http://cr.openjdk.java.net/~yan/8028712/webrev.03/
 
 for
 https://bugs.openjdk.java.net/browse/JDK-8028712
 
 I deleted part of java/sql/package.html,

I did not see the section below deleted, perhaps the change did not get pushed 
to where you generated the webrev from?
 and replaced br/ to br for compliance with html 3.2
 
 
 On 12/05/2013 10:39 PM, Lance Andersen - Oracle wrote:
 Hi Serge
 
 
 
 This looks OK.
 
 
 
 For
 
 --- old/src/share/classes/java/sql/package.html  2013-12-05 
 15:08:50.587885460 +
 +++ new/src/share/classes/java/sql/package.html  2013-12-05 
 15:08:50.435885464 +
 
 Please remove the following
 
 
 Package Specification
 
  . Specification of the JDBC 4.0 API
 Related Documentation
 
  . Getting Started--overviews of the major interfaces
  . Chapters on the JDBC API--from the online version of The Java 
 Tutorial Continued
  . JDBCTMAPI Tutorial and Reference, Third Edition-- a complete 
 reference and tutorial for the JDBC 3.0 API
 
 
 
 The above links keep breaking now that we are off of java.sun.com
 
 And I agree with roger, please use br
 
 
 Alan, yes I can look to clean up some of the formatting crud for Java SE 9 
 once we have access to the workspace
 
 Thank you for doing this Serge.
 
 Best
 Lance
 On Dec 5, 2013, at 10:31 AM, Alan Bateman wrote:
 
 On 05/12/2013 17:25, Serge wrote:
 Hi all,
 please review the fix
 http://cr.openjdk.java.net/~yan/8028712/webrev.02/ 
 http://cr.openjdk.java.net/%7Eyan/8028712/webrev.02/
 for
 https://bugs.openjdk.java.net/browse/JDK-8028712
 
 This patch cleanup tidy warnings for generated html documentation, and do
 not affect the appearance of the documentation.
 The removal of the p tags seems okay. The only thing that I'm not sure 
 about the addition of br/ to the package docs (is that needed?).
 
 Lance - while scanning this patch then it appears that some of the 
 formatting in the javadoc comments is all over the place 
 (java.sql.Connection is one example). It might be good to clean that up 
 once the jdk9 project is open for business.
 
 -Alan
 
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering
 1 Network Drive
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon parsing literals with 100 LF chars

[Lance Andersen - Oracle]

Joe,

I thought this looked OK also


On Dec 17, 2013, at 12:26 PM, huizhe wang wrote:

 
 On 12/17/2013 4:10 AM, Daniel Fuchs wrote:
 Hi Joe,
 
 The fix looks good - though I wonder at whether incrementing
 whiteSpaceLookup by a fix amount wouldn't be better than
 doubling its length.
 
 Both would be okay. The case, as demonstrated in the report, that there are 
 hundreds of LFs in an attribute, is very rare.
 
 Best,
 Joe
 
 
 best regards,
 
 -- daniel
 
 On 12/16/13 8:31 PM, huizhe wang wrote:
 Hi,
 
 This is a quick fix for a whitespace buffer that was not adjusted
 properly in one of the two cases.  The buffer, whiteSpaceLookup, is
 filled in two cases and adjusted properly the 2nd time. The code is
 moved into a method storeWhiteSpace so that it's shared for the 1st case
 as well.
 
 Note at line 1175, there is no need to save character 0x20 since all
 whitespace characters will later be replaced with character 0x20.
 
 webrevs:
 http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
 
 Thanks,
 Joe
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification

[Lance Andersen - Oracle]

looks fine joe
On Dec 11, 2013, at 4:10 PM, huizhe wang wrote:

 
 On 12/11/2013 12:21 PM, Alan Bateman wrote:
 On 11/12/2013 19:52, huizhe wang wrote:
 Hi,
 
 This is a quick documentation change to fix an error in 
 javax.xml.stream.XMLOutputFactory:
 
 http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
 
 Thanks,
 Joe
 It looks okay although I think it could be reduced to something like The 
 original method was incorrectly defined to return XMLInputFactory.
 
 Updated to use your statement:
 
 http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
 
 -Joe
 
 
 -Alan.
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package

[Lance Andersen - Oracle]

Hi Serge



This looks OK.



For

--- old/src/share/classes/java/sql/package.html 2013-12-05 15:08:50.587885460 
+
+++ new/src/share/classes/java/sql/package.html 2013-12-05 15:08:50.435885464 
+

Please remove the following


Package Specification

• Specification of the JDBC 4.0 API
Related Documentation

• Getting Started--overviews of the major interfaces
• Chapters on the JDBC API--from the online version of The Java 
Tutorial Continued
• JDBCTMAPI Tutorial and Reference, Third Edition-- a complete 
reference and tutorial for the JDBC 3.0 API



The above links keep breaking now that we are off of java.sun.com

And I agree with roger, please use br


Alan, yes I can look to clean up some of the formatting crud for Java SE 9 once 
we have access to the workspace

Thank you for doing this Serge.

Best
Lance
On Dec 5, 2013, at 10:31 AM, Alan Bateman wrote:

 On 05/12/2013 17:25, Serge wrote:
 Hi all,
 please review the fix
 http://cr.openjdk.java.net/~yan/8028712/webrev.02/ 
 http://cr.openjdk.java.net/%7Eyan/8028712/webrev.02/
 for
 https://bugs.openjdk.java.net/browse/JDK-8028712
 
 This patch cleanup tidy warnings for generated html documentation, and do
 not affect the appearance of the documentation.
 The removal of the p tags seems okay. The only thing that I'm not sure 
 about the addition of br/ to the package docs (is that needed?).
 
 Lance - while scanning this patch then it appears that some of the formatting 
 in the javadoc comments is all over the place (java.sql.Connection is one 
 example). It might be good to clean that up once the jdk9 project is open for 
 business.
 
 -Alan
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8029489: StringJoiner spec for setEmptyValue() and length() is malformatted

[Lance Andersen - Oracle]

looks OK
On Dec 3, 2013, at 8:40 PM, Stuart Marks wrote:

 Hi all,
 
 Please review the following small javadoc change. The StringJoiner doc for a 
 couple methods uses i.e. in the first sentence, which screws up the javadoc 
 logic that pulls the first sentence into the Method Summary. This is an 
 editorial change to fix this up; there is no actual specification change.
 
 Thanks!
 
 s'marks
 
 # HG changeset patch
 # User smarks
 # Date 1386121046 28800
 # Node ID 0bc91b9f6afd9b4dceea31ecd1036e367b365690
 # Parent  75165f6c1c505ff43f7fd235a95b2e7955413b78
 8029489: StringJoiner spec for setEmptyValue() and length() is malformatted
 Reviewed-by: XXX
 
 diff -r 75165f6c1c50 -r 0bc91b9f6afd 
 src/share/classes/java/util/StringJoiner.java
 --- a/src/share/classes/java/util/StringJoiner.java   Tue Dec 03 17:25:28 
 2013 -0800
 +++ b/src/share/classes/java/util/StringJoiner.java   Tue Dec 03 17:37:26 
 2013 -0800
 @@ -131,7 +131,7 @@
 /**
  * Sets the sequence of characters to be used when determining the string
  * representation of this {@code StringJoiner} and no elements have been
 - * added yet, i.e. when it is empty.  A copy of the {@code emptyValue}
 + * added yet, that is, when it is empty.  A copy of the {@code 
 emptyValue}
  * parameter is made for this purpose. Note that once an add method has 
 been
  * called, the {@code StringJoiner} is no longer considered empty, even if
  * the element(s) added correspond to the empty {@code String}.
 @@ -228,8 +228,8 @@
 }
 
 /**
 - * The length of the {@code StringJoiner} value, i.e. the length of
 - * {@code String} representation of the {@code StringJoiner}. Note that 
 if
 + * Returns the length of the {@code String} representation
 + * of this {@code StringJoiner}. Note that if
  * no add methods have been called, then the length of the {@code String}
  * representation (either {@code prefix + suffix} or {@code emptyValue})
  * will be returned. The value should be equivalent to


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Review request 8029417: Minor javadoc cleanup for JDBC 4.2

[Lance Andersen - Oracle]

Hi all

This is a review request for some minor javadoc clarifications for JDBC 4.2 
based on some feedback that I received.

The webrev can be found http://cr.openjdk.java.net/~lancea/8029417/webrev.00

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories

[Lance Andersen - Oracle]

looks OK Joe
On Nov 26, 2013, at 5:27 PM, huizhe wang wrote:

 
 On 11/26/2013 1:59 PM, roger riggs wrote:
 Hi,
 
 I looked at that twice also.java.time had a similar situation.
 
 To get to the TCCL you need to call ServiceLoader.load(type).
 
 The FactoryFinder:348 findServiceProvider method should test if cl == null 
 and call the original ServiceLoader function.
 
 Yes. I forgot that part. load(service, loader) treats null as the system 
 class loader was one of the topics in the discussion of the spec.
 
 Joe
 
 
 Roger
 
 On 11/26/2013 4:37 PM, Alan Bateman wrote:
 On 26/11/2013 18:38, huizhe wang wrote:
 Hi all,
 
 Here's revised webrev, as Alan suggested, including the implementation.
 
 http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/
 So is this handling the null case correctly? It is spec'ed to use the TCCL 
 but it looks like it's going through to ServiceLoader.load where null means 
 the system class loader. Maybe this needs to wait for tests as that it 
 really the only way to check this.
 
 -Alan
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JDK-8028631 - Improve the test coverage to the pathname handling on unix-like platforms

[Lance Andersen - Oracle]

The changes seem OK.  I did not run the tests though
On Nov 19, 2013, at 2:08 PM, Dan Xu wrote:

 Hi All,
 
 We have java/io/pathNames/GeneralWin32.java testcase to do the general 
 exhaustive test of pathname handling on windows. I am adding a new test 
 GeneralSolaris.java to test the pathname handling in unix-like platforms. In 
 the changes, I also make sure the test can run successfully in concurrency 
 mode. Please help review it. Thanks!
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8028631
 Webrev: http://cr.openjdk.java.net/~dxu/8028631/webrev/
 
 -Dan


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails

[Lance Andersen - Oracle]

looks fine
On Nov 19, 2013, at 5:24 PM, Stuart Marks wrote:

 Hi all,
 
 Please review this small fix for an intermittent timeout. Nothing seems to be 
 going wrong except that if the machine running the test is exceptionally 
 slow, spurious timeouts will occur. The solution is to raise the timeout in 
 the RMI test infrastructure.
 
 Bug:
   https://bugs.openjdk.java.net/browse/JDK-8028638
 
 Diff:
   (appended below)
 
 Thanks,
 
 s'marks
 
 
 # HG changeset patch
 # User smarks
 # Date 1384899795 28800
 # Node ID ebbfb1b45a4e6b37d339942568a662268dcb18fe
 # Parent  67d742c759717ca17518aaadb17725cac85c5897
 8028638: 
 java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java 
 fails
 Reviewed-by: XXX
 
 diff -r 67d742c75971 -r ebbfb1b45a4e test/java/rmi/testlibrary/RMID.java
 --- a/test/java/rmi/testlibrary/RMID.java Tue Nov 19 20:10:58 2013 +0100
 +++ b/test/java/rmi/testlibrary/RMID.java Tue Nov 19 14:23:15 2013 -0800
 @@ -74,6 +74,10 @@
 // +
 //  -Djava.security.debug=all ;
 
 +// Set execTimeout to 60 sec (default is 30 sec)
 +// to avoid spurious timeouts on slow machines.
 +options +=  -Dsun.rmi.activation.execTimeout=6;
 +
 return options;
 }
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter

[Lance Andersen - Oracle]

looks fine joe
On Nov 13, 2013, at 3:02 PM, huizhe wang wrote:

 Hi,
 
 The issue is that the limits applied to each processing process rather than 
 each file processing. This applies to not only StAX as reported, but also 
 other parsers and validators. The fix is to add reset to XMLSecurityManager 
 and call it upon each file processing. XSLT Transform is verified fixed as 
 the underlying parsers are fixed.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/
 
 Thanks,
 Joe
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 8 RFR: more core libs raw warnings cleanup

[Lance Andersen - Oracle]

Looks Ok Joe
On Nov 12, 2013, at 4:28 AM, Joe Darcy wrote:

 Hello,
 
 Please review the patch below which would remove another batch of raw type 
 javac lint warnings from the core libraries.
 
 No signatures of public or protected methods in the Java SE specification 
 have been modified. Regression tests in affected areas pass.
 
 Thanks,
 
 -Joe
 
 diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectOutputStream.java
 --- a/src/share/classes/java/io/ObjectOutputStream.javaSat Nov 09 
 04:21:28 2013 +0400
 +++ b/src/share/classes/java/io/ObjectOutputStream.javaTue Nov 12 
 00:51:15 2013 -0800
 @@ -1248,7 +1248,7 @@
 handles.assign(unshared ? null : desc);
 
 Class? cl = desc.forClass();
 -Class[] ifaces = cl.getInterfaces();
 +Class?[] ifaces = cl.getInterfaces();
 bout.writeInt(ifaces.length);
 for (int i = 0; i  ifaces.length; i++) {
 bout.writeUTF(ifaces[i].getName());
 diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectStreamClass.java
 --- a/src/share/classes/java/io/ObjectStreamClass.javaSat Nov 09 04:21:28 
 2013 +0400
 +++ b/src/share/classes/java/io/ObjectStreamClass.javaTue Nov 12 00:51:15 
 2013 -0800
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1996, 2011, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -1746,7 +1746,7 @@
 dout.writeUTF(()V);
 }
 
 -Constructor[] cons = cl.getDeclaredConstructors();
 +Constructor?[] cons = cl.getDeclaredConstructors();
 MemberSignature[] consSigs = new MemberSignature[cons.length];
 for (int i = 0; i  cons.length; i++) {
 consSigs[i] = new MemberSignature(cons[i]);
 diff -r 9fcb07df1c92 src/share/classes/java/lang/reflect/Proxy.java
 --- a/src/share/classes/java/lang/reflect/Proxy.javaSat Nov 09 04:21:28 
 2013 +0400
 +++ b/src/share/classes/java/lang/reflect/Proxy.javaTue Nov 12 00:51:15 
 2013 -0800
 @@ -494,9 +494,10 @@
 private final int hash;
 private final WeakReferenceClass?[] refs;
 
 +@SuppressWarnings({rawtypes, unchecked})
 KeyX(Class?[] interfaces) {
 hash = Arrays.hashCode(interfaces);
 -refs = new WeakReference[interfaces.length];
 +refs = (WeakReferenceClass?[])new 
 WeakReference[interfaces.length];
 for (int i = 0; i  interfaces.length; i++) {
 refs[i] = new WeakReference(interfaces[i]);
 }
 diff -r 9fcb07df1c92 src/share/classes/java/nio/file/TempFileHelper.java
 --- a/src/share/classes/java/nio/file/TempFileHelper.javaSat Nov 09 
 04:21:28 2013 +0400
 +++ b/src/share/classes/java/nio/file/TempFileHelper.javaTue Nov 12 
 00:51:15 2013 -0800
 @@ -81,7 +81,7 @@
String prefix,
String suffix,
boolean createDirectory,
 -   FileAttribute[] attrs)
 +   FileAttribute?[] attrs)
 throws IOException
 {
 if (prefix == null)
 @@ -155,7 +155,7 @@
 static Path createTempFile(Path dir,
String prefix,
String suffix,
 -   FileAttribute[] attrs)
 +   FileAttribute?[] attrs)
 throws IOException
 {
 return create(dir, prefix, suffix, false, attrs);
 @@ -167,7 +167,7 @@
  */
 static Path createTempDirectory(Path dir,
 String prefix,
 -FileAttribute[] attrs)
 +FileAttribute?[] attrs)
 throws IOException
 {
 return create(dir, prefix, null, true, attrs);
 diff -r 9fcb07df1c92 src/share/classes/java/util/IdentityHashMap.java
 --- a/src/share/classes/java/util/IdentityHashMap.javaSat Nov 09 04:21:28 
 2013 +0400
 +++ b/src/share/classes/java/util/IdentityHashMap.javaTue Nov 12 00:51:15 
 2013 -0800
 @@ -1243,7 +1243,7 @@
 if (ti = size) {
 throw new ConcurrentModificationException();
 }
 -a[ti++] = (T) new 
 AbstractMap.SimpleEntry(unmaskNull(key), tab[si + 1]);
 +a[ti++] = (T) new 
 AbstractMap.SimpleEntry(unmaskNull(key), tab[si + 1]);
 }
 }
 // fewer elements than expected or concurrent modification from 
 other thread detected
 diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logger.java
 --- a/src/share/classes/java/util/logging/Logger.javaSat Nov 09 04:21:28 
 2013 +0400
 +++ b/src/share/classes/java/util/logging/Logger.javaTue Nov 12 

Re: RFR(2): 7174936: several String methods claim to always create new String

[Lance Andersen - Oracle]

The wording changes seem fine to me.

Thanks for the specdiff as it made it much easier to review


On Nov 12, 2013, at 11:43 AM, Stuart Marks wrote:

 Hi all,
 
 Here's an updated version of the String spec change. Changes from the 
 previous version address comments made by Brent Christian and David Holmes. 
 Specifically:
 
 - Specify copyValueOf() overloads as equivalent to corresponding valueOf() 
 overloads.
 - Remove extranous changes to subSequence() method
 - Clarify wording of concat() method doc.
 
 Bug report:
 
   https://bugs.openjdk.java.net/browse/JDK-7174936
 
 Webrev:
 
   http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.1/
 
 Specdiff:
 
   
 http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.1/overview-summary.html
 
 Thanks!
 
 s'marks
 
 On 11/7/13 2:31 AM, Stuart Marks wrote:
 Hi all,
 
 Please review the following spec changes to java.lang.String.
 
 In several places the specs mention returning new strings. This is
 overspecified; it's sufficient to return a string that satisfies the 
 required
 properties. In some cases the current implementation doesn't create a new 
 string
 -- for example, substring(0) returns 'this' -- which is strictly a violation 
 of
 the spec. The solution is to relax the spec requirement to create new 
 strings.
 
 Also, this change cleans up the specs for the copyValueOf() overloads to make
 them identical to the corresponding valueOf() overloads. Previously, they 
 were
 gratuitously different. I think that some time in the dim, distant past,
 probably before JDK 1.0, they had different semantics, but now they're
 identical. The specs should say they're identical.
 
 This change is spec only, no code changes.
 
 Bug report:
 
 https://bugs.openjdk.java.net/browse/jdk-7174936
 
 Webrev:
 
 http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/
 
 Specdiff:
 
 
 http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html
 
 Thanks!
 
 s'marks


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess

[Lance Andersen - Oracle]

+1
On Nov 12, 2013, at 2:29 PM, Mandy Chung wrote:

 This is a simple code deletion in sun.misc.JavaAWTAccess and its 
 implementation class:
 
 Webrev:
 http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/
 
 This patch removes the methods from sun.misc.JavaAWTAccess that are no longer 
 used.  The only dependency remaining from core-libs to AppContext is the 
 ability to obtain an opaque unique object to represent an applet context ifit 
 is running in an applet environment.
 
 thanks
 Mandy


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK RFR to clean-up lint warnings in reflection implementation

[Lance Andersen - Oracle]

looks fine Joe
On Nov 8, 2013, at 2:40 PM, Joe Darcy wrote:

 Hello,
 
 Please review the simple patch below which addresses a handful of raw types 
 lint warning in the core reflection implementation code.
 
 (If memory serves, this code dates back from a time during the development of 
 JDK 5 when wildcards could not be used with arrays; before the release 
 shipped, that combination was allowed.)
 
 Thanks,
 
 -Joe
 
 diff -r 46982ca895b4 
 src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
 --- 
 a/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
  Fri Nov 08 18:54:29 2013 +
 +++ 
 b/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
  Fri Nov 08 11:37:54 2013 -0800
 @@ -52,7 +52,7 @@
 }
 
 private void validateConstructorArguments() {
 -TypeVariable/*?*/[] formals = rawType.getTypeParameters();
 +TypeVariable?[] formals = rawType.getTypeParameters();
 // check correct arity of actual type args
 if (formals.length != actualTypeArguments.length){
 throw new MalformedParameterizedTypeException();
 diff -r 46982ca895b4 
 src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
 --- 
 a/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
  Fri Nov 08 18:54:29 2013 +
 +++ 
 b/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
  Fri Nov 08 11:37:54 2013 -0800
 @@ -42,7 +42,7 @@
 public abstract class GenericDeclRepositoryS extends Signature
 extends AbstractRepositoryS {
 
 -private TypeVariable[] typeParams; // caches the formal type parameters
 +private TypeVariable?[] typeParams; // caches the formal type 
 parameters
 
 protected GenericDeclRepository(String rawSig, GenericsFactory f) {
 super(rawSig, f);
 @@ -64,7 +64,7 @@
  * Return the formal type parameters of this generic declaration.
  * @return the formal type parameters of this generic declaration
  */
 -public TypeVariable/*?*/[] getTypeParameters(){
 +public TypeVariable?[] getTypeParameters(){
 if (typeParams == null) { // lazily initialize type parameters
 // first, extract type parameter subtree(s) from AST
 FormalTypeParameter[] ftps = getTree().getFormalTypeParameters();
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Simple 1-line fix for 8027943 to fix serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImp

[Lance Andersen - Oracle]

+1
On Nov 7, 2013, at 4:59 PM, Mandy Chung wrote:

 This reverts 
 com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl back to the 
 previous serial version.
 
 diff --git 
 a/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java
  
 b/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java
 --- 
 a/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java
 +++ 
 b/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java
 @@ -89,4 +89,6 @@
 sm.checkPermission(perm);
 }
 }
 +
 +private static final long serialVersionUID = 4571178305984833743L;
 }
 
 Webrev:
 http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027943/webrev.00/
 
 Mandy
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR doc only typo in java.io.DataInput

[Lance Andersen - Oracle]

+1
On Nov 7, 2013, at 5:29 PM, roger riggs wrote:

 Please review this straightforward typo correction:
 
 Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-doc-readlong-8024458/
 
 Thanks, Roger
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP): 8024378 : StAX parser shall support JAXP properties

[Lance Andersen - Oracle]

Hi Joe,

I think this is all OK

Best
Lance
On Oct 30, 2013, at 11:40 AM, huizhe wang wrote:

 
 On 10/30/2013 2:58 AM, Daniel Fuchs wrote:
 On 10/30/13 1:14 AM, huizhe wang wrote:
 I updated the webrev to also fix the error message that showed the
 actual number of attributes parsed rather than the limit itself.
 
 http://cr.openjdk.java.net/~joehw/jdk8/8024378/webrev/
 
 Thanks,
 Joe
 
 Hi Joe,
 
 Looks good to me. I see another change, which is that now reset() will
 also do:
   fInScanContent = false;
 But by the look of it I suspect it was a bug that it did not reset it
 previously?
 
 Yes.  But since fInScanContent is always being reset to false after a scan, 
 this is actually redundant. It was previously in 
 reset(XMLComponentManager...) but not reset(PropertyManager ...).
 
 best,
 Joe
 
 
 best regards,
 
 -- daniel
 
 
 
 On 10/29/2013 4:49 PM, huizhe wang wrote:
 It appears the previous patch was one line short of supporting setting
 the JAXP's new property ElementAttributeLimit through the StAX
 factory, that is, resetting the variable in reset(PropertyManager
 propertyManager) as well.  Other than that, I also moved the common
 reset items from reset(XMLComponentManager...) and
 reset(PropertyManager ...) to a new method called resetCommon.
 
 webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8024378/webrev/
 
 The real change is to set the following in both reset methods, now in
 resetCommon:
 
 663 fElementAttributeLimit =
 fSecurityManager.getLimit(XMLSecurityManager.Limit.ELEMENT_ATTRIBUTE_LIMIT);
  
 
 
 
 Thanks,
 Joe
 
 
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP): 8027484 : Implementation error in SAX2DOM.java

[Lance Andersen - Oracle]

+1
On Oct 29, 2013, at 5:13 PM, huizhe wang wrote:

 A quick fix to add the missing braces and correct the misspellings.
 
 webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8027484/webrev/
 
 The following is where the braces were missing, others were a global 
 substitution of the misspelling.
 
 if (_factory == null) {
 -if (useServicesMachnism)
 +if (useServicesMechanism) {
 _factory = DocumentBuilderFactory.newInstance();
 if (!(_factory instanceof 
 com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl)) {
 _internal = false;
 }
 -else
 +} else {
 _factory = DocumentBuilderFactory.newInstance(
   
 com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl,
   SAX2DOM.class.getClassLoader()
   );
 }
 +}
 
 
 Thanks
 Joe
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: minor doc fixes for java.util.Formatter

[Lance Andersen - Oracle]

+1
On Oct 25, 2013, at 4:50 PM, Stuart Marks wrote:

 Hi all,
 
 Please review a few minor javadoc fixes in java.util.Formatter. Links to bugs 
 are:
 
 https://bugs.openjdk.java.net/browse/JDK-5063500
 https://bugs.openjdk.java.net/browse/JDK-7126305
 https://bugs.openjdk.java.net/browse/JDK-8027287
 
 The fixes are all one-liners so I've just appended the patch below.
 
 This obviously isn't a high priority but I wanted something easy to do on a 
 Friday. :-) Thanks to Joe Bowbeer for pointing out JDK-8027287.
 
 s'marks
 
 
 
 
 
 # HG changeset patch
 # User smarks
 # Date 1382732684 25200
 # Node ID 5bd0c1de275f8f779bf7a4ac5be035ffe2a161f1
 # Parent  1153022c0a453ee2e31f4c7572d2d2522674a096
 5063500: Formatter spec says char is not an integral type
 7126305: Wrong Unicode value specified for format conversion character 'd'
 8027287: incorrect example in Formatter javadoc
 Reviewed-by: XXX
 
 diff -r 1153022c0a45 -r 5bd0c1de275f 
 src/share/classes/java/util/Formatter.java
 --- a/src/share/classes/java/util/Formatter.java  Fri Oct 25 13:01:11 
 2013 +0200
 +++ b/src/share/classes/java/util/Formatter.java  Fri Oct 25 13:24:44 
 2013 -0700
 @@ -131,7 +131,7 @@
  *   import static java.util.Calendar.*;
  *
  *   Calendar c = new GregorianCalendar(1995, MAY, 23);
 - *   String s = String.format(Duke's Birthday: %1$tm %1$te,%1$tY, c);
 + *   String s = String.format(Duke's Birthday: %1$tb %1$te, %1$tY, c);
  *   // -gt; s == Duke's Birthday: May 23, 1995
  * /pre/blockquote
  *
 @@ -253,7 +253,7 @@
  * li bIntegral/b - may be applied to Java integral types: {@code byte},
  * {@link Byte}, {@code short}, {@link Short}, {@code int} and {@link
  * Integer}, {@code long}, {@link Long}, and {@link java.math.BigInteger
 - * BigInteger}
 + * BigInteger} (but not {@code char} or {@link Character})
  *
  * libFloating Point/b - may be applied to Java floating-point types:
  * {@code float}, {@link Float}, {@code double}, {@link Double}, and {@link
 @@ -899,7 +899,7 @@
  * table cellpadding=5 summary=IntConv
  *
  * trtd valign=top {@code 'd'}
 - * td valign=top tt'#92;u0054'/tt
 + * td valign=top tt'#92;u0064'/tt
  * td Formats the argument as a decimal integer. The a
  * href=#L10nAlgorithmlocalization algorithm/a is applied.
  *
 @@ -1057,7 +1057,7 @@
  * table cellpadding=5 summary=BIntConv
  *
  * trtd valign=top {@code 'd'}
 - * td valign=top tt'#92;u0054'/tt
 + * td valign=top tt'#92;u0064'/tt
  * td Requires the output to be formatted as a decimal integer. The a
  * href=#L10nAlgorithmlocalization algorithm/a is applied.
  *


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP enableExtensionFunctions): 8004476 XSLT Extension Functions Don't Work in WebStart

[Lance Andersen - Oracle]

looks OK joe
On Oct 23, 2013, at 3:42 PM, huizhe wang wrote:

 Hi Daniel,
 
 Thanks for the review and the detailed list. I've updated the webrev:
 
 http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/
 
 Thanks,
 Joe
 
 On 10/23/2013 11:25 AM, Daniel Fuchs wrote:
 Hi Joe,
 
 I believe all the private FeatureManager could be declared
 final since asfar as I can tell they are only set within
 the constructor.
 
 You could add 'final' to all declaration below:
 
 XSLTC.java:
 
 53 private FeatureManager _featureManager;
 
 TransformerFactoryImpl.java:
 
 232 private FeatureManager _featureManager;
 
 XPathExpressionImpl.java:
 
 72 private FeatureManager featureManager;
 
 XPathFactoryImpl.java:
 
 73 private FeatureManager _featureManager;
 
 XPathImpl.java:
 
  74 FeatureManager featureManager;
 
 Otherwise looks good.
 
 -- daniel
 
 On 10/22/13 6:55 PM, huizhe wang wrote:
 Hi,
 
 This is a new implementation property that is consistent with recent
 additions as in JAXP 1.5 in that the scope and order are the same, refer
 to http://docs.oracle.com/javase/tutorial/jaxp/properties/scope.html. By
 default, feature enableExtensionFunctions is true. When
 FEATURE_SECURE_PROCESSING is set to true, the property is set to false
 allowing no extension functions. Setting FSP to false however will not
 change the value.
 
 The property enableExtensionFunctions is supported by the following API:
 
  TransformerFactory factory = TransformerFactory.newInstance();
  factory.setFeature(name, value);
 
  XPathFactory factory = XPathFactory.newInstance();
  factory.setFeature(name, value);
 
 
 Webrevs:
 http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/
 
 Thanks,
 Joe
 
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Please Review javadoc fixes 8026982

[Lance Andersen - Oracle]

Overall, I think is this good.

I think in MessageDigest


--- old/src/share/classes/java/security/MessageDigest.java  2013-10-21 
17:31:32.734881244 -0400
+++ new/src/share/classes/java/security/MessageDigest.java  2013-10-21 
17:31:32.558891607 -0400
@@ -54,21 +54,21 @@
  *
  * pImplementations are free to implement the Cloneable interface.
  * Client applications can test cloneability by attempting cloning
- * and catching the CloneNotSupportedException: p
+ * and catching the CloneNotSupportedException:
  *
-* pre
-* MessageDigest md = MessageDigest.getInstance(SHA);
-*
-* try {
-* md.update(toChapter1);
-* MessageDigest tc1 = md.clone();
-* byte[] toChapter1Digest = tc1.digest();
-* md.update(toChapter2);
-* ...etc.
-* } catch (CloneNotSupportedException cnse) {
-* throw new DigestException(couldn't make digest of partial content);
-* }
-* /pre
+ * pre
+ * MessageDigest md = MessageDigest.getInstance(SHA);
+ *
+ * try {
+ * md.update(toChapter1);
+ * MessageDigest tc1 = md.clone();
+ * byte[] toChapter1Digest = tc1.digest();
+ * md.update(toChapter2);
+ * ...etc.
+ * } catch (CloneNotSupportedException cnse) {
+ * throw new DigestException(couldn't make digest of partial content);
+ * }
+ * /pre


The above should be in @code{} ?
On Oct 22, 2013, at 2:53 PM, roger riggs wrote:

 Please review more javadoc cleanup to satisfy javadoc -Xlint.
 The changes remove p markup where it is invalid or unnecessary
 in packages java. io, lang, net, nio, rmi, security, text, and util.
 (this is a relatively low priority cleanup).
 
 Webrev:
 
 http://cr.openjdk.java.net/~rriggs/webrev-javadoc-8026982/
 
 Thanks, Roger
 
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Please Review javadoc warning fixes to java.lang.invoke

[Lance Andersen - Oracle]

+1
On Oct 17, 2013, at 1:15 PM, roger riggs wrote:

 Please review a couple of issues with javadoc in java.lang.invoke to cleanup 
 javadoc warnings.
 
 https://bugs.openjdk.java.net/browse/JDK-8026183
 https://bugs.openjdk.java.net/browse/JDK-8015808
 
 Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-invoke-javadoc-8026183/
 
 Thanks, Roger
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP) : 8015243 : SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI.

[Lance Andersen - Oracle]

+1
On Oct 16, 2013, at 2:53 PM, huizhe wang wrote:

 Hi,
 
 This is a conformance issue. The issue is that a JCK test fails since invalid 
 URI such as // was not caught. The fix is to check and allow empty 
 authority only if there's non empty path, query component or fragment 
 identifier.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8015243/webrev/
 
 Thanks,
 Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Review request 8026812, doclint clean up for java.sql and javax.sql

[Lance Andersen - Oracle]

Hi all,

Need a reviewer for 8026812 which addresses the new doclint warnings.

Webrev is at:  http://cr.openjdk.java.net/~lancea/8026812/webrev.00/

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Please Review javadoc cleanup 8026516

[Lance Andersen - Oracle]

Hi Roger,

I think what you have done is OK.

I do have questions on should more be done in general so that we use P /P 
(as I thought that was no required vs just a solo P?).   As I started to look 
through some of the JDBC warnings,  I saw more tags that I thought should have 
been reported by doclint as there were no closing /P.  I see similar 
scenarios in for example Instant.java

Trying to figure out how much we really need to do

Best
Lance
On Oct 16, 2013, at 4:15 PM, roger riggs wrote:

 Hi,
 
 Javadoc cleanup to satisfy javadoc -Xlint.
 
 Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-javadoc-8026516/
 
 Thanks, Roger
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Please Review javadoc cleanup 8026516

[Lance Andersen - Oracle]

Hi Roger
On Oct 16, 2013, at 4:50 PM, roger riggs wrote:

 Hi Lance,
 
 The empty p tag is because in most cases it precedes a ul or a header 
 hx .  
 So there is no content in the paragraph.

I was referring more to an example such as this in Instant.java

* h3Time-scale/h3
 * p
 * The length of the solar day is the standard way that humans measure time.
 * This has traditionally been subdivided into 24 hours of 60 minutes of 60 
seconds,
 * forming a 86400 second day.
 * p

I believe this is no longer correct with the current html standards.  tidy 
complained to me when I ran against one my my doclint reported javadocs for 
tags like that that I did not fix (and a slew of other errors which I am
going to let go for now).

Just trying to know if it is just enough to address what doclint is complaining 
about or should I go further?


Best
Lance
 
 In the past using an empty p tag created some empty vertical space; 
 but i understand that's a misuse of p.
 I didn't try to compensate for that in my updates but it does change the 
 appearance since
 the vertical space gone.  I'll have to look to see if there is some spacing 
 control for ul
 that would restore the spacing.
 
 Roger
 
 On 10/16/2013 4:37 PM, Lance Andersen - Oracle wrote:
 Hi Roger,
 
 I think what you have done is OK.
 
 I do have questions on should more be done in general so that we use P 
 /P (as I thought that was no required vs just a solo P?).   As I started 
 to look through some of the JDBC warnings,  I saw more tags that I thought 
 should have been reported by doclint as there were no closing /P.  I see 
 similar scenarios in for example Instant.java
 
 Trying to figure out how much we really need to do
 
 Best
 Lance
 On Oct 16, 2013, at 4:15 PM, roger riggs wrote:
 
 Hi,
 
 Javadoc cleanup to satisfy javadoc -Xlint.
 
 Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-javadoc-8026516/
 
 Thanks, Roger
 
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering 
 1 Network Drive 
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP) : 8003262 reverse translation required changes

[Lance Andersen - Oracle]

Hi Joe,

I skimmed all of the changes and they look in line with the previous so +1

Best
Lance
On Oct 10, 2013, at 12:47 PM, huizhe wang wrote:

 Hi Daniel, Lance,
 
 I've updated the webrev to include other resource bundles. The changes are 
 the same.
 
 http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/
 
 Thanks,
 Joe
 
 
 On 10/9/2013 10:58 AM, Lance Andersen - Oracle wrote:
 +1
 On Oct 9, 2013, at 1:35 PM, huizhe wang wrote:
 
 Hi,
 
 These resource bundles in JAXP were refactored due to request by WPTG. Now 
 that the WPTG tool has been approved to support the original format, I'm 
 reverting the previous change back to the original format:
 
 http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/
 
 Thanks,
 Joe
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering
 1 Network Drive
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Review Request for java.time test fix 8024612

[Lance Andersen - Oracle]

+1
On Oct 9, 2013, at 10:36 AM, roger riggs wrote:

 Please Review a locale sensitive test correction:
 
 The API under test is based on Locale.getDefault(Locale.Category.FORMAT)
 and the test data should be using the same Locale.
 The failure was seen in locale: ar_EG with Locale.Category.FORMAT=ar_SA
 
 webrev:
 http://cr.openjdk.java.net/~rriggs/webrev-test-formatters-locale-8024612/
 
 Thanks, Roger
 
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: improved exception messages in java.time 8025718

[Lance Andersen - Oracle]

+1
On Oct 9, 2013, at 10:38 AM, roger riggs wrote:

 Ping... any Reviewer...
 
 Thanks
 
 On 10/4/2013 3:37 PM, roger riggs wrote:
 Hi,
 
 Please review these small improvements in messages resulting from
 parsing date and time errors and corresponding tests.
 
 Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-better-msg-8025718/
 
 JBS:
   https://bugs.openjdk.java.net/browse/JDK-8025718
 
 Thanks, Roger
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (JAXP) : 8003262 reverse translation required changes

[Lance Andersen - Oracle]

+1
On Oct 9, 2013, at 1:35 PM, huizhe wang wrote:

 Hi,
 
 These resource bundles in JAXP were refactored due to request by WPTG. Now 
 that the WPTG tool has been approved to support the original format, I'm 
 reverting the previous change back to the original format:
 
 http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/
 
 Thanks,
 Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Fwd: review request 7097386: Correct error in Predicate javadoc example --- Still need an approval from a reviewer

[Lance Andersen - Oracle]

Hi Folks,

Aleksey has been kind enough to review this change.  Still need the blessing of 
a reviewer to put this back...

any takers :-)

Best
Lance

Begin forwarded message:

 From: Lance Andersen - Oracle lance.ander...@oracle.com
 Date: September 16, 2013 7:12:09 AM EDT
 To: Aleksey Shipilev aleksey.shipi...@oracle.com
 Cc: core-libs-dev Core-Libs-Dev core-libs-dev@openjdk.java.net
 Subject: Re: review request 7097386: Correct error in Predicate javadoc 
 example
 
 Thanks for the input.
 On Sep 16, 2013, at 4:58 AM, Aleksey Shipilev wrote:
 
 On 09/15/2013 10:38 PM, Lance Andersen - Oracle wrote:
 I added a webrev
 http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be
 a bit easier for this review.
 
 Notes:
 - change C-style int v[] declarations to Java-ish int[] v.
 
 I changed this.
 - catching SQLException should probably return false right away?
 True, was a missing cut and paste from the code I copied
 - if block can float up to the exception handler block, eliminating
 the need for int value = 0 line.
 
 I left it as is as I try to keep the try/catch for SQLExceptions to just 
 relevant code when applicable.
 
 Otherwise, looks good (not a Reviewer).
 
 again, thank you for the feedback.
 
 Changes are at http://cr.openjdk.java.net/~lancea/7097386/webrev.01/
 
 Best
 Lance
 Thanks,
 -Aleksey,
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering 
 1 Network Drive 
 Burlington, MA 01803
 lance.ander...@oracle.com
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request 7097386: Correct error in Predicate javadoc example --- Still need an approval from a reviewer

[Lance Andersen - Oracle]

On Sep 17, 2013, at 7:14 AM, Alan Bateman wrote:

 On 17/09/2013 11:55, Lance Andersen - Oracle wrote:
 Hi Folks,
 
 Aleksey has been kind enough to review this change.  Still need the blessing 
 of a reviewer to put this back...
 
 any takers :-)
 It looks okay although if is this is sample code that we expect developers to 
 copy then we could do more, like taking a defensive copy of the array. If 
 that is going further than you originally expected then you can ignore this 
 suggestion.

No, the intent was just to be a trivial example not to deep dive into things 
such as defensive copying of the array.

The previous code from the original authors was not even functional :-(
 
 -Alan.
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request 7097386: Correct error in Predicate javadoc example

[Lance Andersen - Oracle]

Thanks for the input.
On Sep 16, 2013, at 4:58 AM, Aleksey Shipilev wrote:

 On 09/15/2013 10:38 PM, Lance Andersen - Oracle wrote:
 I added a webrev
 http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be
 a bit easier for this review.
 
 Notes:
  - change C-style int v[] declarations to Java-ish int[] v.

I changed this.
  - catching SQLException should probably return false right away?
True, was a missing cut and paste from the code I copied
  - if block can float up to the exception handler block, eliminating
 the need for int value = 0 line.

I left it as is as I try to keep the try/catch for SQLExceptions to just 
relevant code when applicable.
 
 Otherwise, looks good (not a Reviewer).
 
again, thank you for the feedback.

Changes are at http://cr.openjdk.java.net/~lancea/7097386/webrev.01/

Best
Lance
 Thanks,
 -Aleksey,


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request 7097386: Correct error in Predicate javadoc example

[Lance Andersen - Oracle]

I added a webrev http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it 
might be a bit easier for this review.

Best
lance
On Sep 13, 2013, at 4:40 PM, Lance Andersen - Oracle wrote:

 Hi Everyone,
 
 Looking for a reviewer for this trivial fix to correct the sample example in 
 the Predicate javadoc for the evaluate method()
 
 
 --
 !hg
 hg diff Predicate.java 
 diff -r 60d6f60416ca src/share/classes/javax/sql/rowset/Predicate.java
 --- a/src/share/classes/javax/sql/rowset/Predicate.java   Thu Sep 12 
 13:20:26 2013 -0400
 +++ b/src/share/classes/javax/sql/rowset/Predicate.java   Fri Sep 13 
 16:30:07 2013 -0400
 @@ -56,44 +56,42 @@
  * pre{@code
  *public class Range implements Predicate {
  *
 - *   private Object lo[];
 - *   private Object hi[];
 + *   private int lo[];
 + *   private int hi[];
  *   private int idx[];
  *
 - *   public Range(Object[] lo, Object[] hi, int[] idx) {
 + *   public Range(int[] lo, int[] hi, int[] idx) {
  *  this.lo = lo;
  *  this.hi = hi;
  *  this.idx = idx;
  *   }
  *
  *  public boolean evaluate(RowSet rs) {
 - *  CachedRowSet crs = (CachedRowSet)rs;
 - *  boolean bool1,bool2;
  *
  *  // Check the present row determine if it lies
  *  // within the filtering criteria.
  *
  *  for (int i = 0; i  idx.length; i++) {
 + * int value = 0;
 + * try {
 + * value = (Integer) rs.getObject(idx[i]);
 + * } catch (SQLException ex) {
 + * Logger.getLogger(Range.class.getName()).log(Level.SEVERE, 
 null, ex);
 + * }
  *
 - *  if ((rs.getObject(idx[i]) = lo[i]) 
 - *  (rs.getObject(idx[i]) = hi[i]) {
 - *  bool1 = true; // within filter constraints
 - *  } else {
 - *  bool2 = true; // outside of filter constraints
 - *  }
 - *  }
 - *
 - *  if (bool2) {
 - * return false;
 - *  } else {
 - * return true;
 - *  }
 + * if (value  lo[i]  value  hi[i]) {
 + * // outside of filter constraints
 + * return false; 
 + * }
 + * }
 + * // Within filter constraints
 + *return true;
  *  }
 - *  }
 + *   }
  * }/pre
  * P
  * The example above implements a simple range predicate. Note, that
 - * implementations should but are not required to provider 
 codeString/code
 + * implementations should but are not required to provide codeString/code
  * and integer index based constructors to provide for JDBC RowSet 
 Implementation
  * applications that use both column identification conventions.
  *
 
 
 -
 
 Best
 Lance
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering 
 1 Network Drive 
 Burlington, MA 01803
 lance.ander...@oracle.com
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

review request 7097386: Correct error in Predicate javadoc example

[Lance Andersen - Oracle]

Hi Everyone,

Looking for a reviewer for this trivial fix to correct the sample example in 
the Predicate javadoc for the evaluate method()


--
!hg
hg diff Predicate.java 
diff -r 60d6f60416ca src/share/classes/javax/sql/rowset/Predicate.java
--- a/src/share/classes/javax/sql/rowset/Predicate.java Thu Sep 12 13:20:26 
2013 -0400
+++ b/src/share/classes/javax/sql/rowset/Predicate.java Fri Sep 13 16:30:07 
2013 -0400
@@ -56,44 +56,42 @@
  * pre{@code
  *public class Range implements Predicate {
  *
- *   private Object lo[];
- *   private Object hi[];
+ *   private int lo[];
+ *   private int hi[];
  *   private int idx[];
  *
- *   public Range(Object[] lo, Object[] hi, int[] idx) {
+ *   public Range(int[] lo, int[] hi, int[] idx) {
  *  this.lo = lo;
  *  this.hi = hi;
  *  this.idx = idx;
  *   }
  *
  *  public boolean evaluate(RowSet rs) {
- *  CachedRowSet crs = (CachedRowSet)rs;
- *  boolean bool1,bool2;
  *
  *  // Check the present row determine if it lies
  *  // within the filtering criteria.
  *
  *  for (int i = 0; i  idx.length; i++) {
+ * int value = 0;
+ * try {
+ * value = (Integer) rs.getObject(idx[i]);
+ * } catch (SQLException ex) {
+ * Logger.getLogger(Range.class.getName()).log(Level.SEVERE, 
null, ex);
+ * }
  *
- *  if ((rs.getObject(idx[i]) = lo[i]) 
- *  (rs.getObject(idx[i]) = hi[i]) {
- *  bool1 = true; // within filter constraints
- *  } else {
- *  bool2 = true; // outside of filter constraints
- *  }
- *  }
- *
- *  if (bool2) {
- * return false;
- *  } else {
- * return true;
- *  }
+ * if (value  lo[i]  value  hi[i]) {
+ * // outside of filter constraints
+ * return false; 
+ * }
+ * }
+ * // Within filter constraints
+ *return true;
  *  }
- *  }
+ *   }
  * }/pre
  * P
  * The example above implements a simple range predicate. Note, that
- * implementations should but are not required to provider codeString/code
+ * implementations should but are not required to provide codeString/code
  * and integer index based constructors to provide for JDBC RowSet 
Implementation
  * applications that use both column identification conventions.
  *


-

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Review request for 8014967: Clarify NPE thrown by DriverManager.registerDriver when driver is null

[Lance Andersen - Oracle]

Looking for a reviewer for this trivial change to clarify the long outstanding 
behavior of registererDriver:


$ hg diff DriverManager.java 
diff -r 262a625809fd src/share/classes/java/sql/DriverManager.java
--- a/src/share/classes/java/sql/DriverManager.java Thu Sep 12 01:47:05 
2013 -0700
+++ b/src/share/classes/java/sql/DriverManager.java Thu Sep 12 10:35:48 
2013 -0400
@@ -326,6 +326,7 @@
  * @param driver the new JDBC Driver that is to be registered with the
  *   {@code DriverManager}
  * @exception SQLException if a database access error occurs
+ * @exception NullPointerException if {@code driver} is null
  */
 public static synchronized void registerDriver(java.sql.Driver driver)
 throws SQLException {
@@ -345,6 +346,7 @@
  * @param da the {@code DriverAction} implementation to be used when
  *   {@code DriverManager#deregisterDriver} is called
  * @exception SQLException if a database access error occurs
+ * @exception NullPointerException if {@code driver} is null
  */
 public static synchronized void registerDriver(java.sql.Driver driver,
 DriverAction da)


registerDriver has thrown this NPE since the early days of DriverManager (1997) 
so it was requested that we clarify this.

Alan,  could you please confirm whether I need a CCC given this behavior has 
been there since JDBC 1.0 and this just adds the @exception and there is no 
behavior change.

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

review request: 8015340: remove erroneous @since tag

[Lance Andersen - Oracle]

Looking for a reviewer for this trivial fix:


 hg diff PreparedStatement.java 
diff -r 262a625809fd src/share/classes/java/sql/PreparedStatement.java
--- a/src/share/classes/java/sql/PreparedStatement.java Thu Sep 12 01:47:05 
2013 -0700
+++ b/src/share/classes/java/sql/PreparedStatement.java Thu Sep 12 11:18:13 
2013 -0400
@@ -954,7 +954,6 @@
  * the JDBC driver does not support this data type
  * @see Types
  *
- * @since 1.6
  */
 void setObject(int parameterIndex, Object x, int targetSqlType, int 
scaleOrLength)
 throws SQLException;



This method dates back to JDBC 1.0.  Looks like when the javadocs were updated 
for JDBC 4.0, the IEC team accidentally added the @since 1.6. 

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle

[Lance Andersen - Oracle]

Looking at the jdk7 source and comparing your change this looks OK.   Would be 
good to get one more pair of eyes on this as well but I think you should be 
good to go

Best
Lance
On Aug 23, 2013, at 10:41 AM, Daniel Fuchs wrote:

 Hi,
 
 Please find below a fix for:
 
 8005899: Logger.getLogger(name, null) should not allow to reset
 a non-null resource bundle
 
 The issue here is that whereas in JDK 7,
Logger.getLogger(foo, null);
 will throw an IllegalArgumentException if foo has a non null
 bundle name, JDK 8 will simply ignore the 'null' parameter and
 behave as
Logger.getLogger(foo);
 
 The fix below restores the IllegalArgumentException in JDK 8.
 
 http://cr.openjdk.java.net/~dfuchs/webrev_8005899/webrev.00/
 
 best regards,
 
 -- daniel


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle

[Lance Andersen - Oracle]

looks fine dan!

On Aug 23, 2013, at 1:26 PM, Daniel Fuchs wrote:

 On 8/23/13 5:50 PM, Mandy Chung wrote:
 Hi Daniel,
 
 The fix looks good.   It might be good to clarify the spec in the case
 when the given resourceBundleName parameter is null?   Perhaps in the
 @params resourceBundleName of the getLogger(String, String) method.
 
* @param   resourceBundleName  name of ResourceBundle to be used for
 localizing
*  messages for this logger. May be
 CODEnull/CODE if none of
*  the messages require localization.
 
 perhaps clarify that null only if the logger does not have a
 localization resource bundle set.
 
 Thanks Lance and Mandy!
 
 I have updated the webrev as per your suggestion:
 
 http://cr.openjdk.java.net/~dfuchs/webrev_8005899/webrev.01/
 
 -- daniel
 
 thanks
 Mandy
 
 On 8/23/2013 7:41 AM, Daniel Fuchs wrote:
 Hi,
 
 Please find below a fix for:
 
 8005899: Logger.getLogger(name, null) should not allow to reset
 a non-null resource bundle
 
 The issue here is that whereas in JDK 7,
Logger.getLogger(foo, null);
 will throw an IllegalArgumentException if foo has a non null
 bundle name, JDK 8 will simply ignore the 'null' parameter and
 behave as
Logger.getLogger(foo);
 
 The fix below restores the IllegalArgumentException in JDK 8.
 
 http://cr.openjdk.java.net/~dfuchs/webrev_8005899/webrev.00/
 
 best regards,
 
 -- daniel
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: 8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile

[Lance Andersen - Oracle]

I think this look OK Alan

Best
Lance
On Aug 20, 2013, at 8:13 AM, Alan Bateman wrote:

 
 For some time now we have been chipping away at the make files that are used 
 to run the jdk tests. Mike has his wielded his axe on several occasions 
 recently to remove logic and rules that are no longer needed. One of the next 
 steps needs to be to remove the definitions of the test targets from the make 
 file as it can't currently be shared between the Makefile and direct jtreg 
 usage.
 
 To that end, I'd like to push a TEST.groups file to define the corresponding 
 jtreg groups. For the most part the proposal is to start up with a mostly 1-1 
 mapping for the existing test targets. In addition to groups for the normal 
 test target then I also propose to add higher level groups that partition the 
 entire test suite into three groups named core, svc and desktop. This 
 makes it really easy to run selections of the test suite, for example jtreg 
 options :core :svc will run all the core area and serviceability tests.
 
 One other thing to mention is that David Holmes will arrive soon with 
 additional groups to add selection of tests that are appropriate for the 
 compact Profiles, maybe JRE vs. JDK too.
 
 The webrev with the proposed changes is here, it's very simple:
 
 http://cr.openjdk.java.net/~alanb/8023351/webrev/
 
 A few things to note (as there are a few small changes from the normal test 
 targets):
 
 1. I've moved the management and java.lang.instrument tests out of the 
 jdk_lang group. Once the make file targets are updated then these can be 
 re-included if needed but logically they should be separated.
 
 2. I have not moved the JSR-292 tests or stream tests, they remain in 
 jdk_lang and jdk_util for now. They can easily be changed if there is good 
 reason.
 
 3. I've kept security1, security2 and security3 for now but these are 
 unbalanced in execution time and ideally should all be in one group. Once we 
 get to the point that concurrency is dialed up by default then that might be 
 the right time to do that.
 
 4. To my knowledge, the client teams do not use the make files and I don't 
 know anyone that used the jdk_awt, etc. make targets. For now, I've just 
 re-worked those targets (eliminating the beans1, beans2, beans3 that have not 
 been needed since we moved the execution mode out of the make file). I'm sure 
 someone in the AWT or 2D area could come up with cleaner definitions but as 
 they aren't used then it shouldn't matter for now.
 
 -Alan
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Reviewer needed for 8022753: SQLXML example typo in the SQLXML javadoc

[Lance Andersen - Oracle]

Hi all,

Need a reviewer for the following trivial javadoc typo.  Bug is 8022753

Best
Lance


hg diff SQLXML.java 
diff -r a4eb59bffb60 src/share/classes/java/sql/SQLXML.java
--- a/src/share/classes/java/sql/SQLXML.javaSat Jun 29 06:12:28 2013 -0400
+++ b/src/share/classes/java/sql/SQLXML.javaMon Aug 12 13:59:31 2013 -0400
@@ -98,7 +98,7 @@
  * or, to set the result value from SAX events:
  * pre
  *   SAXResult saxResult = sqlxml.setResult(SAXResult.class);
- *   ContentHandler contentHandler = 
saxResult.getXMLReader().getContentHandler();
+ *   ContentHandler contentHandler = saxResult.getHandler();
  *   contentHandler.startDocument();
  *   // set the XML elements and attributes into the result
  *   contentHandler.endDocument();


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34

[Lance Andersen - Oracle]

Hi Joe,

The changes look fine

Best
Lance
On Aug 9, 2013, at 1:57 AM, huizhe wang wrote:

 Hi,
 
 The root cause of this issue is that SPECJVM2008 uses a 3rd party parser XOM 
 1.1 to convert the output to its canonical form. The XOM parser directly 
 references to the JDK parser implementation SAXParser with a different 
 configuration than the default JDK parser, in this case, the DTD-only parser 
 configuration DTDConfiguration.  In JAXP 1.5, we added 
 XMLSecurityPropertyManager that is instantiated in the default configuration 
 XML11Configuration.  Since XMLSecurityPropertyManager is not supported by 
 DTDConfiguration, XOM no longer works.
 
 This patch is to add the XMLSecurityPropertyManager to DTDConfiguration so 
 that XOM will continue to work properly with jdk8/7u40. I don't know if 
 there's any library out there that calls into NonValidatingConfiguration 
 directly.  Since it's in a similar situation as DTDConfiguration, I added  
 XMLSecurityPropertyManager support as well.
 
 webrec: http://cr.openjdk.java.net/~joehw/jdk8/8022548/webrev/
 
 test:
   I created a new test that runs with xom1.1.jar on the classpath, and 
 passed.
   all unit tests/SQE regression tests passed
 
 Thanks,
 Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR lint warnings in j.u.concurrent.**

[Lance Andersen - Oracle]

looks fine chris

Best
Lance
On Aug 9, 2013, at 11:03 AM, Chris Hegarty wrote:

 These changes address the remaining lint warnings in the j.u.concurrent.** 
 package(s).
 
 The changes are already in the JSR166 CVS, this is a request to bring them 
 into jdk8.
 
 diff -r 84004d0e3fdd 
 src/share/classes/java/util/concurrent/CompletableFuture.java
 --- a/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 
 09 13:50:13 2013 +0100
 +++ b/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 
 09 15:58:41 2013 +0100
 @@ -420,6 +420,7 @@ public class CompletableFutureT implem
 }
 
 /** Base class can act as either FJ or plain Runnable */
 +@SuppressWarnings(serial)
 abstract static class Async extends ForkJoinTaskVoid
 implements Runnable, AsynchronousCompletionTask {
 public final Void getRawResult() { return null; }
 @@ -671,6 +672,7 @@ public class CompletableFutureT implem
 }
 
 // Opportunistically subclass AtomicInteger to use compareAndSet to claim.
 +@SuppressWarnings(serial)
 abstract static class Completion extends AtomicInteger implements 
 Runnable {
 }
 
 diff -r 84004d0e3fdd 
 src/share/classes/java/util/concurrent/ConcurrentHashMap.java
 --- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 
 09 13:50:13 2013 +0100
 +++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 
 09 15:58:41 2013 +0100
 @@ -4716,6 +4716,7 @@ public class ConcurrentHashMapK,V exte
  * Base class for bulk tasks. Repeats some fields and code from
  * class Traverser, because we need to subclass CountedCompleter.
  */
 +@SuppressWarnings(serial)
 abstract static class BulkTaskK,V,R extends CountedCompleterR {
 NodeK,V[] tab;// same as Traverser
 NodeK,V next;
 diff -r 84004d0e3fdd 
 src/share/classes/java/util/concurrent/atomic/Striped64.java
 --- a/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 
 13:50:13 2013 +0100
 +++ b/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 
 15:58:41 2013 +0100
 @@ -43,6 +43,7 @@ import java.util.concurrent.ThreadLocalR
  * for classes supporting dynamic striping on 64bit values. The class
  * extends Number so that concrete subclasses must publicly do so.
  */
 +@SuppressWarnings(serial)
 abstract class Striped64 extends Number {
 /*
  * This class maintains a lazily-initialized table of atomically
 
 
 -Chris.


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JDK-8021977 -- Open File Using Java.IO May Throw IOException On Windows

[Lance Andersen - Oracle]

Looks OK Dan

Best
Lance
On Aug 8, 2013, at 7:26 PM, Dan Xu wrote:

 Hi All,
 
 Please review a simple bug fix for JDK8021977. For the backward 
 compatibility, I have to remove the code that might throw out IOExceptionin 
 the native side. The issue has never been reported.But it exists in a 
 possible code path. And it is not easy to write a testcase for this obvious 
 but corner issue. I am relying on the existing IO testcases for testing. 
 Thanks!
 
 Webrev: http://cr.openjdk.java.net/~dxu/8021977/webrev.00/
 Bug: http://bugs.sun.com/view_bug.do?bug_id=8021977
 
 -Dan
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8022479: clean up warnings from sun.tools.asm

[Lance Andersen - Oracle]

Hi Stuart,

On the surface the changes look fine, including what you did for SwitchData.

Certainly another pair of eyes would be good also on this.

Best
Lance
On Aug 7, 2013, at 2:28 AM, Stuart Marks wrote:

 Hi,
 
 Please review the fix for this warnings cleanup bug.
 
 Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022479
(not yet available publicly, but should be shortly)
 
 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8022479/webrev.0/
 
 There are a few items of note.
 
 This is *very* old code. You can see some of the authors' names in the code. 
 It's replete with uses of Vector, Hashtable, and Enumeration. It also has a 
 kind of musty style, which might have been reasonable from the standpoint of 
 C programmers (which we all were at the time!). For example, there are a 
 bunch of cases of direct field access to another class. There are also cases 
 where a class contains a Vector that's returned by a getter method. I guess 
 we just have to trust the caller not to modify it at the wrong time.
 
 I've confined most of my cleanups to the addition of generics (which gets rid 
 of the rawtypes and unchecked warnings). There were a smattering of other 
 warnings I've cleaned up as well. I've also replaced few cases of calls to 
 new on boxed types like Integer and Long with calls to the respective 
 valueOf() methods. I didn't check all the code for this, though, just 
 instances I happened to run across.
 
 There is much more cleanup that could be done that I've elected not to do, 
 such as replacing Vector, Hashtable, and Enumeration with ArrayList, HashMap, 
 and Iterator, and using the enhanced-for loop. These changes would *probably* 
 be safe, but they would require more analysis and testing than I'm willing to 
 do at the moment.
 
 Two locations deserve a bit of scrutiny.
 
 1) There are four occurrences in Assembler.java of calls to 
 MemberDefinition.getArguments(). Unfortunately MemberDefinition resides in 
 the sun.tools.java package and getArguments() returns a raw Vector. This is 
 also overridden in a couple places spread across a couple sun.tools packages, 
 and there are hints that it being a LocalMember or MemberDefinition. It seems 
 out of scope to try to fix up the return value of getArguments() and its 
 various overrides.
 
 Locally in the Assembler.java file, though, the contents of the returned 
 vector are always cast to MemberDefinition, so it seems sensible to make an 
 unchecked cast of the getArguments() return value to VectorMemberDefinition 
 and to suppress warnings at that point. Usage beyond those points within 
 Assembler.java is filled with sweet and juicy generic goodness.
 
 2) SwitchData.java contains a field whereCaseTab which is a 
 HashtableInteger,Long ... most of the time. In the addTableDefault() 
 method, a value is put into the Hashtable under the key default -- a 
 String. Ick.
 
 To deal with this I declared it as HashtableInteger,Long since that's the 
 typical case, and for the put(String, Long) case I cast through raw and 
 suppressed the warning. The get() method already takes an Object so we're OK 
 there. Note that default as a key for this Hashtable is used in a couple 
 other places in Assembler.java. It's not intractable to change these to some 
 other sentinel value, but, you know, where does one stop?
 
 (I said Ick when encountering a mix-type collection, and in a generified 
 world we very rarely see this style anymore. Upon further reflection, though, 
 from the standpoint of a pre-generics world, this is pretty sensible. Using a 
 string as a sentinel key is guaranteed not to collide with any Integer keys. 
 Sometimes it's possible to use -1 or Integer.MAX_VALUE as a sentinel, but if 
 any integer value is permitted as a key, what does one do then?)
 
 With this changeset, sun.tools.asm is reduced from about 76 to zero warnings.
 
 Thanks,
 
 s'marks


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package

[Lance Andersen - Oracle]

looks fine Dan
On Aug 7, 2013, at 1:49 PM, Dan Xu wrote:

 Hi All,
 
 Please review the simple warning fix in 
 src/share/classes/sun/invoke/anon/ConstantPoolPatch.java.
 
 webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/
 
 Thanks,
 
 -Dan


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR doclint issues in java.net

[Lance Andersen - Oracle]

Good to go
On Jul 25, 2013, at 6:00 AM, Chris Hegarty wrote:

 This is a request for review for some doclint warnings in the java.net 
 package. Trivially, the list type should be left to the CSS.
 
 Note: with these changes there are still warnings for two DatagramPacket 
 constructors that are missing @throws for SocketException. I do not see any 
 reason that these constructors need to throw SE, and I will file a separate 
 bug to follow up.
 
 diff -r fd1b5adcfdf0 src/share/classes/java/net/URI.java
 --- a/src/share/classes/java/net/URI.java   Wed Jul 24 22:52:01 2013 +0100
 +++ b/src/share/classes/java/net/URI.java   Thu Jul 25 10:56:25 2013 +0100
 @@ -530,7 +530,7 @@ public final class URI
  * href=http://www.ietf.org/rfc/rfc2396.txt;RFCnbsp;2396/a,
  * Appendixnbsp;A, biexcept for the following deviations:/i/b 
 /p
  *
 - * ul type=disc
 + * ul
  *
  *   lip An empty authority component is permitted as long as it is
  *   followed by a non-empty path, a query component, or a fragment
 @@ -993,7 +993,7 @@ public final class URI
  *   lip Otherwise the new URI's authority component is copied from
  *   this URI, and its path is computed as follows: /p
  *
 - *   ol type=a
 + *   ol
  *
  * lip If the given URI's path is absolute then the new URI's path
  * is taken from the given URI. /p/li
 @@ -1241,7 +1241,7 @@ public final class URI
  * p The host component of a URI, if defined, will have one of the
  * following forms: /p
  *
 - * ul type=disc
 + * ul
  *
  *   lip A domain name consisting of one or more ilabels/i
  *   separated by period characters (tt'.'/tt), optionally followed by
 @@ -1495,7 +1495,7 @@ public final class URI
  *
  * p The ordering of URIs is defined as follows: /p
  *
 - * ul type=disc
 + * ul
  *
  *   lip Two URIs with different schemes are ordered according the
  *   ordering of their schemes, without regard to case. /p/li
 @@ -1513,7 +1513,7 @@ public final class URI
  *   lip Two hierarchical URIs with identical schemes are ordered
  *   according to the ordering of their authority components: /p
  *
 - *   ul type=disc
 + *   ul
  *
  * lip If both authority components are server-based then the URIs
  * are ordered according to their user-information components; if 
 these
 
 
 -Chris.


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JAXP in JDK8/7u40 : 8021148 Regression in SAXParserImpl in 7u40 b34 (NPE)

[Lance Andersen - Oracle]

looks fine Joe
On Jul 25, 2013, at 2:30 AM, huizhe wang wrote:

 I received test from the NetBeans team. The NetBeans did reference the 
 internal JAXPSAXParser directly. This is not a usage supported by the spec. I 
 would suggest them remove it and use the default parser instead. I'm asking 
 the NetBeans team what are the features they rely on that the default parser 
 couldn't provide. In the meantime, we're making this fix so that existing 
 NetBeans continue to work properly when 7u40 is used.
 
 Here's an updated webrev (test included):
 http://cr.openjdk.java.net/~joehw/7u40/8021148/webrev/
 
 Thanks,
 Joe
 
 On 7/24/2013 3:41 AM, Lance Andersen - Oracle wrote:
 Agree with the change and making fSecurityPropertyMgr final
 
 Best
 Lance
 On Jul 24, 2013, at 5:04 AM, chris Hegarty wrote:
 
 Joe,
 
 I can see in SAXParserImpl constructor, setFeature0 could throw, leaving 
 the fSecurityPropertyMgr uninitialized. There my be other code paths too.
 
 I agree with this change, and Daniel's comments to make both 
 fSecurityPropertyMgr fields final. Consider it reviewed ( at least on my 
 side ).
 
 -Chris.
 
 On 24/07/2013 07:59, huizhe wang wrote:
 On 7/23/2013 11:00 PM, Daniel Fuchs wrote:
 Hi Joe,
 
 This looks reasonable.
 Out of curiosity - could it be that it was fSAXParser that was null,
 and not fSecurityPropertyMgr?
 JAXPSAXParser has a no arg public constructor that could have lead to
 that...
 That was my suspicion as well. I thought NetBeans was referencing the
 internal class directly since the new JAXPSAXParser(this) inside
 SAXParserImpl was the only call in the entire jaxp code. I was therefore
 thinking it really should have been a private class. Of course, once
 NetBeans bugzilla became accessible (it was down at the time), I was
 able to get the error stacktrace.
 
 There is still something strange since XMLReaderManager.getXMLReader
 calls XMLReaderFactory which should have returned SAXParser since it's
 hardcoded default. In a manual test, I could only get a JAXPSAXParser if
 I intentionally set org.xml.sax.driver to a bogus parser. I'm asking
 the NetBeans reporter and haven't heard from him yet.
 
 I have only one remark:
 
 It looks as if fSecurityPropertyMgr could be declared final in both
 classes - and I think it
 would be better if it were: it would make it clear that it's never
 replaced in fSAXParser
 and that therefore your new code is strictly equivalent to the old in
 that respect.
 Make sense.
 
 Thanks,
 Joe
 
 best regards,
 
 -- daniel
 
 On 7/24/13 4:01 AM, huizhe wang wrote:
 Hi Lance, Chris,
 
 Looking at the affected class [1], and the error stack trace [2] , it
 appeared that in SAXParserImpl$JAXPSAXParser , line 545,
 fSAXParser.fSecurityPropertyMgr is null when setProperty is called.
 fSecurityPropertyMgr was instantiated in SAXParserImpl's constructor
 after JAXPSAXParser was. I can see a chance where the NetBeans got a
 copy of JAXPSAXParser instance with fSecurityPropertyMgr not
 initialized. The fix is to remove the reference of
 fSecurityPropertyMgr in JAXPSAXParser, and pass it in when
 JAXPSAXParser is created.
 
 Here is the webrev:
 http://cr.openjdk.java.net/~joehw/7u40/8021148/webrev/
 
 [1]
 http://cr.openjdk.java.net/~joehw/7u40/8021148/webrev/src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java.html
 
 [2]
 
 Caused by: java.lang.NullPointerException
 at
 com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.access$300(SAXParserImpl.java:69)
 
 at
 com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.setProperty(SAXParserImpl.java:545)
 
 at
 com.sun.org.apache.xml.internal.utils.XMLReaderManager.getXMLReader(XMLReaderManager.java:161)
 
 at
 com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault.getXMLReader(DTMManagerDefault.java:613)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:401)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:252)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.java:559)
 
 ... 43 more
 -
 javax.xml.transform.TransformerException: java.lang.NullPointerException
 at
 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.java:581)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:742)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:353)
 
 at
 org.netbeans.spi.project.support.ant.GeneratedFilesHelper$1$1.run(GeneratedFilesHelper.java:332)
 
 
 Thanks,
 Joe
 
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering 
 1 Network Drive 
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR JDK 8 javac lint cleanup of java.lang.ref

[Lance Andersen - Oracle]

Looks fine joe
On Jul 25, 2013, at 4:33 PM, Joe Darcy wrote:

 Hello,
 
 Please review these changes to remove the javac lint warnings from the 
 java.lang.ref package:
 
8021429 Fix lint warnings in java.lang.ref
http://cr.openjdk.java.net/~darcy/8021429.0/
 
 Care was taken to not change any signatures of public API elements. After 
 doing a clean build, all the java.lang.ref regression tests pass. Full patch 
 below.
 
 Thanks,
 
 -Joe
 
 --- old/src/share/classes/java/lang/ref/FinalReference.java 2013-07-25 
 13:29:12.0 -0700
 +++ new/src/share/classes/java/lang/ref/FinalReference.java 2013-07-25 
 13:29:12.0 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1997, 2003, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -25,13 +25,12 @@
 
 package java.lang.ref;
 
 -
 -/* Final references, used to implement finalization */
 -
 +/**
 + * Final references, used to implement finalization
 + */
 class FinalReferenceT extends ReferenceT {
 
 public FinalReference(T referent, ReferenceQueue? super T q) {
 super(referent, q);
 }
 -
 }
 --- old/src/share/classes/java/lang/ref/Finalizer.java2013-07-25 
 13:29:13.0 -0700
 +++ new/src/share/classes/java/lang/ref/Finalizer.java2013-07-25 
 13:29:13.0 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1997, 2008, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -29,16 +29,16 @@
 import java.security.AccessController;
 
 
 -final class Finalizer extends FinalReference { /* Package-private; must be in
 -  same package as the 
 Reference
 -  class */
 +final class Finalizer extends FinalReferenceObject { /* Package-private; 
 must be in
 +same package as the 
 Reference
 +class */
 
 /* A native method that invokes an arbitrary object's finalize method is
required since the finalize method is protected
  */
 static native void invokeFinalizeMethod(Object o) throws Throwable;
 
 -private static ReferenceQueue queue = new ReferenceQueue();
 +private static ReferenceQueueObject queue = new ReferenceQueue();
 private static Finalizer unfinalized = null;
 private static final Object lock = new Object();
 
 --- old/src/share/classes/java/lang/ref/Reference.java2013-07-25 
 13:29:14.0 -0700
 +++ new/src/share/classes/java/lang/ref/Reference.java2013-07-25 
 13:29:13.0 -0700
 @@ -96,6 +96,7 @@
  *Enqueued:   next reference in queue (or this if last)
  *Inactive:   this
  */
 +@SuppressWarnings(rawtypes)
 Reference next;
 
 /* When active:   next element in a discovered reference list maintained 
 by GC (or this if last)
 @@ -119,7 +120,7 @@
  * them.  This list is protected by the above lock object. The
  * list uses the discovered field to link its elements.
  */
 -private static Reference pending = null;
 +private static ReferenceObject pending = null;
 
 /* High-priority thread to enqueue pending References
  */
 @@ -131,7 +132,7 @@
 
 public void run() {
 for (;;) {
 -Reference r;
 +ReferenceObject r;
 synchronized (lock) {
 if (pending != null) {
 r = pending;
 @@ -166,7 +167,7 @@
 continue;
 }
 
 -ReferenceQueue q = r.queue;
 +ReferenceQueueObject q = r.queue;
 if (q != ReferenceQueue.NULL) q.enqueue(r);
 }
 }
 --- old/src/share/classes/java/lang/ref/ReferenceQueue.java 2013-07-25 
 13:29:14.0 -0700
 +++ new/src/share/classes/java/lang/ref/ReferenceQueue.java 2013-07-25 
 13:29:14.0 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1997, 2005, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -40,14 +40,14 @@
  */
 public ReferenceQueue() { }
 
 -private static class Null extends ReferenceQueue {
 -boolean enqueue(Reference r) {
 +private static class NullS extends ReferenceQueueS {
 +boolean enqueue(Reference? extends S r) {
 return 

Re: RFR: JAXP in JDK8/7u40 : 8021148 Regression in SAXParserImpl in 7u40 b34 (NPE)

[Lance Andersen - Oracle]

Agree with the change and making fSecurityPropertyMgr final

Best
Lance
On Jul 24, 2013, at 5:04 AM, chris Hegarty wrote:

 Joe,
 
 I can see in SAXParserImpl constructor, setFeature0 could throw, leaving the 
 fSecurityPropertyMgr uninitialized. There my be other code paths too.
 
 I agree with this change, and Daniel's comments to make both 
 fSecurityPropertyMgr fields final. Consider it reviewed ( at least on my side 
 ).
 
 -Chris.
 
 On 24/07/2013 07:59, huizhe wang wrote:
 
 On 7/23/2013 11:00 PM, Daniel Fuchs wrote:
 Hi Joe,
 
 This looks reasonable.
 Out of curiosity - could it be that it was fSAXParser that was null,
 and not fSecurityPropertyMgr?
 JAXPSAXParser has a no arg public constructor that could have lead to
 that...
 
 That was my suspicion as well. I thought NetBeans was referencing the
 internal class directly since the new JAXPSAXParser(this) inside
 SAXParserImpl was the only call in the entire jaxp code. I was therefore
 thinking it really should have been a private class. Of course, once
 NetBeans bugzilla became accessible (it was down at the time), I was
 able to get the error stacktrace.
 
 There is still something strange since XMLReaderManager.getXMLReader
 calls XMLReaderFactory which should have returned SAXParser since it's
 hardcoded default. In a manual test, I could only get a JAXPSAXParser if
 I intentionally set org.xml.sax.driver to a bogus parser. I'm asking
 the NetBeans reporter and haven't heard from him yet.
 
 
 I have only one remark:
 
 It looks as if fSecurityPropertyMgr could be declared final in both
 classes - and I think it
 would be better if it were: it would make it clear that it's never
 replaced in fSAXParser
 and that therefore your new code is strictly equivalent to the old in
 that respect.
 
 Make sense.
 
 Thanks,
 Joe
 
 
 best regards,
 
 -- daniel
 
 On 7/24/13 4:01 AM, huizhe wang wrote:
 Hi Lance, Chris,
 
 Looking at the affected class [1], and the error stack trace [2] , it
 appeared that in SAXParserImpl$JAXPSAXParser , line 545,
 fSAXParser.fSecurityPropertyMgr is null when setProperty is called.
 fSecurityPropertyMgr was instantiated in SAXParserImpl's constructor
 after JAXPSAXParser was. I can see a chance where the NetBeans got a
 copy of JAXPSAXParser instance with fSecurityPropertyMgr not
 initialized. The fix is to remove the reference of
 fSecurityPropertyMgr in JAXPSAXParser, and pass it in when
 JAXPSAXParser is created.
 
 Here is the webrev:
 http://cr.openjdk.java.net/~joehw/7u40/8021148/webrev/
 
 [1]
 http://cr.openjdk.java.net/~joehw/7u40/8021148/webrev/src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java.html
 
 [2]
 
 Caused by: java.lang.NullPointerException
 at
 com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.access$300(SAXParserImpl.java:69)
 
 at
 com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.setProperty(SAXParserImpl.java:545)
 
 at
 com.sun.org.apache.xml.internal.utils.XMLReaderManager.getXMLReader(XMLReaderManager.java:161)
 
 at
 com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault.getXMLReader(DTMManagerDefault.java:613)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:401)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:252)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.java:559)
 
 ... 43 more
 -
 javax.xml.transform.TransformerException: java.lang.NullPointerException
 at
 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.java:581)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:742)
 
 at
 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:353)
 
 at
 org.netbeans.spi.project.support.ant.GeneratedFilesHelper$1$1.run(GeneratedFilesHelper.java:332)
 
 
 Thanks,
 Joe
 
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR : 6799426 : (xs) Add constructor PriorityQueue(Comparator)

[Lance Andersen - Oracle]

looks fine Mike

Best
Lance
On Jul 22, 2013, at 3:24 PM, Mike Duigou wrote:

 Hello all;
 
 A simple rewiew for the addition of another constructor to PriorityQueue. 
 Currently if you wish to specify a Comparator you must also supply a size. 
 This addition allows use of the default size which is good for two reason; 
 you don't have to specify a fixed value and the implementation can change 
 it's default as appropriate.
 
 http://cr.openjdk.java.net/~mduigou/JDK-6799426/0/webrev/
 
 Mike


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: (JAXP) 8020430 : NullPointerException in xml sqe nightly result on 2013-07-12

[Lance Andersen - Oracle]

The fix looks fine to me Joe as does the test.  I assume you will go with 
Chris's plan below for the test locations?

Best
Lance
On Jul 12, 2013, at 5:44 AM, Chris Hegarty wrote:

 The source changes look fine to me.
 
 The tests should be located elsewhere, otherwise they will collide with an 
 Oracle internal repo. Say jdk/test/jaxp?
 
 As an aside, I plan to move the jaxws tests to a similar holding area, 
 jdk/test/jaxws. They can then follow the appropriate package structure.
 
 -Chris
 
 On 12 Jul 2013, at 09:59, huizhe wang huizhe.w...@oracle.com wrote:
 
 Hi,
 
 This is a quick fix on a regression caused by 8016648.  The new property 
 manager added to handle the new jaxp 1.5 properties is only created for the 
 input and event factories. For the output factory therefore, there should 
 have a null-check.  I've run the tests used in the nightly build with a 
 local build, all passed with this patch.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8020430/webrev/
 
 Thanks,
 Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 8 code review request for JDK-8020095: Fix doclint warnings in java.util.regex

[Lance Andersen - Oracle]

Looks fine Joe including Mandy's feedback

Best
Lance
On Jul 8, 2013, at 10:10 PM, Joe Darcy wrote:

 Hello,
 
 Please review my changes to resolve (almost all of):
 
JDK-8020095 Fix doclint warnings in java.util.regex
http://cr.openjdk.java.net/~darcy/8020095.0/
 
 Full text of the patch also included below.
 
 For some reason I have not been able to determine, even with the patch, one 
 error remains:
 
 src/share/classes/java/util/regex/Pattern.java:222: error: text not allowed 
 in table element
 * tr align=leftth colspan=2 id=unicodeClasses for Unicode scripts, 
 blocks, categories and binary properties/th/tr
 ^
 1 error
 
 This line has the same structure as other that appear unproblematic. In any 
 case, since over 200 doclint issues are resolved with the patch, I'd like to 
 go forward with the patch and have this lone remaining error investigated 
 later on.
 
 Thanks,
 
 -Joe
 
 --- old/src/share/classes/java/util/regex/MatchResult.java 2013-07-08 
 19:03:31.0 -0700
 +++ new/src/share/classes/java/util/regex/MatchResult.java 2013-07-08 
 19:03:31.0 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -77,7 +77,7 @@
 public int start(int group);
 
 /**
 - * Returns the offset after the last character matched. /p
 + * Returns the offset after the last character matched.
  *
  * @return  The offset after the last character matched
  *
 --- old/src/share/classes/java/util/regex/Matcher.java2013-07-08 
 19:03:32.0 -0700
 +++ new/src/share/classes/java/util/regex/Matcher.java2013-07-08 
 19:03:32.0 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -29,7 +29,7 @@
 
 /**
  * An engine that performs match operations on a {@link java.lang.CharSequence
 - * /codecharacter sequencecode} by interpreting a {@link Pattern}.
 + * character sequence} by interpreting a {@link Pattern}.
  *
  * p A matcher is created from a pattern by invoking the pattern's {@link
  * Pattern#matcher matcher} method.  Once created, a matcher can be used to
 @@ -330,7 +330,7 @@
 }
 
 /**
 - * Returns the start index of the previous match.  /p
 + * Returns the start index of the previous match.
  *
  * @return  The index of the first character matched
  *
 @@ -402,7 +402,7 @@
 }
 
 /**
 - * Returns the offset after the last character matched. /p
 + * Returns the offset after the last character matched.
  *
  * @return  The offset after the last character matched
  *
 @@ -647,6 +647,7 @@
  * invocations of the {@link #find()} method will start at the first
  * character not matched by this match.  /p
  *
 + * @param start the index to start searching for a match
  * @throws  IndexOutOfBoundsException
  *  If start is less than zero or if start is greater than the
  *  length of the input sequence.
 @@ -736,8 +737,8 @@
  * captured during the previous match: Each occurrence of
  * tt${/ttiname/itt}/tt or tt$/ttig/i
  * will be replaced by the result of evaluating the corresponding
 - * {@link #group(String) group(name)} or {@link #group(int) 
 group(g)/tt}
 - * respectively. For tt$/ttig/itt/tt,
 + * {@link #group(String) group(name)} or {@link #group(int) group(g)}
 + * respectively. For tt$/ttig/i,
  * the first number after the tt$/tt is always treated as part of
  * the group reference. Subsequent numbers are incorporated into g if
  * they would form a legal group reference. Only the numerals '0'
 --- old/src/share/classes/java/util/regex/Pattern.java2013-07-08 
 19:03:32.0 -0700
 +++ new/src/share/classes/java/util/regex/Pattern.java2013-07-08 
 19:03:32.0 -0700
 @@ -45,8 +45,8 @@
  *
  * p A regular expression, specified as a string, must first be compiled 
 into
  * an instance of this class.  The resulting pattern can then be used to 
 create
 - * a {@link Matcher} object that can match arbitrary {@link
 - * java.lang.CharSequence /codecharacter sequencescode} against the 
 regular
 + * a {@link Matcher} object that can match arbitrary {@linkplain
 + * java.lang.CharSequence character sequences} against the regular
  * expression.  All of the state involved in performing a match resides in the
  * matcher, so many matchers can share the same pattern.
  *
 @@ -73,15 +73,15 @@
  * such use.
  *
  *
 - * a name=sum
 - * h4 

Re: RFR: JAXP 1.5 for JDK8/7u40: 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown

[Lance Andersen - Oracle]

Hi Joe

Looks good

Best
Lance
On Jul 8, 2013, at 9:07 PM, huizhe wang wrote:

 Hi,
 
 I've updated webrev with improved property management, and quality backed by 
 320 test cases. Thanks Daniel for the help expanding the test suite!
 
 Here's the webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8016648/webrev/
 
 -Joe
 
 On 7/5/2013 6:48 PM, huizhe wang wrote:
 
 On 7/5/2013 1:32 AM, Alan Bateman wrote:
 On 04/07/2013 21:25, huizhe wang wrote:
 
 Reverted back to the original code: 
 http://cr.openjdk.java.net/~joehw/jdk8/8016648/webrev/
 The code split the version number and look at the 1st or 2nd element, it 
 thus works for both the current format and the proposed one, e.g. for 
 1.7.0, it compares with the 2nd element, and for the proposed 
 MAJOR.MINOR.FU.*, the 1st or MAJOR.
 Thanks for dropping the dependency on javax.lang.model. What you now is 
 probably okay although I'm a bit dubious about attempting to support an 
 alternative format (I'm not aware of any proposal that changes the format 
 of the java.version property as changing it would like cause a lot of 
 breakage).
 
 There was a survey from Iris last year, and the JPG site has a presentation 
 from Aurelio. But you're right, I'll remove it. If there's any change in the 
 future, that is if it happens at all, we can always add that back.
 
 A minor point but isJDKOrAbove looks a bit odd to me, I'd probably go for 
 something like isJavaVersionGTE or isJavaVersionAtLeast but as it's not 
 part of the API then it doesn't matter of course.
 
 isJavaVersionAtLeast is easy to understand. What does GTE stand for?
 
 
 I think I mentioned it a while back but have warnings emitted with 
 System.err can be problematic (gets mixed up with application messages to 
 stderr). I realize the Xerces code seems to do this in places but we really 
 need to see about eliminating these messages or getting consistent logging 
 into this code.
 
 I agree, this one is not particularly graceful. There were 88 matches of 
 System.err in Xalan and 75 in Xerces, although some I believe are used for 
 debugging. It could take quite some effort.
 
 I mentioned that with a standalone release, we were trying to stay away from 
 new JDK features. It's probably better to spend time/effort on some upgrades.
 
 
 :
 
 The last scenario to work on is if FSP is set on the Validator instead of 
 SchemaFactory. With that, I'm looking at refactoring the way properties 
 are represented so that they carry state. It would then be cleaner to pass 
 them from SchemaFactory over to Schema and then Validator. It's a bit of 
 work. Fortunately, we only have three of them to deal with.
 So are you planning to send another webrev or do it as a separate issue?
 
 Looking at affected code by this change, it doesn't seem to be too bad. I'll 
 send another webrev.
 
 Joe
 
 
 -Alan
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 8 code review request for doclint fixes in java.util.jar.Pack200

[Lance Andersen - Oracle]

looks good Joe
On Jun 30, 2013, at 7:20 PM, Joe Darcy wrote:

 Hello,
 
 Pack200 has some doclint issues; please review the fixes to them below.
 
 Thanks,
 
 -Joe
 
 --- a/src/share/classes/java/util/jar/Pack200.javaSun Jun 30 16:02:11 
 2013 -0700
 +++ b/src/share/classes/java/util/jar/Pack200.javaSun Jun 30 16:19:25 
 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -112,7 +112,7 @@
 // Static methods of the Pack200 class.
 /**
  * Obtain new instance of a class that implements Packer.
 - *
 + * ul
  * lipIf the system property ttjava.util.jar.Pack200.Packer/tt
  * is defined, then the value is taken to be the fully-qualified name
  * of a concrete implementation class, which must implement Packer.
 @@ -122,6 +122,7 @@
  * lipIf an implementation has not been specified with the system
  * property, then the system-default implementation class is instantiated,
  * and the result is returned./p/li
 + * /ul
  *
  * pNote:  The returned object is not guaranteed to operate
  * correctly if multiple threads use it at the same time.
 @@ -137,7 +138,7 @@
 
 /**
  * Obtain new instance of a class that implements Unpacker.
 - *
 + * ul
  * lipIf the system property ttjava.util.jar.Pack200.Unpacker/tt
  * is defined, then the value is taken to be the fully-qualified
  * name of a concrete implementation class, which must implement Unpacker.
 @@ -147,6 +148,7 @@
  * lipIf an implementation has not been specified with the
  * system property, then the system-default implementation class
  * is instantiated, and the result is returned./p/li
 + * /ul
  *
  * pNote:  The returned object is not guaranteed to operate
  * correctly if multiple threads use it at the same time.
 @@ -350,14 +352,14 @@
  * directory will be passed also.
  * p
  * Examples:
 - * precode
 + * pre{@code
  * Map p = packer.properties();
  * p.put(PASS_FILE_PFX+0, mutants/Rogue.class);
  * p.put(PASS_FILE_PFX+1, mutants/Wolverine.class);
  * p.put(PASS_FILE_PFX+2, mutants/Storm.class);
  * # Pass all files in an entire directory hierarchy:
  * p.put(PASS_FILE_PFX+3, police/);
 - * /pre/code.
 + * }/pre
  */
 String PASS_FILE_PFX= pack.pass.file.;
 
 @@ -378,12 +380,12 @@
  * This is the default value for this property.
  * p
  * Examples:
 - * precode
 + * pre{@code
  * Map p = pack200.getProperties();
  * p.put(UNKNOWN_ATTRIBUTE, ERROR);
  * p.put(UNKNOWN_ATTRIBUTE, STRIP);
  * p.put(UNKNOWN_ATTRIBUTE, PASS);
 - * /pre/code
 + * }/pre
  */
 String UNKNOWN_ATTRIBUTE= pack.unknown.attribute;
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 8 code review request for doclint cleanup of javax.naming.*

[Lance Andersen - Oracle]

Hi Joe,

Looks good.

fwiw,  I was able to use H3 vs H1 tags to make doclint accessibility happy.
Not sure if it matters below but thought I would point it out if you want a 
smaller heading

Best
Lance
On Jun 28, 2013, at 1:54 PM, Joe Darcy wrote:

 Hello,
 
 Still more doclint fixes for review below; this time to javax.naming.*.
 
 Thanks,
 
 -Joe
 
 --- a/src/share/classes/javax/naming/CompositeName.javaFri Jun 28 
 16:39:15 2013 +0100
 +++ b/src/share/classes/javax/naming/CompositeName.javaFri Jun 28 
 10:54:12 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -42,7 +42,7 @@
  * The most significant component is at index 0.
  * An empty composite name has no components.
  *p
 - * h4JNDI Composite Name Syntax/h4
 + * h1JNDI Composite Name Syntax/h1
  * JNDI defines a standard string representation for composite names. This
  * representation is the concatenation of the components of a composite name
  * from left to right using the component separator (a forward
 @@ -73,12 +73,12 @@
  * a separator) denotes a trailing empty component.
  * Adjacent component separators denote an empty component.
  *p
 - *h4Composite Name Examples/h4
 + *h1Composite Name Examples/h1
  *This table shows examples of some composite names. Each row shows
  *the string form of a composite name and its corresponding structural form
  *(ttCompositeName/tt).
  *p
 -table border=1 cellpadding=3 width=70% summary=examples showing string 
 form of composite name and its corresponding structural form (CompositeName)
 +table border=1 cellpadding=3 summary=examples showing string form of 
 composite name and its corresponding structural form (CompositeName)
 
 tr
 thString Name/th
 @@ -137,14 +137,14 @@
 /tr
 /table
  * p
 - *h4Composition Examples/h4
 + *h1Composition Examples/h1
  * Here are some composition examples.  The right column shows composing
  * string composite names while the left column shows composing the
  * corresponding ttCompositeName/tts.  Notice that composing the
  * string forms of two composite names simply involves concatenating
  * their string forms together.
 
 -p table border=1 cellpadding=3 width=70% summary=composition 
 examples showing string names and composite names
 +p table border=1 cellpadding=3 summary=composition examples showing 
 string names and composite names
 
 tr
 thString Names/th
 @@ -189,7 +189,7 @@
 
 /table
  *p
 - *h4Multithreaded Access/h4
 + *h1Multithreaded Access/h1
  * A ttCompositeName/tt instance is not synchronized against concurrent
  * multithreaded access. Multiple threads trying to access and modify a
  * ttCompositeName/tt should lock the object.
 diff -r 52b4527d3fc7 src/share/classes/javax/naming/CompoundName.java
 --- a/src/share/classes/javax/naming/CompoundName.javaFri Jun 28 16:39:15 
 2013 +0100
 +++ b/src/share/classes/javax/naming/CompoundName.javaFri Jun 28 10:54:12 
 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -39,7 +39,7 @@
  * The most significant component is at index 0.
  * An empty compound name has no components.
  *p
 - * h4Compound Name Syntax/h4
 + * h1Compound Name Syntax/h1
  * The syntax of a compound name is specified using a set of properties:
  *dl
  *  dtjndi.syntax.direction
 @@ -136,7 +136,7 @@
  * so that when the same string is parsed, it will yield the same components
  * of the original compound name.
  *p
 - *h4Multithreaded Access/h4
 + *h1Multithreaded Access/h1
  * A ttCompoundName/tt instance is not synchronized against concurrent
  * multithreaded access. Multiple threads trying to access and modify a
  * ttCompoundName/tt should lock the object.
 diff -r 52b4527d3fc7 src/share/classes/javax/naming/Context.java
 --- a/src/share/classes/javax/naming/Context.javaFri Jun 28 16:39:15 2013 
 +0100
 +++ b/src/share/classes/javax/naming/Context.javaFri Jun 28 10:54:12 2013 
 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1999, 2006, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -32,7 +32,7 @@
  * consists of a set of name-to-object bindings.
  * It contains methods for examining and updating these bindings.
  * p
 - * h4Names/h4
 + * h1Names/h1
  * Each name passed as an argument to a 

Review needed for ResultSet.next typo bug 8019286

[Lance Andersen - Oracle]

Hi,

Looking for a reviewer for this minor typo in ResultSet.next()

$ hg diff
diff -r 4e69a7dfbeac src/share/classes/java/sql/ResultSet.java
--- a/src/share/classes/java/sql/ResultSet.java Thu Jun 27 10:21:22 2013 +0100
+++ b/src/share/classes/java/sql/ResultSet.java Fri Jun 28 18:09:36 2013 -0400
@@ -148,7 +148,7 @@
 public interface ResultSet extends Wrapper, AutoCloseable {
 
 /**
- * Moves the cursor froward one row from its current position.
+ * Moves the cursor forward one row from its current position.
  * A codeResultSet/code cursor is initially positioned
  * before the first row; the first call to the method
  * codenext/code makes the first row the current row; the
dhcp-amer-vpn-adc-anyconnect-10-154-144-63:sql lanceandersen$ 


Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 8 code review request: doclint cleanup of java.util.logging

[Lance Andersen - Oracle]

+1
On Jun 27, 2013, at 2:58 PM, Joe Darcy wrote:

 Hello,
 
 Please review the patch below which resolves doclint warnings in 
 java.util.logging.
 
 Thanks,
 
 -Joe
 
 diff -r 1c31082f0a51 src/share/classes/java/util/logging/Handler.java
 --- a/src/share/classes/java/util/logging/Handler.javaThu Jun 27 11:06:46 
 2013 -0700
 +++ b/src/share/classes/java/util/logging/Handler.javaThu Jun 27 11:56:23 
 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -209,6 +209,7 @@
 /**
  * Retrieves the ErrorManager for this Handler.
  *
 + * @return the ErrorManager for this Handler
  * @exception  SecurityException  if a security manager exists and if
  * the caller does not have 
 ttLoggingPermission(control)/tt.
  */
 diff -r 1c31082f0a51 src/share/classes/java/util/logging/LogManager.java
 --- a/src/share/classes/java/util/logging/LogManager.javaThu Jun 27 
 11:06:46 2013 -0700
 +++ b/src/share/classes/java/util/logging/LogManager.javaThu Jun 27 
 11:56:23 2013 -0700
 @@ -257,7 +257,8 @@
 }
 
 /**
 - * Return the global LogManager object.
 + * Returns the global LogManager object.
 + * @return the global LogManager object
  */
 public static LogManager getLogManager() {
 if (manager != null) {
 diff -r 1c31082f0a51 src/share/classes/java/util/logging/LogRecord.java
 --- a/src/share/classes/java/util/logging/LogRecord.javaThu Jun 27 
 11:06:46 2013 -0700
 +++ b/src/share/classes/java/util/logging/LogRecord.javaThu Jun 27 
 11:56:23 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -211,6 +211,7 @@
  * the message string before formatting it.  The result may
  * be null if the message is not localizable, or if no suitable
  * ResourceBundle is available.
 + * @return the localization resource bundle
  */
 public ResourceBundle getResourceBundle() {
 return resourceBundle;
 @@ -231,6 +232,7 @@
  * This is the name for the ResourceBundle that should be
  * used to localize the message string before formatting it.
  * The result may be null if the message is not localizable.
 + * @return the localization resource bundle name
  */
 public String getResourceBundleName() {
 return resourceBundleName;
 @@ -281,6 +283,7 @@
  * p
  * Sequence numbers are normally assigned in the LogRecord constructor,
  * so it should not normally be necessary to use this method.
 + * @param seq the sequence number
  */
 public void setSequenceNumber(long seq) {
 sequenceNumber = seq;
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: JDK 8 core review request for doclint warnings in javax.script

[Lance Andersen - Oracle]

looks fine joe
On Jun 27, 2013, at 3:47 PM, Joe Darcy wrote:

 Hello,
 
 Please review the next patch in a series of patches to resolve doclint 
 warnings in the JDK; this time in javax.script.
 
 Thanks,
 
 -Joe
 
 diff -r b8f16cb2d95b src/share/classes/javax/script/Invocable.java
 --- a/src/share/classes/javax/script/Invocable.javaThu Jun 27 12:24:26 
 2013 -0700
 +++ b/src/share/classes/javax/script/Invocable.javaThu Jun 27 12:45:29 
 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -63,6 +63,7 @@
 /**
  * Used to call top-level procedures and functions defined in scripts.
  *
 + * @param name of the procedure or function to call
  * @param args Arguments to pass to the procedure or function
  * @return The value returned by the procedure or function
  *
 @@ -79,6 +80,7 @@
  * the interpreter. The methods of the interface
  * may be implemented using the codeinvokeFunction/code method.
  *
 + * @param T the type of the interface to return
  * @param clasz The codeClass/code object of the interface to return.
  *
  * @return An instance of requested interface - null if the requested 
 interface is unavailable,
 @@ -95,6 +97,7 @@
  * a scripting object compiled in the interpreter. The methods of the
  * interface may be implemented using the codeinvokeMethod/code 
 method.
  *
 + * @param T the type of the interface to return
  * @param thiz The scripting object whose member functions are used to 
 implement the methods of the interface.
  * @param clasz The codeClass/code object of the interface to return.
  *
 diff -r b8f16cb2d95b src/share/classes/javax/script/ScriptContext.java
 --- a/src/share/classes/javax/script/ScriptContext.javaThu Jun 27 
 12:24:26 2013 -0700
 +++ b/src/share/classes/javax/script/ScriptContext.javaThu Jun 27 
 12:45:29 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved.
 + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -78,6 +78,7 @@
  * @return The associated codeBindings/code. Returns 
 codenull/code if it has not
  * been set.
  *
 + * @param scope The scope
  * @throws IllegalArgumentException If no codeBindings/code is 
 defined for the
  * specified scope value in codeScriptContext/code of this type.
  */
 diff -r b8f16cb2d95b src/share/classes/javax/script/ScriptEngineFactory.java
 --- a/src/share/classes/javax/script/ScriptEngineFactory.javaThu Jun 27 
 12:24:26 2013 -0700
 +++ b/src/share/classes/javax/script/ScriptEngineFactory.javaThu Jun 27 
 12:45:29 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -80,6 +80,7 @@
  * identify the codeScriptEngine/code by the 
 codeScriptEngineManager/code.
  * For instance, an implementation based on the Mozilla Rhino Javascript 
 engine might
  * return list containing {quot;javascriptquot;, quot;rhinoquot;}.
 + * @return an immutable list of short names
  */
 public ListString getNames();
 
 diff -r b8f16cb2d95b src/share/classes/javax/script/SimpleScriptContext.java
 --- a/src/share/classes/javax/script/SimpleScriptContext.javaThu Jun 27 
 12:24:26 2013 -0700
 +++ b/src/share/classes/javax/script/SimpleScriptContext.javaThu Jun 27 
 12:45:29 2013 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -82,7 +82,9 @@
  */
 protected Bindings globalScope;
 
 -
 +/**
 + * Create a {@code SimpleScriptContext}.
 + */
 public SimpleScriptContext() {
 engineScope = new SimpleBindings();
 globalScope = null;
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: 8016217: More javadoc warnings

[Lance Andersen - Oracle]

This looks good.  Thank you for taking this on Alan.

Best
Lance
On Jun 10, 2013, at 6:31 AM, Alan Bateman wrote:

 
 About 8 months ago I tried an early build of doclint [1] and used it to fix 
 up a bunch issues at the time [2]. It's been awhile, so I decided to try out 
 the latest version to see how it has progressed. All I can say is Yikes.  
 The good news is that they reported against the original source and that 
 makes it easy when compared to tools that validate the generated html.
 
 I decided to fix up a few issues, mostly syntax (escaping of  and  in 
 particular) and a few reference issues that were missed the last time (or are 
 new). There are thousands of other issues for anyone that wants to jump in.
 
 I've put the webrev with the changes here:
 
 http://cr.openjdk.java.net/~alanb/8016217/webrev/
 
 In total this fixes ~500 issues, although 270 of those were coming from 
 java.sql.DatabaseMetaData due to the number of un-escaped usages of  =. In 
 many cases, the changes are simply to use {@code ..} or replace code with 
 {@code ...}. It is tempting to just do a global replace on existing 
 code/code usages (would fixing up content that is escaped of course).
 
 I've run specdiff on the before  after to check that I didn't mess anything 
 up. One obvious difference is that code examples that use generics now have 
 the type parameters going through to the generated javadoc.
 
 The webrev touches many areas but as the changes are trivial, I don't need a 
 reviewer from every area.
 
 -Alan.
 
 [1] http://openjdk.java.net/jeps/172
 [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized.

[Lance Andersen - Oracle]

looks fine joe

-lance
On Jun 8, 2013, at 4:11 PM, huizhe wang wrote:

 Hi,
 
 This patch is to continue the support of plugging in 3rd party parser impls 
 (such as Xerces) that do not support JAXP 1.5. The fix is to catch 
 SAXNotRecognizedException, print out a warning, and then continue as usual. 
 The warning is for the developer in case he actually sets the new access* 
 properties on the TransformerFactory but has a 3rd party parser on the 
 classpath that does not support the new properties.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/
 
 I intend to backport the change to 7u.  The change will be identical.
 
 Thanks,
 Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized.

[Lance Andersen - Oracle]

looks OK
On Jun 10, 2013, at 3:26 PM, huizhe wang wrote:

 Thanks Lance!
 
 As Daniel noted, I added warnings to these additional property settings, but 
 there are a couple of other places in the original JAXP 1.5 impl that did not 
 have warning. I've added the warning message now (in 
 ValidatorHandlerImpl.java and XMLReaderManager.java). Also, in 
 ValidatorHandlerImpl.java, there was a redundant setting at line 677 that 
 would invalidate a 3rd party impl. This was a porting error when the patch 
 was ported from jaxp standalone[1] to JDK.  It is now removed.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/
 
 [1] jaxp standalone source
 https://java.net/projects/jaxp-sources/sources/svn/content/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java?rev=3134
 
 Thanks,
 Joe
 
 On 6/10/2013 9:44 AM, Lance Andersen - Oracle wrote:
 looks fine joe
 
 -lance
 On Jun 8, 2013, at 4:11 PM, huizhe wang wrote:
 
 Hi,
 
 This patch is to continue the support of plugging in 3rd party parser impls 
 (such as Xerces) that do not support JAXP 1.5. The fix is to catch 
 SAXNotRecognizedException, print out a warning, and then continue as usual. 
 The warning is for the developer in case he actually sets the new access* 
 properties on the TransformerFactory but has a 3rd party parser on the 
 classpath that does not support the new properties.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/
 
 I intend to backport the change to 7u.  The change will be identical.
 
 Thanks,
 Joe
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering 
 1 Network Drive 
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Review request for 8016101, javadoc typos for SerialRef and SerialStruct

[Lance Andersen - Oracle]

Hi, 

Need a reviewer for this minor javadoc update for bug 8016101


SerialStruct was missing a javadoc @param tag in the constructor
SerialRef had an extra '.'

Best
Lance


hg diff
diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialRef.java
--- a/src/share/classes/javax/sql/rowset/serial/SerialRef.java  Tue May 28 
15:22:30 2013 +0200
+++ b/src/share/classes/javax/sql/rowset/serial/SerialRef.java  Thu Jun 06 
16:01:07 2013 -0400
@@ -202,7 +202,7 @@
 }
 
 /**
- * Returns a clone of this {@code SerialRef}. .
+ * Returns a clone of this {@code SerialRef}.
  * The underlying {@code Ref} object will be set to null.
  *
  * @return  a clone of this SerialRef
diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialStruct.java
--- a/src/share/classes/javax/sql/rowset/serial/SerialStruct.java   Tue May 
28 15:22:30 2013 +0200
+++ b/src/share/classes/javax/sql/rowset/serial/SerialStruct.java   Thu Jun 
06 16:01:07 2013 -0400
@@ -87,6 +87,7 @@
  * object for custom mapping the SQL structured type or any of its
  * attributes that are SQL structured types.
  *
+ * @param in an instance of {@code Struct} 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Review request for 8016101, javadoc typos for SerialRef and SerialStruct

[Lance Andersen - Oracle]

Hi Aleksey,

The change is 2 lines, not worth a webrev.  Here it is again in case it was 
truncated in last email (looked OK on my end)

 
new-host-2:serial lanceandersen$ hg diff
diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialRef.java
--- a/src/share/classes/javax/sql/rowset/serial/SerialRef.java  Tue May 28 
15:22:30 2013 +0200
+++ b/src/share/classes/javax/sql/rowset/serial/SerialRef.java  Thu Jun 06 
16:01:07 2013 -0400
@@ -202,7 +202,7 @@
 }
 
 /**
- * Returns a clone of this {@code SerialRef}. .
+ * Returns a clone of this {@code SerialRef}.
  * The underlying {@code Ref} object will be set to null.
  *
  * @return  a clone of this SerialRef
diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialStruct.java
--- a/src/share/classes/javax/sql/rowset/serial/SerialStruct.java   Tue May 
28 15:22:30 2013 +0200
+++ b/src/share/classes/javax/sql/rowset/serial/SerialStruct.java   Thu Jun 
06 16:01:07 2013 -0400
@@ -87,6 +87,7 @@
  * object for custom mapping the SQL structured type or any of its
  * attributes that are SQL structured types.
  *
+ * @param in an instance of {@code Struct} 
  * @param map a codejava.util.Map/code object in which
  *each entry consists of 1) a codeString/code object
  *giving the fully qualified name of a UDT and 2) the
On Jun 6, 2013, at 4:34 PM, Aleksey Shipilev wrote:

 Hi Lance,
 
 On 06/07/2013 12:09 AM, Lance Andersen - Oracle wrote:
 Need a reviewer for this minor javadoc update for bug 8016101
 
 (not a reviewer) The patch appears to be truncated, can you submit it as
 patch/webrev somewhere on the web (e.g. cr.openjdk.java.net)?
 
 -Aleksey.
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (jaxp): 8015016: Improve JAXP 1.5 error message

[Lance Andersen - Oracle]

Hi Joe,

The change looks OK.  I know the messages have to be translated by the 
globalization team for the other languages.

Best
Lance
On Jun 6, 2013, at 5:42 PM, huizhe wang wrote:

 This is a quick fix to improve the error message so that it's clearly 
 differentiated from those reported by the Security Manager.
 
 The change is identical for both JDK7 and 8. I will backport the fix to 7u40 
 if approved.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8015016/webrev/
 
 Thanks,
 Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR (jaxp): 8015016: Improve JAXP 1.5 error message

[Lance Andersen - Oracle]

Hi Joe
On Jun 6, 2013, at 5:56 PM, huizhe wang wrote:

 Hi Lance,
 
 Thanks for the quick review!  
 
 I filed a request (8005454) to translate new error messages accumulated since 
 the last translation. But the way the localization tool works is that the 
 error message has to be in the repository before the tool can pull them out.
 
I know it takes time, to get that done.  Thank you for clarifying the error 
message.

Best
Lance
 Best,
 Joe
 
 On 6/6/2013 2:51 PM, Lance Andersen - Oracle wrote:
 Hi Joe,
 
 The change looks OK.  I know the messages have to be translated by the 
 globalization team for the other languages.
 
 Best
 Lance
 On Jun 6, 2013, at 5:42 PM, huizhe wang wrote:
 
 This is a quick fix to improve the error message so that it's clearly 
 differentiated from those reported by the Security Manager.
 
 The change is identical for both JDK7 and 8. I will backport the fix to 
 7u40 if approved.
 
 webrev:
 http://cr.openjdk.java.net/~joehw/jdk8/8015016/webrev/
 
 Thanks,
 Joe
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering 
 1 Network Drive 
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8000450: Restrict access to com/sun/corba/se/impl package

[Lance Andersen - Oracle]

the changes make sense to me
On Jun 4, 2013, at 6:57 PM, Seán Coffey wrote:

 The com.sun.corba.se.impl package is a private package. The API is subject to 
 change at any time and no 3rd party code should be using it. As a result, I'd 
 like to add it to the package restricted list. I've run our internal CORBA 
 SQE testsuite against the proposed change and didn't see any issues.
 
 bug report : http://bugs.sun.com/view_bug.do?bug_id=8000450
 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8000450.jdk8/
 
 I plan to port the same change to jdk7u.
 
 regards,
 Sean.


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Code review request, JDK-8010814, More buffers are stored or returned without cloning

[Lance Andersen - Oracle]

Looks fine Xuelei

best
Lance
On May 16, 2013, at 5:08 AM, Xuelei Fan wrote:

 Hi,
 
 There is another fix to avoid the use of mutable objects.
 
 webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/
 
 Thanks,
 Xuelei


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: 8014500: bootcycle-images fails after upgrade to JAXP 1.5

[Lance Andersen - Oracle]

+1
On May 14, 2013, at 8:16 AM, Alan Bateman wrote:

 
 The bootcycle-images target is currently broken in jdk8/tl.
 
 Jon has taken 8014461 to fix genstubs but once you get past that then the 
 CLDRConverter fails parsing LDML due to DTD references that aren't allowed by 
 the default policy in jdk8 (since the update to JAXP 1.5). This policy is due 
 to be re-visited later in jdk8 and I expect it will need to allow at least 
 access to the DTDs on the file system. For now, and to get the boot cycle 
 builds going again, I propose to update the CLDRConverter to set the 
 accessExternalDTD property.
 
 Attached is the proposed patch. It uses a hard-coded string rather than 
 XMLConstants.ACCESS_EXTERNAL_DTD because the boot JDK will likely have an 
 older version of JAXP where this constant isn't defined.
 
 Thanks,
 Alan.
 
 
 
 diff --git a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java 
 b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java
 --- a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java
 +++ b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java
 @@ -34,6 +34,8 @@
 import java.util.*;
 import javax.xml.parsers.SAXParser;
 import javax.xml.parsers.SAXParserFactory;
 +import org.xml.sax.SAXNotRecognizedException;
 +import org.xml.sax.SAXNotSupportedException;
 
 
 /**
 @@ -234,6 +236,17 @@
 }
 }
 
 +/**
 + * Configure the parser to allow access to DTDs on the file system.
 + */
 +private static void enableFileAccess(SAXParser parser) throws 
 SAXNotSupportedException {
 +try {
 +
 parser.setProperty(http://javax.xml.XMLConstants/property/accessExternalDTD;,
  file);
 +} catch (SAXNotRecognizedException ignore) {
 +// property requires = JAXP 1.5
 +}
 +}
 +
 private static ListBundle readBundleList() throws Exception {
 ResourceBundle.Control defCon = 
 ResourceBundle.Control.getControl(ResourceBundle.Control.FORMAT_DEFAULT);
 ListBundle retList = new ArrayList();
 @@ -279,6 +292,7 @@
 SAXParserFactory factory = SAXParserFactory.newInstance();
 factory.setValidating(true);
 SAXParser parser = factory.newSAXParser();
 +enableFileAccess(parser);
 LDMLParseHandler handler = new LDMLParseHandler(id);
 File file = new File(SOURCE_FILE_DIR + File.separator + id + .xml);
 if (!file.exists()) {
 @@ -314,6 +328,7 @@
 SAXParserFactory factorySuppl = SAXParserFactory.newInstance();
 factorySuppl.setValidating(true);
 SAXParser parserSuppl = factorySuppl.newSAXParser();
 +enableFileAccess(parserSuppl);
 handlerSuppl = new SupplementDataParseHandler();
 File fileSupply = new File(SPPL_SOURCE_FILE);
 parserSuppl.parse(fileSupply, handlerSuppl);
 @@ -322,6 +337,7 @@
 SAXParserFactory numberingParser = SAXParserFactory.newInstance();
 numberingParser.setValidating(true);
 SAXParser parserNumbering = numberingParser.newSAXParser();
 +enableFileAccess(parserNumbering);
 handlerNumbering = new NumberingSystemsParseHandler();
 File fileNumbering = new File(NUMBERING_SOURCE_FILE);
 parserNumbering.parse(fileNumbering, handlerNumbering);
 @@ -330,6 +346,7 @@
 SAXParserFactory metazonesParser = SAXParserFactory.newInstance();
 metazonesParser.setValidating(true);
 SAXParser parserMetaZones = metazonesParser.newSAXParser();
 +enableFileAccess(parserMetaZones);
 handlerMetaZones = new MetaZonesParseHandler();
 File fileMetaZones = new File(METAZONES_SOURCE_FILE);
 parserNumbering.parse(fileMetaZones, handlerMetaZones);


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFEs implementing JEP 170

[Lance Andersen - Oracle]

Hi Neil,

Just back from holiday and catching up (or trying to)

 
On May 2, 2013, at 7:13 AM, Neil Richards wrote:

 
 Hi Lance,
 I've been trying to identify the Java bug ids for the RFEs which
 implement JEP 170 (which, from what I can tell, should be in OpenJDK 8
 since milestone 6 [1]).

The following changesets are for JDBC 4.2

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3da0d29d7cd (8005080)
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dcb74c3ffba (8007520)
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac3e189c9099 (8010416)

The last change was pushed last week before I left so at this point JDBC 4.2/ 
JEP 170 is complete.  I will look to update the JEP now that I am back once I 
catch up on my backlog :-)

Best
Lance
 
 Unlike most JEPs, the entry for 170 does not seem to hold references to
 these ids (only to the affected JSRs).
 
 Searching the mailing archives for jep 170, jsr 114  jsr 221 also
 didn't offer any greater insight, though by searching for jdbc 4.2, I
 did manage to find reference to 8005080 [2] [3].
 
 That conversation suggests there should be other RFEs concerned with
 the remaining implementation of JEP 170, but I haven't been able to
 determine which those are.
 
 Could you please tell me which RFEs implements this JEP?
 It also would be good to update the document for JEP 170 [4] with there
 references, and perhaps update its status to Completed if it has,
 indeed, been completely delivered into openjdk 8?
 
 Thanks,
 Neil
 
 [1] http://openjdk.java.net/projects/jdk8/milestones
 [2] 
 http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013569.html
 [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d3da0d29d7cd
 [4] http://openjdk.java.net/jeps/170
 
 -- 
 Unless stated above:
 IBM email: neil_richards at uk.ibm.com
 IBM United Kingdom Limited - Registered in England and Wales with number 
 741598.
 Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8011814/8013271/8013272: Three improvements to J2SE Netbeans project

[Lance Andersen - Oracle]

Hi Mike,

The changes look good to me.  

Best
Lance
On Apr 29, 2013, at 10:11 PM, Mike Duigou wrote:

 Hello All;
 
 This is a review for three changes to the J2SE Netbeans project. If necessary 
 I can break this up into three separate patches but I would rather not if 
 possible.
 
 
 http://cr.openjdk.java.net/~mduigou/JDK-8011814/0/webrev/
 
 
 8011814: Add testng.jar to Netbeans projects test compile classpath
 
 An increasing number of jtreg tests now use TestNG. This change adds the 
 TestNG jar from you JTReg installation to the tests classpath. The location 
 of JTReg is specified in build.properties using jtreg.home or from the 
 environment via JT_HOME.
 
 
 8013271: Add OS X sources to J2SE Netbeans project
 
 Adds as source entry for Apple OS X sources to match the Unix and Windows 
 entries. I checked the trademark with the Apple Trademarks page to make sure 
 I got it correct.
 
 
 8013272: JDK Netbeans projects should use ASCII encoding for sources
 
 The build scripts compile all OpenJDK java sources using the US-ASCII 
 encoding. This change causes Netbeans to respect this encoding. Whether 
 US-ASCII is the awesomest encoding is certainly debatable, but all editors 
 and IDEs should use what the compiler uses.
 
 
 Thanks for reviewing,
 
 Mike


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request for 8010416: Provide a way for DriverManager.deregisterDriver to notify the JDBC driver that it has been deregistered.

[Lance Andersen - Oracle]

On Apr 26, 2013, at 8:35 AM, Alan Bateman wrote:

 On 25/04/2013 21:53, Lance Andersen - Oracle wrote:
 http://cr.openjdk.java.net/~lancea/8010416/webrev.03/  addresses the typos 
 that were pointed out and also fixes a couple javadoc warnings
 
 This looks okay to me.
 
 One small suggestion for DriverAction and the first statement where it reads 
  ... when a Driver wants to be notified by DriverManager. It might be 
 better as ... to receive notifications from the DriverManager. I suggest 
 this because it's not specifically the Driver that is notified.

I changed it to

A JDBC driver may create a DriverAction implementation in order to receive 
notifications when DriverManager.deregisterDriver has been called.


I won't issue another webrev but once the ccc is final I will push the changes


thank you for the input

best
Lance
 
 -Alan.
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request for 8010416: Provide a way for DriverManager.deregisterDriver to notify the JDBC driver that it has been deregistered.

[Lance Andersen - Oracle]

http://cr.openjdk.java.net/~lancea/8010416/webrev.03/  addresses the typos that 
were pointed out and also fixes a couple javadoc warnings

Best,
Lance
On Apr 22, 2013, at 11:17 AM, Lance Andersen - Oracle wrote:

 
 On Apr 22, 2013, at 9:13 AM, Alan Bateman wrote:
 
 On 21/04/2013 12:45, Lance Andersen - Oracle wrote:
 :
 
 DriverManager
 
 - one point that isn't covered in the spec is whether the DriverAction's 
 deregister is invoked before or after it is deregistered. This distinction 
 is probably only interesting for the case that the deregister method fails 
 with an error/exception but it's not clear if the driver is still 
 registered in that case. For completeness then the spec should probably 
 say that any error/runtime exception is propagated to the caller of 
 deregisterDriver.
 
 - could the new (and the original) registerDriver methods specify the 
 behavior for the case that the Driver is already registered? This brings 
 up the question as to whether the DriverAction is overridden if already 
 registered.
 clarified
 Thanks, I think that covers all the corner cases.
 
 One typo, line 376, should be If the specified 
 
 Fixed that thank you.
 
 -Alan.
 
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering 
 1 Network Drive 
 Burlington, MA 01803
 lance.ander...@oracle.com
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request for 8010416: Provide a way for DriverManager.deregisterDriver to notify the JDBC driver that it has been deregistered.

[Lance Andersen - Oracle]

On Apr 21, 2013, at 11:09 AM, Ulf Zibis wrote:

 Minor nits:
 DriverManager line 349: I would break the line right after the opening 
 parenthesis.

I did not change this as other methods break after the 1st parameter 
(getConnection is one example) so I would prefer to keep it consistent (or as 
much as it can be)
 DriverManager line 355: missing space after comma.

fixed this.  thank for this

Best
Lance
 
 -Ulf
 
 Am 21.04.2013 13:45, schrieb Lance Andersen - Oracle:
 Thank you for the feedback Alan,
 
 Please see below and the webrev 
 http://cr.openjdk.java.net/~lancea/8010416/webrev.02/
 On Apr 21, 2013, at 4:34 AM, Alan Bateman wrote:
 
 On 19/04/2013 18:34, Lance Andersen - Oracle wrote:
 Hi,
 
 We have been asked  by a few JDBC driver vendors  to allow a JDBC driver 
 to be notified when/if it was deregistered via 
 DriverManager.deregisterDriver if desired.
 
 
 The webrev can be found at 
 http://cr.openjdk.java.net/~lancea/8010416/webrev.01
 
 This looks much better than the original proposal, it would have been just 
 too problematic to have Driver define a deregister method. Also the 
 proposed wording to specify Driver-implementation specific behavior when 
 the Driver or Connections is in use, or subsequent use, addresses the 
 points that I brought up in the original thread here (thanks!).
 
 Driver
 
 - {@linkplain DriverManager.deregister} - I assume this should 
 DriverManagert#deregisterDriver
 
 - minor alignment issue with the p tag.
 Fixed
 
 DriverManager
 
 - one point that isn't covered in the spec is whether the DriverAction's 
 deregister is invoked before or after it is deregistered. This distinction 
 is probably only interesting for the case that the deregister method fails 
 with an error/exception but it's not clear if the driver is still 
 registered in that case. For completeness then the spec should probably say 
 that any error/runtime exception is propagated to the caller of 
 deregisterDriver.
 
 - could the new (and the original) registerDriver methods specify the 
 behavior for the case that the Driver is already registered? This brings up 
 the question as to whether the DriverAction is overridden if already 
 registered.
 clarified
 - the @param alignment is inconsistent in the new deregisterDriver.
 done
 - the re-wording of the original deregisterDriver looks much better. Minor 
 nit: was null - is null.
 done
 - DriverInfo - would be cleaner to extend the constructor to take the 
 DriverAction. Also an action() accessor would make the usage a bit cleaner 
 too.
 done
 
 Best
 Lance
 
 That's all I have for now.
 
 -Alan
 
 
 
 
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering
 1 Network Drive
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request for 8010416: Provide a way for DriverManager.deregisterDriver to notify the JDBC driver that it has been deregistered.

[Lance Andersen - Oracle]

On Apr 22, 2013, at 9:13 AM, Alan Bateman wrote:

 On 21/04/2013 12:45, Lance Andersen - Oracle wrote:
 :
 
 DriverManager
 
 - one point that isn't covered in the spec is whether the DriverAction's 
 deregister is invoked before or after it is deregistered. This distinction 
 is probably only interesting for the case that the deregister method fails 
 with an error/exception but it's not clear if the driver is still 
 registered in that case. For completeness then the spec should probably say 
 that any error/runtime exception is propagated to the caller of 
 deregisterDriver.
 
 - could the new (and the original) registerDriver methods specify the 
 behavior for the case that the Driver is already registered? This brings up 
 the question as to whether the DriverAction is overridden if already 
 registered.
 clarified
 Thanks, I think that covers all the corner cases.
 
 One typo, line 376, should be If the specified 

Fixed that thank you.
 
 -Alan.
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request for 8010416: Provide a way for DriverManager.deregisterDriver to notify the JDBC driver that it has been deregistered.

[Lance Andersen - Oracle]

Thank you for the feedback Alan,

Please see below and the webrev 
http://cr.openjdk.java.net/~lancea/8010416/webrev.02/
On Apr 21, 2013, at 4:34 AM, Alan Bateman wrote:

 On 19/04/2013 18:34, Lance Andersen - Oracle wrote:
 Hi,
 
 We have been asked  by a few JDBC driver vendors  to allow a JDBC driver to 
 be notified when/if it was deregistered via DriverManager.deregisterDriver 
 if desired.
 
 
 The webrev can be found at 
 http://cr.openjdk.java.net/~lancea/8010416/webrev.01
 
 This looks much better than the original proposal, it would have been just 
 too problematic to have Driver define a deregister method. Also the proposed 
 wording to specify Driver-implementation specific behavior when the Driver or 
 Connections is in use, or subsequent use, addresses the points that I brought 
 up in the original thread here (thanks!).
 
 Driver
 
 - {@linkplain DriverManager.deregister} - I assume this should 
 DriverManagert#deregisterDriver
 
 - minor alignment issue with the p tag.

Fixed
 
 
 DriverManager
 
 - one point that isn't covered in the spec is whether the DriverAction's 
 deregister is invoked before or after it is deregistered. This distinction is 
 probably only interesting for the case that the deregister method fails with 
 an error/exception but it's not clear if the driver is still registered in 
 that case. For completeness then the spec should probably say that any 
 error/runtime exception is propagated to the caller of deregisterDriver.
 
 - could the new (and the original) registerDriver methods specify the 
 behavior for the case that the Driver is already registered? This brings up 
 the question as to whether the DriverAction is overridden if already 
 registered.
clarified
 
 - the @param alignment is inconsistent in the new deregisterDriver.
done
 
 - the re-wording of the original deregisterDriver looks much better. Minor 
 nit: was null - is null.
done
 
 - DriverInfo - would be cleaner to extend the constructor to take the 
 DriverAction. Also an action() accessor would make the usage a bit cleaner 
 too.

done

Best
Lance
 
 
 That's all I have for now.
 
 -Alan
 
 
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

review request for 8010416: Provide a way for DriverManager.deregisterDriver to notify the JDBC driver that it has been deregistered.

[Lance Andersen - Oracle]

Hi,

We have been asked  by a few JDBC driver vendors  to allow a JDBC driver to be 
notified when/if it was deregistered via DriverManager.deregisterDriver if 
desired.


The webrev can be found at http://cr.openjdk.java.net/~lancea/8010416/webrev.01



Best
Lance



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Review Request: 8012624: Add sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java in ProblemList.txt

[Lance Andersen - Oracle]

+1
On Apr 18, 2013, at 2:07 PM, Mandy Chung wrote:

 This fix adds GetSafepointSyncTime.java test in the ProblemList.txt
 until 8010897 is resolved. It has been failing intermittently on macosx-x64.
 
 diff --git a/test/ProblemList.txt b/test/ProblemList.txt
 --- a/test/ProblemList.txt
 +++ b/test/ProblemList.txt
 @@ -144,6 +144,9 @@
 
 # jdk_management
 
 +# 8010897
 +sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java   macosx-all
 +
 
 
 # jdk_jmx
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

review request: 8011620 adding free form netbeans project for jdbc to jdk/make/netbeans

[Lance Andersen - Oracle]

Hi,

This is a request to review adding a netbeans freeform project to 
jdk/make/netbeans for jdbc

As part of this change,  I also modified common/shared.xml to properly look for 
the jtreg report.html in the html directory and so the javadoc was using 
version 1.8

The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/

Best
lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: review request: 8011620 adding free form netbeans project for jdbc to jdk/make/netbeans

[Lance Andersen - Oracle]

Thank you ulf,  I made the change in my workspace so that it will be 
accommodated as part of the putback

Best
Lance
On Apr 9, 2013, at 11:26 AM, Ulf Zibis wrote:

 Hi,
 
 there is a little indentation error in build.xml in line 42.
 
 -Ulf
 
 Am 09.04.2013 16:55, schrieb Lance Andersen - Oracle:
 Hi,
 
 This is a request to review adding a netbeans freeform project to 
 jdk/make/netbeans for jdbc
 
 As part of this change,  I also modified common/shared.xml to properly look 
 for the jtreg report.html in the html directory and so the javadoc was using 
 version 1.8
 
 The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/
 
 Best
 lance
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering
 1 Network Drive
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8006036, (process) cleanup code in java/lang/Runtime/exec/WinCommand.java

[Lance Andersen - Oracle]

looks ok
On Apr 5, 2013, at 5:18 PM, Jim Gish wrote:

 Please review trivial change to add back in delete of test files on test 
 completion.
 
 http://cr.openjdk.java.net/~jgish/Bug8006036-WinCommand/ 
 http://cr.openjdk.java.net/%7Ejgish/Bug8006036-WinCommand/
 
 Thanks,
   Jim
 
 -- 
 Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
 Oracle Java Platform Group | Core Libraries Team
 35 Network Drive
 Burlington, MA 01803
 jim.g...@oracle.com
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Review request for 8011393 - javadoc typo in SerialClob.truncate

[Lance Andersen - Oracle]

Hi all

Need a reviewer for the  correction of the following typo in SerialClob.java 
which is bug 8011393


 hg diff SerialClob.java 
diff -r e6c3b8e74e50 src/share/classes/javax/sql/rowset/serial/SerialClob.java
--- a/src/share/classes/javax/sql/rowset/serial/SerialClob.java Tue Apr 02 
10:12:20 2013 -0700
+++ b/src/share/classes/javax/sql/rowset/serial/SerialClob.java Wed Apr 03 
12:06:01 2013 -0400
@@ -508,7 +508,7 @@
  *
  * @param length the length, in bytes, to which the codeCLOB/code
  *value should be truncated
- * @throws SerialLException if there is an error accessing the
+ * @throws SerialException if there is an error accessing the
  *codeCLOB/code value;
  * if the {@code free} method had been previously called on this object
  */


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: Review request for 8011393 - javadoc typo in SerialClob.truncate

[Lance Andersen - Oracle]

Hi Mandy,

Thank you for the suggestion and the review.  I have been making some of those 
changes as I have been going forward.  I agree, that would be better  to use 
{@code} and will look to continue to clean those things up.  Would be great if 
we had an automated tool to help as I am sure there is a lot of code that could 
be cleaned up besides JDBC :-)


Thank you again.

Best
Lance
On Apr 3, 2013, at 1:49 PM, Mandy Chung wrote:

 Looks fine.  You may want to use {@code CLOB} to replace code.../code
 
 Mandy
 
 On 4/3/2013 9:15 AM, Lance Andersen - Oracle wrote:
 Hi all
 
 Need a reviewer for the  correction of the following typo in SerialClob.java 
 which is bug 8011393
 
 
  hg diff SerialClob.java
 diff -r e6c3b8e74e50 
 src/share/classes/javax/sql/rowset/serial/SerialClob.java
 --- a/src/share/classes/javax/sql/rowset/serial/SerialClob.java  Tue Apr 
 02 10:12:20 2013 -0700
 +++ b/src/share/classes/javax/sql/rowset/serial/SerialClob.java  Wed Apr 
 03 12:06:01 2013 -0400
 @@ -508,7 +508,7 @@
   *
   * @param length the length, in bytes, to which the codeCLOB/code
   *value should be truncated
 - * @throws SerialLException if there is an error accessing the
 + * @throws SerialException if there is an error accessing the
   *codeCLOB/code value;
   * if the {@code free} method had been previously called on this object
   */
 
 
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering
 1 Network Drive
 Burlington, MA 01803
 lance.ander...@oracle.com
 
 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Review request 8010416 Addition of Driver.deregisterDriver

[Lance Andersen - Oracle]

Need a reviewer for 8010416, addition of Driver.deregisterDriver.

The webrev can be found at  
http://cr.openjdk.java.net/~lancea/8010416/webrev.00/.

I will be submitting the ccc request later today but want to do this in parallel

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Review request for 8008716 to address typo in CallableStatement javadocs

[Lance Andersen - Oracle]

H alli,

This is a review request  for  8008716 to address a couple of typos in 
CallableStatement:


$ hg diff CallableStatement.java 
diff -r 7dcb74c3ffba src/share/classes/java/sql/CallableStatement.java
--- a/src/share/classes/java/sql/CallableStatement.java Tue Feb 12 09:25:43 
2013 -0800
+++ b/src/share/classes/java/sql/CallableStatement.java Fri Feb 22 09:02:51 
2013 -0500
@@ -2621,7 +2621,7 @@
  * parameter determines the Java type that must be used
  * in the {@code get} method to read the value of that parameter.
  * p
- * This version of {@code  registrOutParameter} should be
+ * This version of {@code  registerOutParameter} should be
  * used when the parameter is of JDBC type {@code JDBCType.NUMERIC}
  * or {@code JDBCType.DECIMAL}.
  *P
@@ -2649,7 +2649,7 @@
 /**
  * Registers the designated output parameter.
  * This version of
- * the method {@code  registrOutParameter}
+ * the method {@code  registerOutParameter}
  * should be used for a user-defined or {@code REF} output parameter.
  * Examples
  * of user-defined types include: {@code STRUCT}, {@code DISTINCT},
@@ -2717,7 +2717,7 @@
  * register the OUT Parameter.
  * If the parameter is of JDBC type {@code JDBCType.NUMERIC}
  * or {@code JDBCType.DECIMAL}, the version of
- * {@code  registrOutParameter} that accepts a scale value
+ * {@code  registerOutParameter} that accepts a scale value
  * should be used.
  * @exception SQLException if parameterName does not correspond to a named
  * parameter; if a database access error occurs or
@@ -2745,7 +2745,7 @@
  * parameter determines the Java type that must be used
  * in the {@code get} method to read the value of that parameter.
  * p
- * This version of {@code  registrOutParameter} should be
+ * This version of {@code  registerOutParameter} should be
  * used when the parameter is of JDBC type {@code JDBCType.NUMERIC}
  * or {@code JDBCType.DECIMAL}.
  *P
@@ -2774,7 +2774,7 @@
 
 /**
  * Registers the designated output parameter.  This version of
- * the method {@code  registrOutParameter}
+ * the method {@code  registerOutParameter}
  * should be used for a user-named or REF output parameter.  Examples
  * of user-named types include: STRUCT, DISTINCT, JAVA_OBJECT, and
  * named array types.


Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com