Re: Proposal: java.lang.reflect.Proxy and default methods

2017-03-02 Thread Remi Forax
Alan, i think we should update the doc section of j.l.r.Proxy to add a sentence about default methods ? Rémi - Mail original - > De: "Alan Bateman" > À: "mp911de" , core-libs-dev@openjdk.java.net > Envoyé: Jeudi 2 Mars 2017 09:28:35 > Objet:

Re: RFR JDK-8176029: Linebreak matcher is not equivalent to the pattern as stated in javadoc

2017-03-02 Thread Xueming Shen
On 3/2/17, 6:56 PM, Xueming Shen wrote: Hi, Please help review the change for JDK-8176029 issue: https://bugs.openjdk.java.net/browse/JDK-8176029 webrev: http://cr.openjdk.java.net/~sherman/8176029/webrev It appears the API doc for \R is correct, instead the implementation is buggy when

RFR JDK-8176029: Linebreak matcher is not equivalent to the pattern as stated in javadoc

2017-03-02 Thread Xueming Shen
Hi, Please help review the change for JDK-8176029 issue: https://bugs.openjdk.java.net/browse/JDK-8176029 webrev: http://cr.openjdk.java.net/~sherman/8176029/webrev It appears the API doc for \R is correct, instead the implementation is buggy when dealing with sequence "\r\n" (u+000du+000a).

Re: RFR: 8176044: (tz) Support tzdata2017a

2017-03-02 Thread Naoto Sato
Looks fine. Thanks, Ramanand. Naoto On 3/2/17 4:45 AM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA integration (tzdata2017a) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/ All the TimeZone related

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Ulf Zibis
Am 02.03.2017 um 18:16 schrieb Vitaly Davidovich: When the optimization applies, there shouldn't be *any* instructions for the null check on the path - it's done via signal handling. Thanks for clarification. This is Sufficiently Smart Compiler territory. It's much better to hand-code this

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Vitaly Davidovich
On Thu, Mar 2, 2017 at 11:42 AM, Ulf Zibis wrote: > > Am 02.03.2017 um 14:55 schrieb Vitaly Davidovich: > >> Implicit null checks ... generally don't cost anything. >> > Any additional byte of code in CPU cache prevents other code from staying > there. When the optimization

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Ulf Zibis
Am 02.03.2017 um 14:55 schrieb Vitaly Davidovich: Implicit null checks ... generally don't cost anything. Any additional byte of code in CPU cache prevents other code from staying there. I can't imagine, if any programmer would rely on such contract, instead of doing the check

RE: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Christoph Dreis
Hey Vitaly, Thanks for clearing the way. As all things seem to be clarified now, is there someone who is willing to sponsor the patch? Cheers, Christoph == PATCH == diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.jav ---

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Jonathan Bluett-Duncan
Hi Vitaly, > If there's no early bail out, there's an implicit null check when > replacement.toString() is called... Oh apologies! I had missed in the code that NPE does get thrown if `replacement` is null, no matter if the `if (j < 0) { ... }` block is entered or not, because

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Vitaly Davidovich
On Thu, Mar 2, 2017 at 8:32 AM Ulf Zibis wrote: > HI, > > first sorry for missing the class wide definition. > > Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich: > > > > On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis > wrote: > > > >

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Vitaly Davidovich
On Thu, Mar 2, 2017 at 8:26 AM, Jonathan Bluett-Duncan < jbluettdun...@gmail.com> wrote: > Hi Christoph and Vitaly, > > I am struggling to understand why the null-check for `replacement` has > been moved within the `if (j < 0) { ... }` block. Could one of you explain > to me the reasoning behind

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Ulf Zibis
HI, first sorry for missing the class wide definition. Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich: On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis > wrote: In any case, what's the reasonable of checking an argument, which is not used in

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Jonathan Bluett-Duncan
Hi Christoph and Vitaly, I am struggling to understand why the null-check for `replacement` has been moved within the `if (j < 0) { ... }` block. Could one of you explain to me the reasoning behind this change? I ask because, AFAICT, making it so that it only throws an NPE if `replacement` is

RFR: 8176044: (tz) Support tzdata2017a

2017-03-02 Thread Ramanand Patil
Hi all, Please review the latest TZDATA integration (tzdata2017a) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

Re: [9] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine

2017-03-02 Thread Paul Sandoz
> On 2 Mar 2017, at 11:35, Claes Redestad wrote: > > Hi, > > as this now significantly helps with one of our startup regression, and > the change is very low risk, I've retargetted to 9. Any objections? > No objections, +1 for 9. Paul.

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Vitaly Davidovich
On Thu, Mar 2, 2017 at 6:45 AM Claes Redestad wrote: > On 03/02/2017 11:38 AM, Ulf Zibis wrote: > > Hi Vitaly, > > > > I don't see any contract to throw an NPE: > > >

RE: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Christoph Dreis
Hey Ulf, > Hi Vitaly, > > I don't see any contract to throw an NPE: > https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace- > java.lang.CharSequence-java.lang.CharSequence- > > In any case, what's the reasonable of checking an argument, which is not > used in that case? > >

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Vitaly Davidovich
On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis wrote: > Hi Vitaly, > > I don't see any contract to throw an NPE: > > https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- Hmm, I must've looked at java 7 docs, which

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Claes Redestad
On 03/02/2017 11:38 AM, Ulf Zibis wrote: Hi Vitaly, I don't see any contract to throw an NPE: https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- "Unless otherwise noted, passing anullargument to a constructor or method in

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

2017-03-02 Thread Ulf Zibis
Hi Vitaly, I don't see any contract to throw an NPE: https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- In any case, what's the reasonable of checking an argument, which is not used in that case? Am 02.03.2017 um 00:18

Re: [9] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine

2017-03-02 Thread Claes Redestad
Hi, as this now significantly helps with one of our startup regression, and the change is very low risk, I've retargetted to 9. Any objections? /Claes On 03/01/2017 05:17 PM, Aleksey Shipilev wrote: On 03/01/2017 06:11 PM, Claes Redestad wrote: Sure, with a bit of fix-up this drops another

Re: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine

2017-03-02 Thread John Rose
On Mar 1, 2017, at 5:11 PM, Claes Redestad wrote: > > It seems javac optimizes byte-char comparisons pretty well This happened because of the JVM's bytecode ISA, which requires that javac must "erase" all integer subrange types (boolean, char, byte, short) internally

Re: Proposal: java.lang.reflect.Proxy and default methods

2017-03-02 Thread Alan Bateman
On 01/03/2017 21:14, mp911de wrote: Is there any progress on this issue? In the light of Java 9, the workaround with MethodHandles.lookup()/unreflectSpecial does not work anymore because MethodHandles is encapsulated and calling setAccessible(true) on the constructor fails. Resolving method