Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

On 8/10/14, 7:16 PM, David Holmes wrote: Hi Ioi, We seem to have lost core-libs-dev so I added them back. A couple of minor follow ups. On 9/08/2014 6:02 PM, Ioi Lam wrote: Hi, Thanks a lot to everyone for the very useful comments. I have updated the webrev Just the delta from the previous

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

On 8/11/2014 11:23 PM, David Holmes wrote: Hi Mandy, On 12/08/2014 9:01 AM, Mandy Chung wrote: On 8/11/14 2:15 PM, Ioi Lam wrote: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v3/ I would like to avoid adding private methods for VM to call as fewer as possible. SecureClassLoader.g

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

Hi Mandy, On 12/08/2014 9:01 AM, Mandy Chung wrote: On 8/11/14 2:15 PM, Ioi Lam wrote: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v3/ I would like to avoid adding private methods for VM to call as fewer as possible. SecureClassLoader.getProtectionDomain(URL) Can you use the e

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

On 8/11/14, 4:01 PM, Mandy Chung wrote: On 8/11/14 2:15 PM, Ioi Lam wrote: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v3/ I would like to avoid adding private methods for VM to call as fewer as possible. SecureClassLoader.getProtectionDomain(URL) Can you use the existing privat

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

On 8/11/14 2:15 PM, Ioi Lam wrote: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v3/ I would like to avoid adding private methods for VM to call as fewer as possible. SecureClassLoader.getProtectionDomain(URL) Can you use the existing private getProtectionDomain(CodeSource) meth

Re: JDK RFR of 8054720: Modifications of I/O methods for instrumentation purposes

On Aug 11, 2014, at 1:10 PM, Alan Bateman wrote: > This looks okay except SSLSocketImpl#isLayered (not clear why the override is > needed). This is needed as it may be required to instrument sun.security.ssl.SSLSocketImpl.closeSocket() in which the knowledge of whether the socket is layered

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

Hi David, thanks for the feedback. I will integrate your comments. Everyone, due to upcoming deadlines, we would like to push this change into jdk9/hs-rt by this Thursday. Please send additional comments, thumbs up/down by today if possible. Thanks! - Ioi On 8/10/14, 7:16 PM, David Holmes w

Re: JDK RFR of 8054720: Modifications of I/O methods for instrumentation purposes

On 11/08/2014 20:51, Brian Burkhalter wrote: JDK 9 reviewers: I would like to request the review of this patch to address the indicated issue: Issue: https://bugs.openjdk.java.net/browse/JDK-8054720 Patch: http://cr.openjdk.java.net/~bpb/8054720/ This changes passes the jdk_io and jdk_net te

Re: RFR JDK-8054857: Fix typos in java.lang.** packages

On 8/11/14 12:48 PM, Pavel Rappo wrote: Hi everyone, Could you please review my change for JDK-8054857? http://cr.openjdk.java.net/~prappo/8054857/webrev.00/ It's just a bunch of misspellings and typos in comments and javadoc. Thanks for fixing those. Looks okay to me. Mandy

Re: RFR JDK-8054857: Fix typos in java.lang.** packages

On 11/08/2014 20:48, Pavel Rappo wrote: Hi everyone, Could you please review my change for JDK-8054857? http://cr.openjdk.java.net/~prappo/8054857/webrev.00/ It's just a bunch of misspellings and typos in comments and javadoc. Looks good. -Alan.

JDK RFR of 8054720: Modifications of I/O methods for instrumentation purposes

JDK 9 reviewers: I would like to request the review of this patch to address the indicated issue: Issue: https://bugs.openjdk.java.net/browse/JDK-8054720 Patch: http://cr.openjdk.java.net/~bpb/8054720/ This changes passes the jdk_io and jdk_net tests on all platforms. Thanks, Brian

Re: RFR: JDK-8038861 [javadoc] broken links in org/omg/CORBA/FloatSeqHelper.html

On 11/08/2014 20:41, Mark Sheppard wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8038861/webrev/ which addresses the issue raised in https://bugs.openjdk.java.net/browse/JDK-8038861 HREFs in FloatSeqHelper.java java doc are incorrect, and fix c

RFR JDK-8054857: Fix typos in java.lang.** packages

Hi everyone, Could you please review my change for JDK-8054857? http://cr.openjdk.java.net/~prappo/8054857/webrev.00/ It's just a bunch of misspellings and typos in comments and javadoc. Thanks -Pavel

RFR: JDK-8038861 [javadoc] broken links in org/omg/CORBA/FloatSeqHelper.html

Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8038861/webrev/ which addresses the issue raised in https://bugs.openjdk.java.net/browse/JDK-8038861 HREFs in FloatSeqHelper.java java doc are incorrect, and fix changes cgi.omg.org to www.omg.org regard

Re: RFR [8054841] : (process) ProcessBuilder leaks native memory

Thanks Roger and Alan! I'll fix alignment before pushing. Sincerely yours, Ivan On 11.08.2014 22:14, Alan Bateman wrote: On 11/08/2014 18:14, Ivan Gerasimov wrote: Hello! There seems to be a small native memory leak in the ProcessBuilder's code. Would you please help review the trivial fi

Re: RFR [8054841] : (process) ProcessBuilder leaks native memory

On 11/08/2014 18:14, Ivan Gerasimov wrote: Hello! There seems to be a small native memory leak in the ProcessBuilder's code. Would you please help review the trivial fix for that? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8054841 WEBREV: http://cr.openjdk.java.net/~igerasim/8054841/0/

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

Hi David, On 08/10/2014 07:16 PM, David Holmes wrote: src/share/vm/runtime/arguments.cpp 3340 // This causes problems with CDS, which requires that all directories specified in the classpath 3341 // must be empty. Should that be "must not be empty"? Or did you mean directory names? That co

Re: RFR [8054841] : (process) ProcessBuilder leaks native memory

Hi Ivan, The fix looks fine. Roger On 8/11/2014 1:14 PM, Ivan Gerasimov wrote: Hello! There seems to be a small native memory leak in the ProcessBuilder's code. Would you please help review the trivial fix for that? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8054841 WEBREV: http://c

Re: Replace concat String to append in StringBuilder parameters

Sorry, I should've written this: Iterable whatever = ... StringJoiner joiner = new StringJoiner(", "); whatever.forEach(w -> joiner.add(w.toString())); String s = joiner.toString(); -Pavel On 11 Aug 2014, at 17:17, Pavel Rappo wrote: > Iterable wha

RFR [8054841] : (process) ProcessBuilder leaks native memory

Hello! There seems to be a small native memory leak in the ProcessBuilder's code. Would you please help review the trivial fix for that? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8054841 WEBREV: http://cr.openjdk.java.net/~igerasim/8054841/0/webrev/ Sincerely yours, Ivan

[8u40] RFR(M): 8050114, 8041972, 8006627

Hi, I want to request backports of 8050114 [1], 8041972 [2] and 8006627[3] to 8u-dev. The patches apply cleanly when pushed in the sequence listed. [1] Expose Integer/Long formatUnsigned methods internally - jdk9 patch appliescleanly to jdk8u-dev https://bugs.openjdk.java.net/browse/JDK-805011

Re: Replace concat String to append in StringBuilder parameters

Ulf, My point was simply that none of these classes provide methods that accept java.lang.Object. IMO, the scenario when we join elements into a String by calling toString on each element prior to append it -- is the most common scenario (maybe except for when element is a String itself). That

Re: Replace concat String to append in StringBuilder parameters

Am 11.08.2014 um 16:33 schrieb Pavel Rappo: Unfortunately, neither java.util.StringJoiner nor String.join have perfect (but who has?) APIs. So it's up to us to figure out the best way of joining elements. Maybe remember my thoughts from here: http://mail.openjdk.java.net/pipermail/core-libs-d

Re: RFR: 8054828: [TESTBUG] Typos in java/lang/Long/ParsingTest

On 08/11/2014 04:27 PM, Alan Bateman wrote: On 11/08/2014 15:21, Claes Redestad wrote: Thanks, Alan! I'll need someone to push this. Any takers? Okay, I can sponsor this for you. Great! Thanks again! /Claes -Alan.

Re: Replace concat String to append in StringBuilder parameters

Otavio, Just skimmed through your changes. It looks good. But there are some things we can make a little bit better though. IMO, it's not always a performance that matters (looking around to see if Alexey Shipilev is somewhere near) but readability. It's good to estimate performance requirement

Re: RFR: 8054828: [TESTBUG] Typos in java/lang/Long/ParsingTest

On 11/08/2014 15:21, Claes Redestad wrote: Thanks, Alan! I'll need someone to push this. Any takers? Okay, I can sponsor this for you. -Alan.

Re: RFR: 8054828: [TESTBUG] Typos in java/lang/Long/ParsingTest

On 08/11/2014 04:00 PM, Alan Bateman wrote: On 11/08/2014 14:52, Claes Redestad wrote: Hi, please review this small patch which resolves a number of typos where java/lang/Long/ParsingTest.java accidentally uses Integer.parseInt instead of Long.parseLong webrev: http://cr.openjdk.java.net/

Re: The future of Serialization

On 11/08/2014 13:06, Peter Firmstone wrote: Thanks Alan, I can relate to time poverty :) I might be assuming too much, but if there's interest in doing something with Serialization, I'd be interested in learning about plans or difficulties involved in deserialization and modules. It can be a

Re: Replace concat String to append in StringBuilder parameters

Am 11.08.2014 um 15:12 schrieb Andrej Golovnin: In the most classes I mentioned in my previous mail only the #toString()-methods would be affected by the proposal. And in the most cases, maybe in all cases, the #toString()-methods in this classes exists only to provide nice output. So why not

Re: RFR: 8054828: [TESTBUG] Typos in java/lang/Long/ParsingTest

On 11/08/2014 14:52, Claes Redestad wrote: Hi, please review this small patch which resolves a number of typos where java/lang/Long/ParsingTest.java accidentally uses Integer.parseInt instead of Long.parseLong webrev: http://cr.openjdk.java.net/~redestad/8054828/webrev.0/ bug: https://bug

Re: Replace concat String to append in StringBuilder parameters

Hi Otávio! A few days ago I've posted another cleanup request, which included modifications to src/share/classes/sun/net/www/MimeEntry.java http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028131.html As our changes overlap, one should be reverted back. I believe using StringJo

RFR: 8054828: [TESTBUG] Typos in java/lang/Long/ParsingTest

Hi, please review this small patch which resolves a number of typos where java/lang/Long/ParsingTest.java accidentally uses Integer.parseInt instead of Long.parseLong webrev: http://cr.openjdk.java.net/~redestad/8054828/webrev.0/ bug: https://bugs.openjdk.java.net/browse/JDK-8054828 Than

RFR [8046339] sun.rmi.transport.DGCAckHandler leaks memory

Hello everyone! It has been reported that under some conditions instances of sun.rmi.transport.DGCAckHandler accumulate and can cause OOM Error. This is because they are stored in the global DGCAckHandler.idTable map, and may fail to be removed if a timeout has expired. The webrev contains a

Re: Replace concat String to append in StringBuilder parameters

Hi, About readable of code I just renamed this class to sb instead of buf, > strbuf, etc. > I doubt that renaming variables does really improve the code readability. And you changed the indentation (take look at other classes too): 239 public String toString() { 240 StringBuilder s

Re: The future of Serialization

Thanks Alan, I can relate to time poverty :) I might be assuming too much, but if there's interest in doing something with Serialization, I'd be interested in learning about plans or difficulties involved in deserialization and modules. It can be a little more difficult to find the correct C

Re: Replace concat String to append in StringBuilder parameters

Hi Otávio, please ignore the previous diff. I'm sorry, there was a small mistake. I have attached the corrected version. Best regards, Andrej Golovnin On Mon, Aug 11, 2014 at 1:55 PM, Andrej Golovnin wrote: > Hi Otávio, > > About the template in Parser.jjt, TokenMgrError.java, etc. I don't k

Re: Replace concat String to append in StringBuilder parameters

Hi Otávio, About the template in Parser.jjt, TokenMgrError.java, etc. I don't know how > can do that. Can anyone help me? > See attached diff for the changes in Parser.jjt and Parser.jj. For the TokenMgrError and ParserException you can just subscribe here: https://java.net/projects/javacc/lists

Re: The future of Serialization

On 09/08/2014 06:56, Peter Firmstone wrote: I've noticed there's not much interest in improving Serialization on these lists. This makes me wonder if java Serialization has lost relevance in recent years with the rise of protocol buffers apache thrift and other means of data transfer over byt

Re: Replace concat String to append in StringBuilder parameters

> In the class > src/share/classes/javax/management/openmbean/CompositeType.java you have > added the > annotation @SuppressWarnings("StringConcatenationInsideStringBufferAppend") > instead of fixing the concatenation inside the append method. Why? +1 Moreover, I wonder where this value comes from

Re: The future of Serialization

On 11/08/2014 8:12 PM, Peter Firmstone wrote: Brian, Thanks for picking up on my frustration ;) I have something in mind for Serializable2 to address cyclic data structures and the possibility of independant evolution of super and child classes, while retaining a relatively clean public api,

Re: The future of Serialization

Brian, Thanks for picking up on my frustration ;) I have something in mind for Serializable2 to address cyclic data structures and the possibility of independant evolution of super and child classes, while retaining a relatively clean public api, with one optional private method. The methods

Re: Replace concat String to append in StringBuilder parameters

Hi Otávio, the class src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java is generated from the grammar src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.jjt src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.jj Therefore when you are going to change the Parser class, then you must change the grammar

Re: Replace concat String to append in StringBuilder parameters

'\"' can be written as '"': com_sun.diff:209:+sb.append(' ').append(nodeName).append("=\"").append(att.getNodeValue()).append('\"'); java_lang.diff:31:+ sb.append('\"').append(getThreadName()).append('\"') java_security.diff:78:+.append('\"'); s