Re: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames

On 11/03/2014 09:41 PM, David Chase wrote: On 2014-11-03, at 3:09 PM, Peter Levart wrote: Hi David, I was thinking about the fact that java.lang.invoke code is leaking into java.lang.Class. Perhaps, If you don't mind rewriting the code, a better code structure would be, if j.l.Class changes

Re: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames

On 2014-11-04, at 5:07 AM, Peter Levart wrote: > Are you thinking of an IdentityHashMap type of hash table (no linked-list of > elements for same bucket, just search for 1st free slot on insert)? The > problem would be how to pre-size the array. Count declared members? It can’t be an identityH

Re: RFR (JAXP) 6770436 : Entity callback order differs between Java1.5 and Java1.6

Hi Joe, looks OK. Best Lance On Nov 3, 2014, at 4:09 PM, huizhe wang wrote: > Hi, > > The order of the Character event for a built-in entity reference was wrong > after the integration of StAX in JDK 6. The error was introduced when all > Character event was moved to the scanDocument method.

Re: RFR: 8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed

Hi, Here is a revised patch that introduces a new .handlers.ensureCloseOnReset=true|false property. This property can be used as a fallback to turn the new behavior off in the improbable case where an application may need to do so. I have updated the LogManager class-level API documentation. ht

Re: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames

On 11/04/2014 04:19 PM, David Chase wrote: On 2014-11-04, at 5:07 AM, Peter Levart wrote: Are you thinking of an IdentityHashMap type of hash table (no linked-list of elements for same bucket, just search for 1st free slot on insert)? The problem would be how to pre-size the array. Count decl

Re: RFR (JAXP) 6770436 : Entity callback order differs between Java1.5 and Java1.6

Thanks Lance! Joe On 11/4/2014 7:39 AM, Lance Andersen wrote: Hi Joe, looks OK. Best Lance On Nov 3, 2014, at 4:09 PM, huizhe wang > wrote: Hi, The order of the Character event for a built-in entity reference was wrong after the integration of StAX in JDK 6

Re: RFR: 8062773: Clarifications for Class specification

[+core-libs-dev] I'm sorry I keep forgetting to add the mailing list to my review requests. I blame google's code review mail tool, which cc's the right mailing lists automagically. Webrev updated to add a few more "direct"s, as suggested by Paul. https://bugs.openjdk.java.net/browse/JDK-806277

RFR JDK-8062759: Update test/javax/naming/spi/providers/InitialContextTest.java to use classpath

Hi everyone, Could you please review my change for JDK-8062759? http://cr.openjdk.java.net/~prappo/8062759/webrev.00/ P.S. The actual change is located at lines [215, 219]. Everything else is just a minor refactoring. P.P.S. I de

Re: RFR: 8062771: Core reflection should use final fields whenever possible

[+core-libs-dev, Alexey] On Tue, Nov 4, 2014 at 2:13 AM, Paul Sandoz wrote: > Hi Martin, > > Should this and the other review also be posted on core-libs? (sorry for forgetting the mailing list) > On Nov 3, 2014, at 11:18 PM, Martin Buchholz wrote: > >> Hi Joe, Paul, >> >> I'd like you to do

Re: RFR: 8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed

Hi, 917 final boolean ensureCloseOnReset = names.length == 0 ? false 918 : getBooleanProperty(handlersPropertyName + ".ensureCloseOnReset", 919 names.length > 0); I think the statement would be a lot easier to read as: fin

Re: RFR: 8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed

On 04/11/14 18:54, Stanimir Simeonoff wrote: Hi, 917 final boolean ensureCloseOnReset = names.length == 0 ? false 918 : getBooleanProperty(handlersPropertyName + ".ensureCloseOnReset", 919 names.length > 0); I think

Please Review Draft JEP: More memory-efficient internal representation for Strings

Hi, Please review this draft JEP for: "More memory-efficient internal representation for Strings" https://bugs.openjdk.java.net/browse/JDK-8054307 Thanks, Brent

Re: Please Review Draft JEP: More memory-efficient internal representation for Strings

As far as it goes, it looks good to me. I do note that so far it has no mention of the academic literature that has already explored this or related problems, and I hope that part of the activity would be to survey and summarize this literature before making implementation decisions. —Guy On Nov

Re: RFR: 8062771: Core reflection should use final fields whenever possible

On 04.11.2014 20:53, Martin Buchholz wrote: > On Tue, Nov 4, 2014 at 2:13 AM, Paul Sandoz wrote: >> On Nov 3, 2014, at 11:18 PM, Martin Buchholz wrote: >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/reflection-final-fields/ >>> https://bugs.openjdk.java.net/browse/JDK-8062771 Looks good

sun.nio.cs.StreamDecoder readBytes() possible issue

Javadoc for java.io.InputStream.read(byte[] b, int off , int len) says: "Reads up to len bytes of data from the input stream into an array of bytes. An attempt is made to read as many as len bytes, but a smaller number may be read. The number of bytes actually read is returned as an integer." So m

Re: RFR: 8062771: Core reflection should use final fields whenever possible

Hi Aleksey, On Tue, Nov 4, 2014 at 11:55 AM, Aleksey Shipilev wrote: > On 04.11.2014 20:53, Martin Buchholz wrote: >> On Tue, Nov 4, 2014 at 2:13 AM, Paul Sandoz wrote: >>> On Nov 3, 2014, at 11:18 PM, Martin Buchholz wrote: > If you do this: > >> // Generic info repository; lazily initial

Re: sun.nio.cs.StreamDecoder readBytes() possible issue

There's more detail in the InputStream.read javadoc, specifically (emphasis mine): This method blocks until input data is available, end of file is detected, > or an exception is thrown. > > If len is zero, then no bytes are read and 0 is returned; *otherwise, > there is an attempt to read at le

Re: RFR: 8062771: Core reflection should use final fields whenever possible

Hi Martin, On 04.11.2014 23:11, Martin Buchholz wrote: > On Tue, Nov 4, 2014 at 11:55 AM, Aleksey Shipilev > wrote: >> On 04.11.2014 20:53, Martin Buchholz wrote: >>> On Tue, Nov 4, 2014 at 2:13 AM, Paul Sandoz wrote: On Nov 3, 2014, at 11:18 PM, Martin Buchholz wrote: >> If you do this: >

Re: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames

I’m working on the initial benchmarking, and so far this arrangement (with synchronization and binary search for lookup, lots of barriers and linear cost insertion) has not yet been any slower. I am nonetheless tempted by the 2-tables solution, because I think the simpler JVM-side interface tha

RFR 8062180: MethodHandleImpl.makeArrays throws and swallows java.lang.NoSuchFieldError in normal flow

Hi, please review this minor improvement to the initialization of MethodHandleImpl$Lazy. Running any code which initializes MethodHandlesImpl$Lazy will trigger throwing of java.lang.NoSuchFieldErrors, which has a measurable impact on startup. Additionally, the current lookup via findCollecto

Re: RFR 8062180: MethodHandleImpl.makeArrays throws and swallows java.lang.NoSuchFieldError in normal flow

Hi Claes, On 04.11.2014 23:57, Claes Redestad wrote: > please review this minor improvement to the initialization of > MethodHandleImpl$Lazy. Running any code which initializes > MethodHandlesImpl$Lazy will trigger throwing of > java.lang.NoSuchFieldErrors, which has a measurable impact on startup

Re: RFR JDK-8062759: Update test/javax/naming/spi/providers/InitialContextTest.java to use classpath

Hi Pavel, On 11/4/14 9:10 AM, Pavel Rappo wrote: Hi everyone, Could you please review my change for JDK-8062759? http://cr.openjdk.java.net/~prappo/8062759/webrev.00/ This looks okay to me. Mandy

Re: RFR: 8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed

On 11/4/14 8:48 AM, Daniel Fuchs wrote: Hi, Here is a revised patch that introduces a new .handlers.ensureCloseOnReset=true|false property. You have explored several different options and as you have found, none of them is ideal. I think having a property to specify ensureCloseOnReset would b

Re: RFR: 8062194: java.util.jar.Attributes should use insertion-ordered iteration

On Tue, Oct 28, 2014 at 12:52 PM, Alan Bateman wrote: > On 28/10/2014 18:09, Martin Buchholz wrote: >> >> Xueming, I understand that getting CCC approval is a fair amount of >> work. At your option, we could leave the spec unchanged and do >> without CCC, given that Attributes' iteration order ha

Re: RFR: 8062773: Clarifications for Class specification

Hi Martin, This description in getGenericInterfaces 876 * If this object represents a class, the return value is an 877 * array containing objects representing all interfaces 878 * implemented by the class. The order of the interface objects in could also be direct-ized. In