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

On Friday 03 May 2013 11:53 AM, Tim Bell wrote: On 05/ 2/13 01:24 PM, I wrote: Hi Sundar: Oracle JDK includes Rhino based javax.script implementation (which lives mostly in "closed" code). Rhino is being removed from Oracle JDK builds and there are the changes to the jdk open repository as w

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

On 05/ 2/13 01:24 PM, I wrote: Hi Sundar: Oracle JDK includes Rhino based javax.script implementation (which lives mostly in "closed" code). Rhino is being removed from Oracle JDK builds and there are the changes to the jdk open repository as well like com.sun.script.javascript package, makef

hg: jdk8/tl/jdk: 7199324: Connection ID for IPv6 addresses is not generated accordingly to the specification

Changeset: 470f19b6bfdd Author:jbachorik Date: 2013-05-02 13:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/470f19b6bfdd 7199324: Connection ID for IPv6 addresses is not generated accordingly to the specification Summary: RemoteServer.getClientHost is returning a String w

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

Hi, Please help review the proposed fix for 8012326. The direct trigger is the fix we put in #6898310 [1], in which we added the synchronization to prevent a possible race condition as described in $4685305. However it appears the added synchronization triggers another race condition as sho

hg: jdk8/tl/jdk: 8013855: DigestMD5Client has not checked RealmChoiceCallback value

Changeset: 81be41c7323f Author:weijun Date: 2013-05-03 10:43 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81be41c7323f 8013855: DigestMD5Client has not checked RealmChoiceCallback value Reviewed-by: xuelei, mullan ! src/share/classes/com/sun/security/sasl/digest/DigestMD5C

Re: Review Request: BigInteger patch for efficient multiplication and division (#4837946)

On May 2, 2013, at 5:02 AM, Alan Bateman wrote: > On 02/05/2013 02:34, Tim Buktu wrote: >> : >> >> Alan is working on an improved BigInteger.toString() that should be >> dramatically faster for large numbers. What's the deadline for getting >> this in? >> Thanks, >> >> Tim > Here's the latest mi

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

Hi All, Thanks for all your comments. Based on the previous feedback, I have moved to the other approach, i.e., to fail file operations if the invalid NUL characher is found in a file path. As you know, due to the compatibility issue, we cannot throw an exception immediately in the File const

hg: jdk8/tl/jdk: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name

Changeset: 3062bf908281 Author:khazra Date: 2013-05-02 14:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3062bf908281 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name Summary: Remove buffer overruns in native code Reviewed-by: alanb, che

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

Hi Sundar: Oracle JDK includes Rhino based javax.script implementation (which lives mostly in "closed" code). Rhino is being removed from Oracle JDK builds and there are the changes to the jdk open repository as well like com.sun.script.javascript package, makefiles etc. Please review the ope

Re: RFR : 7178639 : (XXS) Remove incorrect documentation from Deque.push(E e)

My proposed changes are now in JSR166 CVS. Syncing work is needed before jdk8 ships!

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

As a followup to this issue it's been pointed out that I pushed this patch with source-level set to "1.8" which is not supported by Netbeans 7.2 or 7.3. Source 1.8 is supported by the development version of Netbeans which is what I use primarily. There's a problem here: - The JDK repo now cont

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

On 04/30/2013 04:57 PM, Thomas Schatzl wrote: Hi all, the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/ presents a first stab at the CR "7038914: VM could throw uncaught OOME in ReferenceHandler thread". The problem is that under very heavy memory pressure, there is the ref

Re: RFR: 7150256/8004095: Add back Remote Diagnostic Commands

Karen, Thank you for the review. 1. 2. and 3. have been fixed. Regarding 4. Most (all?) permissions have a name argument. However, if p._name is null, the string "(null)" is printed. This is not wrong, but not very pretty: Permission: MyPermission((null)). I've changed the code (both 105 and

Re: RFR: JDK-8013736: [launcher] cleanup code for correctness

Oops. Of course, that shouldn't have the trailing semicolon #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ ncor_failure_return_value) \ do { \ if ((ncor_pointer_to_check) == NULL) { \

Re: RFR: JDK-8013736: [launcher] cleanup code for correctness

What would Martin actually do? #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ ncor_failure_return_value) \ do { \ if ((ncor_pointer_to_check) == NULL) { \ JLI_ReportErrorMessage(JNI_ER

Re: RFR: JDK-8013736: [launcher] cleanup code for correctness

On 5/2/2013 10:17 AM, Martin Buchholz wrote: This is global fix creep, but ... :( these macros are also found in the hotspot sources. I would rewrite all the macros in the jdk to adopt the blessed style do { ... } while(0) and remove all comments in the jdk of the form /* next token must be

Re: RFR: JDK-8013736: [launcher] cleanup code for correctness

This is global fix creep, but ... these macros are also found in the hotspot sources. I would rewrite all the macros in the jdk to adopt the blessed style do { ... } while(0) and remove all comments in the jdk of the form /* next token must be ; */ If you want a macro that does nothing at all, yo

Re: RFR: JDK-8013736: [launcher] cleanup code for correctness

I would also be inclined to change == 0 to == NULL This seems like another occasion to use the weird do { ... } while(0) trick to make the macro behave more like a statement. I might obfuscate the macro parameters to make collisions less likely, e.g. e => N_C_RV_e On Wed, May 1, 2013 at 12:

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

On 02/05/2013 17:41, A. Sundararajan wrote: Hi, Oracle JDK includes Rhino based javax.script implementation (which lives mostly in "closed" code). Rhino is being removed from Oracle JDK builds and there are the changes to the jdk open repository as well like com.sun.script.javascript package,

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

Hi, Oracle JDK includes Rhino based javax.script implementation (which lives mostly in "closed" code). Rhino is being removed from Oracle JDK builds and there are the changes to the jdk open repository as well like com.sun.script.javascript package, makefiles etc. Please review the open jdk c

Re: RFR: 7150256/8004095: Add back Remote Diagnostic Commands

Frederic, Code looks good - actually it looks very clean. Ship it. Couple of minor comments that don't require re-review: 1. nmtDCmd.hpp/cpp - copyrights 2012 -> 2012, 2013 2. jmm.h line 213: "True is" -> "True if" 3. diagnosticFramework.hpp Thank you for the comments! line 298 "rational

Re: RFEs implementing JEP 170

Yes I am away right now but will follow up when I am back mid next week 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 May 2, 2013, at 11:45 AM, Alan Ba

hg: jdk8/tl/jdk: 8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile

Changeset: 5045eb04a579 Author:mduigou Date: 2013-05-02 09:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5045eb04a579 8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile Reviewed-by: mduigou, henryjen, alanb, martin, psandoz Contributed-by: akhil.ar...@o

Re: RFR: JDK-8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently

Hi, Please find an updated webrev below: Changes are: catch IAE are removed - as suggested by Alan. I didn't find traces of IAE being thrown by OutputStreamWriter constructor in recent JDK - so I think it's safe to remove those catch c

Re: RFR JDK-8003258(2nd round): BufferedReader.lines()

On 05/02/2013 05:08 AM, Alan Bateman wrote: > On 02/05/2013 07:49, Henry Jen wrote: >> Hi, >> >> Take feedbacks from previous round, the javadoc is updated >> >> http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/webrev/ >> http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/specdiff/ >> > This look

Re: RFR: JDK-8006884: (fs) Add Files.list, lines and find

On May 2, 2013, at 8:52 AM, Henry Jen wrote: > > On May 2, 2013, at 8:22 AM, Alan Bateman wrote: > >> On 02/05/2013 07:52, Henry Jen wrote: >>> Hi, >>> >>> Please review a couple stream access API proposed for >>> java.nio.file.Files and java.nio.file.DirectoryStream, >>> >>> http://cr.open

Re: RFR: JDK-8006884: (fs) Add Files.list, lines and find

On May 2, 2013, at 8:22 AM, Alan Bateman wrote: > On 02/05/2013 07:52, Henry Jen wrote: >> Hi, >> >> Please review a couple stream access API proposed for >> java.nio.file.Files and java.nio.file.DirectoryStream, >> >> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/webrev/ >> http://cr.ope

Re: RFEs implementing JEP 170

On 02/05/2013 12:13, Neil Richards wrote: : 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. I'm sure Lance will add the links but in the mean-time then "hg log src/share/classes/

Re: RFR: JDK-8006884: (fs) Add Files.list, lines and find

On 02/05/2013 07:52, Henry Jen wrote: Hi, Please review a couple stream access API proposed for java.nio.file.Files and java.nio.file.DirectoryStream, http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/webrev/ http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/specdiff/ Cheers, Henry One corne

Re: RFR: 8013155: [pack200] improve performance of pack200

Looks good. Kumar Kumar, On 4/30/13 22:32, Kumar Srinivasan wrote: Couple of nits: I don't think you need the parens j = (nextsemi < nextangl ? nextsemi : nextangl); Here i tend to agree with John - the condition being a superposition of two really closely named variables might look confusi

Re: RFR: 8013155: [pack200] improve performance of pack200

Kumar, On 4/30/13 22:32, Kumar Srinivasan wrote: Couple of nits: I don't think you need the parens j = (nextsemi < nextangl ? nextsemi : nextangl); Here i tend to agree with John - the condition being a superposition of two really closely named variables might look confusing and since the worl

hg: jdk8/tl/jdk: 8013225: Refresh jdk's private ASM to the latest.

Changeset: 167d2dca Author:ksrini Date: 2013-05-01 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/167d2dca 8013225: Refresh jdk's private ASM to the latest. Reviewed-by: mduigou, sundar ! src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java !

Re: RFR: JDK-8013736: [launcher] cleanup code for correctness

On 01/05/2013 20:33, Kumar Srinivasan wrote: Hi, Please review simple fixes for code correctness in the launcher. http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ Thanks Kumar This looks okay to me although I wonder why the NULL_CHECK macros check for 0 rather than NULL. I don't know if

Re: RFR JDK-8003258(2nd round): BufferedReader.lines()

On 02/05/2013 07:49, Henry Jen wrote: Hi, Take feedbacks from previous round, the javadoc is updated http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/webrev/ http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/specdiff/ This looks good to me except for the last two sentences of the final par

Re: Review Request: BigInteger patch for efficient multiplication and division (#4837946)

On 02/05/2013 02:34, Tim Buktu wrote: : Alan is working on an improved BigInteger.toString() that should be dramatically faster for large numbers. What's the deadline for getting this in? Thanks, Tim Here's the latest milestone dates: http://openjdk.java.net/projects/jdk8/milestones Given th

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

Hi, On Tue, 2013-04-30 at 16:44 +0100, Alan Bateman wrote: > On 30/04/2013 15:57, Thomas Schatzl wrote: > > Hi all, > > > >the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/ > > presents a first stab at the CR "7038914: VM could throw uncaught OOME > > in ReferenceHandler thre

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

Hello. nonNull could be renamed into isNonNull, else people might use it instead of requireNonNull, especially if they are already used to a pre-Java 7 requireNonNull that would be called nonNull. (example: http://grokbase.com/p/openjdk/core-libs-dev/111tbha823/code-review-7012540-java-util-objec

RFEs implementing JEP 170

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]). Unlike most JEPs, the entry for 170 does not seem to hold references to these ids (only to the affected JSRs). Searching the m

Re: RFEs implementing JEP 170

Oops, messed up my reply-to address. (I blame my newly upgraded system). Hopefully this should be better. Regards, Neil On Thu, 2013-05-02 at 12:02 +0100, 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

Re: RFR: 8012665: CharSequence.chars, CharSequence.codePoints

Thanks for your opinion, Paul. Looking into the existing sources, violation of the 80 character limit seems widely accepted, so to me it seems reasonable to continue this style in appropriate cases. But I rarely see good reasons to violate the 8-spaces indentation rule for continuation lines.