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:
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
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).
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
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
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
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
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
---
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
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:
> >
> >
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
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
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
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.
> 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.
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:
> >
>
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?
>
>
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
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
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
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
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
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
23 matches
Mail list logo