> On 12 Oct 2015, at 09:47, Andrej Golovnin wrote:
>
> Hi Paul,
>
> wouldn't it be better to use Objects#equals(Object, Object) in the
> line 3293 in the Arrays class instead of the ternary operator (the
> same applies to the line 3238)?
>
Thanks updated both the
>
> “Optional.or” is the best name so far i have come up with. The “orElse”
> prefix is reversed for terminal methods and i don’t want to overload that.
>
> --
>
> Alternative suggestions:
>
> - “Optional.otherwise”
> A bit of a mouthful, but reasonably accurate
>
> - “Optional.mapElse"
> The
> On 22 Sep 2015, at 18:30, Paul Sandoz wrote:
>
> Hi,
>
> Please review the following which adds methods to Arrays for performing
> equality, comparison and mismatch:
>
> https://bugs.openjdk.java.net/browse/JDK-8033148
>
>
> On 25 Sep 2015, at 12:58, Paul Sandoz wrote:
>
> Hi,
>
> Please review this change to add a method Optional.or that allows one to
> better compose optionals:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/
>
> I also took the
Hi Paul,
wouldn't it be better to use Objects#equals(Object, Object) in the
line 3293 in the Arrays class instead of the ternary operator (the
same applies to the line 3238)?
Best regards,
Andrej Golovnin
On Mon, Oct 12, 2015 at 9:31 AM, Paul Sandoz wrote:
>
>> On 22
Looks ok to me Amy.
-Chris.
On 12/10/15 09:27, Amy Lu wrote:
Test java/rmi/registry/readTest/readTest.sh is known to fail
intermittently, this patch is to mark the test accordingly with keyword
'intermittent'.
bug: https://bugs.openjdk.java.net/browse/JDK-8139407
webrev:
Hello!
If my opinion matters, I'm perfectly fine with Optional.or name, no
need to change.
With best regards,
Tagir Valeev.
>> On 25 Sep 2015, at 12:58, Paul Sandoz wrote:
>>
>> Hi,
>>
>> Please review this change to add a method Optional.or that allows one to
>>
On 10/12/2015 05:56 PM, Alan Bateman wrote:
On 12/10/2015 16:09, Vyom Tewari wrote:
Hi All,
Please review my changes for below bug.
Bug:JDK-8068887 : java.lang.Throwable could use
Collections.emptyList for suppressedException
Webrev:
On 12/10/2015 17:20, Aleksey Shipilev wrote:
:
No, of course not :) The mere fact a collection is empty when the
unmodifiable view is acquired does not mean somebody who can access the
collection via the "modifiable" reference would not update it ;)
Of course :-)
It seems you suggest to hide this feature "à la" Unsafe to avoid exposing a
new Java SE API. But the move is quite the opposite right now where all
Unsafe "features" will find an exit to a public reliable API which is good
and low latency and performance people is waiting for. JVM already uses the
+1 as well :)
BR,
Haim Yadid
> On 8 באוק׳ 2015, at 17:56, Doug Lea wrote:
>
>> On 10/08/2015 07:01 AM, David M. Lloyd wrote:
>>> On 10/08/2015 05:58 AM, Doug Lea wrote:
>>>
>>> class Thread { //
>>> /**
>>>* A hint to the platform that the current thread is
Hi Thomas,
the change looks good. Thanks for fixing this.
Best regards,
Goetz.
From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-boun...@openjdk.java.net] On
Behalf Of Thomas Stüfe
Sent: Mittwoch, 7. Oktober 2015 16:28
To: Java Core Libs; ppc-aix-port-...@openjdk.java.net
Subject: RFR(xxs):
Hello,
Please review the next step of porting fdlibm to Java, the cbrt method:
JDK-8136799 Port fdlibm cbrt to Java
http://cr.openjdk.java.net/~darcy/8136799.3/
A few points of note about the port, there is a transliteration port in
the test area for comparison purposes. I also ran these
On 10/12/2015 06:56 PM, Alan Bateman wrote:
> On 12/10/2015 16:09, Vyom Tewari wrote:
>> Bug:JDK-8068887 : java.lang.Throwable could use
>> Collections.emptyList for suppressedException
>> Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/
+1
> (Your patch makes me
>
> Hi Gil,
>
> Glad to see this being addressed!
>
Me too, this would be a useful addition to the Disruptor.
On 10/04/2015 07:22 PM, Gil Tene wrote:
> > We propose to add a method to the JDK which would be hint that a spin
> > loop is being performed. E.g.
> >
It might be intentional or a copy+paste thing, the javadoc of FOREVER
reads:
"... The estimated duration of the era is artificially defined as the
largest duration supported by Duration."
Since this fragment of the sentence is also describing ERA i suspect
its a copy+paste problem, it can be
On 12/10/2015 16:09, Vyom Tewari wrote:
Hi All,
Please review my changes for below bug.
Bug:JDK-8068887 : java.lang.Throwable could use
Collections.emptyList for suppressedException
Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/
This change ensure that
On Tue, Oct 6, 2015 at 10:16 AM, Andrew Haley wrote:
>
> Sure. I would have thought, though, that java.util.concurrent was a
> natural home for this. Is there any kind of userland spinlock which
> is not about concurrency?
>
> Andrew.
>
Spinning is not always for a spinlock.
+1
On Thu, Oct 8, 2015 at 6:35 PM, Paul Sandoz wrote:
>
> > On 8 Oct 2015, at 18:33, mark.reinh...@oracle.com wrote:
> >
> > 2015/10/8 7:56 -0700, d...@cs.oswego.edu:
> ...
>
> class Thread { //
> /**
> * A hint to the platform that the
Hello!
With the introduction of Stream API the JavaDoc for
Collections.synchronizedCollection was updated (as part of work on
JDK-8023275):
* It is imperative that the user manually synchronize on the returned
* collection when traversing it via {@link Iterator}, {@link Spliterator}
* or
Hi All,
Please review my changes for below bug.
Bug:JDK-8068887 : java.lang.Throwable could use
Collections.emptyList for suppressedException
Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/
This change ensure that fewer classes are loaded in a simple(hello
> On Oct 12, 2015, at 8:09 AM, Vyom Tewari wrote:
>
> Hi All,
>
> Please review my changes for below bug.
>
> Bug:JDK-8068887 : java.lang.Throwable could use
> Collections.emptyList for suppressedException
> Webrev:
On 22 Sep 2015, at 18:30, Paul Sandoz wrote:
Hi,
Please review the following which adds methods to Arrays for
performing equality, comparison and mismatch:
https://bugs.openjdk.java.net/browse/JDK-8033148
On 12 Oct 2015, at 17:54, Mandy Chung wrote:
>
>> On Oct 12, 2015, at 8:09 AM, Vyom Tewari wrote:
>>
>> Hi All,
>>
>> Please review my changes for below bug.
>>
>> Bug:JDK-8068887 : java.lang.Throwable could use
>>
2015/10/8 1:41 -0700, roger.ri...@oracle.com:
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/
>
> javadoc:
> http://cr.openjdk.java.net/~rriggs/cleaner-doc2/
Roger -- thanks for taking this on. The more we can do to get people
to stop using sun.misc APIs,
> On 12 Oct 2015, at 19:50, Mike Duigou wrote:
>
>
>>> On 22 Sep 2015, at 18:30, Paul Sandoz wrote:
>>> Hi,
>>> Please review the following which adds methods to Arrays for performing
>>> equality, comparison and mismatch:
>>>
On 10/12/15 3:40 PM, Naoto Sato wrote:
I have two comments in the test case:
- A typo in line 32: "symetrically" -> "symmetrically"
Well-spotted. I also fixed "corresponsing" on line 78. :)
- Should "toUpperToLowerOriginals() compare the length of two strings?
The current implementation
FYI: updated webrev & specdiff with test case, and Roger's suggestion
for using @link:
http://cr.openjdk.java.net/~bchristi/8138824/webrev.1/
http://cr.openjdk.java.net/~bchristi/8138824/specdiff.1/overview-summary.html
Thanks,
-Brent
On 10/8/15 10:22 AM, Brent Christian wrote:
Sure, I'll
Hi Brent,
Thank you for adding a test case. I have two comments in the test case:
- A typo in line 32: "symetrically" -> "symmetrically"
- Should "toUpperToLowerOriginals() compare the length of two strings?
The current implementation returns true if str2.startsWith(str1) is true.
Naoto
On
> On Oct 12, 2015, at 12:30 PM, mark.reinh...@oracle.com wrote:
>
> 2015/10/8 1:41 -0700, roger.ri...@oracle.com:
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/
>>
>> javadoc:
>>http://cr.openjdk.java.net/~rriggs/cleaner-doc2/
>
> Roger -- thanks for
- I apologize if this was discussed earlier in the thread but why is
the comparison of floats and doubles done by first == operator of the
int bits and only then the compare method ?
I was being consistent with the test used for the existing equals
methods of float[] and double[]. Note that
31 matches
Mail list logo