Re: RFR 9: 8077350 Process API Updates Implementation Review

2015-04-13 Thread Martin Buchholz
On Sat, Apr 11, 2015 at 11:13 AM, Roger Riggs roger.ri...@oracle.com wrote: Hi Martin, Thanks for the review. On 4/11/2015 1:37 AM, Martin Buchholz wrote: Thanks for the huge effort. I did a superficial review and it seems pretty good. Of course, changing the Process good is high risk

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread huizhe wang
On 4/13/2015 4:42 AM, Alan Bateman wrote: On 13/04/2015 12:22, alexander stepanov wrote: Hello Joe, Thank you for the notes; Copyright year shall not be changed. That seems to be a bit controversial point; sometimes (while cleaning docs) I was asked to do that, other times - not to do

Re: RFR: 8077622: Add sources from jdk/src/jdk.deploy.osx/macosx/classes/ to unshuffle script

2015-04-13 Thread Chris Hegarty
On 13 Apr 2015, at 17:29, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Hi! Preparing a backport to 8, I found that some files aren't properly mapped from 9 to 8. Thank you for updating this list. The change looks good to me. -Chris. The following simple patch fixes the issue: ---

Re: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

2015-04-13 Thread John Rose
It's good. Nice cleanup. — John On Apr 13, 2015, at 10:39 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: John, David, thanks for the feedback! What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk

Re: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

2015-04-13 Thread Vladimir Ivanov
John, David, thanks for the feedback! What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/hotspot Best regards, Vladimir Ivanov On 4/10/15 10:15 PM, John Rose wrote: On Apr 9,

Re: RFR (S): 8076461: JSR292: remove unused native and constants

2015-04-13 Thread John Rose
That's much better; thanks. Glad to hear the verifyC's still works. The MN_* constants are a private interface between C++ and Java code. Those are the most important to verify. You can get rid of these lines; we don't look at vtable indexes any more: // The JVM uses values of -2 and

RFR 9: 8048264 : StringBuffer's codePoint methods throw unspecified IndexOutOfBoundsException

2015-04-13 Thread Brent Christian
Hello, Please review this small javadoc change. It was discovered that some codePoint-related methods in StringBuffer are missing documentation for throwing IndexOutOfBoundsException. The methods are: codePointAt(int) codePointBefore(int) codePointCount(int,int)

Re: RFR 9: 8048264 : StringBuffer's codePoint methods throw unspecified IndexOutOfBoundsException

2015-04-13 Thread Lance @ Oracle
Let me know and I will add myself as a reviewer 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 Sent from my iPad On Apr 13, 2015, at 6:55 PM, Brent Christian

Re: RFR 9: 8048264 : StringBuffer's codePoint methods throw unspecified IndexOutOfBoundsException

2015-04-13 Thread Brent Christian
Thanks, Lance. My next stop is the CCC. :) -Brent On 4/13/15 3:53 PM, Lance @ Oracle wrote: Hi Brent, This looks fine You might need to fast track a CCC request even though this is minor Best Lance http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of

Re: RFR 9: 8048264 : StringBuffer's codePoint methods throw unspecified IndexOutOfBoundsException

2015-04-13 Thread Lance @ Oracle
Hi Brent, This looks fine You might need to fast track a CCC request even though this is minor 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 Sent from my iPad On Apr

Re: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

2015-04-13 Thread David Holmes
On 14/04/2015 3:39 AM, Vladimir Ivanov wrote: John, David, thanks for the feedback! What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/hotspot Looks good - thanks. David Best

Re: RFR 9: 8048264 : StringBuffer's codePoint methods throw unspecified IndexOutOfBoundsException

2015-04-13 Thread David Holmes
On 14/04/2015 8:49 AM, Brent Christian wrote: Hello, Please review this small javadoc change. It was discovered that some codePoint-related methods in StringBuffer are missing documentation for throwing IndexOutOfBoundsException. The methods are: codePointAt(int) codePointBefore(int)

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread alexander stepanov
Thanks! On 10.04.2015 20:07, Sean Mullan wrote: On 04/10/2015 12:01 PM, Alan Bateman wrote: On 10/04/2015 16:50, alexander stepanov wrote: Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8077332/ for https://bugs.openjdk.java.net/browse/JDK-8077332

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread Alan Bateman
On 13/04/2015 12:22, alexander stepanov wrote: Hello Joe, Thank you for the notes; Copyright year shall not be changed. That seems to be a bit controversial point; sometimes (while cleaning docs) I was asked to do that, other times - not to do that. Our internal policy seemingly assigns to

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread alexander stepanov
Hello Joe, Thank you for the notes; Copyright year shall not be changed. That seems to be a bit controversial point; sometimes (while cleaning docs) I was asked to do that, other times - not to do that. Our internal policy seemingly assigns to change the 2nd date every time the sources

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread alexander stepanov
Hello Alan, Thank you. Regards, Alexander On 10.04.2015 19:01, Alan Bateman wrote: On 10/04/2015 16:50, alexander stepanov wrote: Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8077332/ for https://bugs.openjdk.java.net/browse/JDK-8077332 Some HTML

Re: RFR: 8076549: Update JAX-WS RI integration to latest version (2.2.11-b150402.1412)

2015-04-13 Thread Otávio Gonçalves de Santana
One Question: Look to these classes: MIMEPart MIMEMessage why do not implement AutoClosable instead Closable? Other suggestions: On class MIMEMessage, you can use diamond resource. private final ListMIMEPart partsList = new ArrayList(); private final MapString, MIMEPart partsMap = new

Re: RFR: 8076549: Update JAX-WS RI integration to latest version (2.2.11-b150402.1412)

2015-04-13 Thread Aleksej Efimov
Hi Otávio, Thank you for your remarks. Answers are in-lined below. In general - standalone JAXWS/B still compatible with JDK6. Thank you, Aleksej On 04/13/2015 01:52 PM, Otávio Gonçalves de Santana wrote: One Question: Look to these classes: MIMEPart MIMEMessage why do not implement

Re: RFR: 8076549: Update JAX-WS RI integration to latest version (2.2.11-b150402.1412)

2015-04-13 Thread Alan Bateman
On 13/04/2015 14:08, Aleksej Efimov wrote: Hi Otávio, Thank you for your remarks. Answers are in-lined below. In general - standalone JAXWS/B still compatible with JDK6. Can you double check this that this policy is continuing for JDK 9? That is, the upstream projects want to compile for 6,

RFR: 8077622: Add sources from jdk/src/jdk.deploy.osx/macosx/classes/ to unshuffle script

2015-04-13 Thread Ivan Gerasimov
Hi! Preparing a backport to 8, I found that some files aren't properly mapped from 9 to 8. The following simple patch fixes the issue: --- a/common/bin/unshuffle_list.txt +++ b/common/bin/unshuffle_list.txt @@ -1294,6 +1294,9 @@ jdk/src/jdk.crypto.pkcs11/windows/native/libj2pkcs11/p11_md.c :

Re: RFR (XXS) : 8050123: Incorrect property name documented in CORBA InputStream API

2015-04-13 Thread Seán Coffey
JDK-8077395 tracking this request now. Thanks for logging bug Alan. Regards, Sean. On 10/04/15 08:03, Alan Bateman wrote: This is JDK-specific and so shouldn't be in the constructor specification. Can it be moved to an @implNote?