- 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 t
Hi Daniel,
> On Oct 9, 2015, at 12:53 PM, Daniel Fuchs wrote:
>
> JEP:
> http://openjdk.java.net/jeps/264
> https://bugs.openjdk.java.net/browse/JDK-8046565
>
> specdiff:
> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html
>
> webrev:
> http://cr.openjdk.ja
> 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 tak
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 ret
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 1
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 wr
> 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:
>>> https://bugs.openjdk.java.net/browse/JDK-8033148
>>> http://cr.ope
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, th
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
>> Collections.emptyList for suppressedException
>> Webrev: http:/
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
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
> 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: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/
>
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 rew
+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 momentarily
>>>* un
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
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): 8
+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 current thread is momentari
>
> 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.
> > jdk.util.PerformanceHints.spinLoopH
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. Most of the time i
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 :-)
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: http://cr.openjdk.java.net/~vtewari/806888
On 2015-10-12 17:56, Alan Bateman wrote:
This looks okay (just missing the a space in =Collections) but I'm
curious if it does actual reduce the number of classes loaded at
startup. I would think ArrayList and unmodifiable list would be popular.
I filed this RFE, so this looks okay to me as
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
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 f
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 t
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
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 {@lin
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
>> better compose optionals:
>
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: http://cr.openjdk.java
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: http://cr.openjdk.java.net/~amlu/8139407/webrev.00/
Thanks,
Amy
--- old/test/java/
>
> “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 name
> 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 Arrays.equals and Arrays.mism
> 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 opportunity to clear up the JavaDo
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 Sep 2015, at 18:30, Paul Sa
> 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
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexic
34 matches
Mail list logo
