On September 23, 2016 8:13:36 AM GMT+02:00, Kasper Nielsen
wrote:
>Hi,
>
>I accidently bumped into an old friend today
>https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html
>There are couple of questions that might need an update after Java 8.
>Such
>as
>
>Why don'
On 21 September 2016 at 22:43, Martin Buchholz wrote:
> (Sorry to re-open this discussion)
>
> The separation of a read-only CompletionStage from CompletableFuture is
> great. I'm a fan of the scala style Promise/Future split as described in
> http://docs.scala-lang.org/overviews/core/futures.ht
Hi,
I accidently bumped into an old friend today
https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html
There are couple of questions that might need an update after Java 8. Such
as
Why don't you provide an "apply" method in Collection to apply a given
method ("upcall")
Hi Goetz,
I see a change not related directly to S390 ie change from ARM to ARM32
in src/os/linux/vm/os_linux.cpp
It will be a while before I can go through this in any detail.
David
On 23/09/2016 3:52 PM, Lindenmaier, Goetz wrote:
Hi,
This change is part of the s390 port. It contains some
Hi,
This change is part of the s390 port. It contains some basic adaptions needed
for a full hotspot port for linux s390x.
It defines the required macros, platform names and includes.
The s390 port calles CodeCache::contains() in current_frame(), which is used in
NMT. As NMT already collects
This is the second example I've seen in two days concerning misuse of
CHECK_ macros. They expand into an if statement after the call, so can
not appear on calls that are part of a return statement, or a
conditional statement, or likely a number of other places, as the if
code either becomes unr
Thanks for the lesson, James!
On Wed, Sep 21, 2016 at 3:57 PM, James Roper wrote:
> On 22 September 2016 at 06:43, Martin Buchholz
> wrote:
>
>> What is happening instead is API providers not using CompletionStage as
>> return values in public APIs because of the lack of convenient blocking,
>>
That’d be fine.
Mandy
> On Sep 22, 2016, at 11:43 AM, Sean Coffey wrote:
>
> Thanks Mandy. I pushed this change earlier today. If BasicImageReader.java is
> being edited again in the near future, we might be able to make your
> suggested edits then.
>
> regards,
> Sean.
>
> On 22/09/2016 19
Brent,
Looks good for me.
-Dmitry
On 2016-09-22 19:04, Brent Christian wrote:
> Hi,
>
> Looks like my 8165372 change broke the slowdebug build. Please review
> my fix (which also breaks up a pretty long line):
>
> --- a/src/share/vm/prims/stackwalk.cpp
> +++ b/src/share/vm/prims/stackwalk.cpp
Thanks Mandy. I pushed this change earlier today. If
BasicImageReader.java is being edited again in the near future, we might
be able to make your suggested edits then.
regards,
Sean.
On 22/09/2016 19:23, Mandy Chung wrote:
On Sep 21, 2016, at 8:56 AM, Seán Coffey wrote:
Resurrecting this o
> On Sep 21, 2016, at 8:56 AM, Seán Coffey wrote:
>
> Resurrecting this old review thread. After some internal discussion, I've
> dropped the minor edit that was made in StackTraceElementCompositeData. It
> could be noisy data for exception purposes. I've corrected the other issues
> raised b
On Sep 22, 2016, at 12:23 AM, Michael Haupt wrote:
> thanks for your review, and thanks Vladimir! I've had another go at the
> implementation to use a dedicated loop clause holder class with a stable
> array; performance is roughly on par with that of the BMHs-as-arrays approach
> (see below).
Hi,
Looks like my 8165372 change broke the slowdebug build. Please review
my fix (which also breaks up a pretty long line):
--- a/src/share/vm/prims/stackwalk.cpp
+++ b/src/share/vm/prims/stackwalk.cpp
@@ -331,10 +331,12 @@
assert (use_frames_array(mode), "Bad mode for get live frame");
Thanks Daniel!
I'm glad the issue was caught! I'm also making sure any the debugging
method shall throw Exception as well :-)
Best,
Joe
On 9/22/16, 2:09 AM, Daniel Fuchs wrote:
Hi Joe,
Looks good to me.
Thanks for having taken the time to take a second look :-)
best regards,
-- daniel
O
On 22/09/2016 14:14, Alan Bateman wrote:
This looks okay to me. You may want to change the bug message to drop
"thrown by jigsaw code" as most of the changed files are jimage or
other areas.
Thanks Alan - Yes - will correct that before I push then.
regards,
Sean.
On Thu, Sep 22, 2016 at 5:39 AM, Chris Hegarty
wrote:
>
> Can you please check the indentation in testCopy_normalCompletion
> and testCopy_exceptionalCompletion.
>
CompletableFutureTest.java has a unique experimental indentation style,
that is not clearly worse than the alternatives.
On 21/09/2016 08:56, Seán Coffey wrote:
Resurrecting this old review thread. After some internal discussion,
I've dropped the minor edit that was made in
StackTraceElementCompositeData. It could be noisy data for exception
purposes. I've corrected the other issues raised by Alan and Jim has
l
On 21 Sep 2016, at 20:33, Martin Buchholz wrote:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
>
> Notable here is an attempt to make a minimal completion stage more acceptable
> as a return value from APIs, by making
> completableFuture.minimalCompletionStag
Until now CS and CF have not appeared in Java SE API signatures,
outside of the j.u.c package. They are, however, currently being
proposed for use in API signatures for Java SE 9 [1][2], namely
j.l.Process[Handle]::onExit, and more extensively in the proposed new
HTTP Client.
CF was chosen, in som
Hi Joe,
Looks good to me.
Thanks for having taken the time to take a second look :-)
best regards,
-- daniel
On 21/09/16 17:47, Joe Wang wrote:
Hi Daniel,
Here's the fix for the test issues, a couple of errors including missing
handler in StAX test, and dtd was mistakingly typed as xsd . Th
Hi John,
thanks for your review, and thanks Vladimir! I've had another go at the
implementation to use a dedicated loop clause holder class with a stable array;
performance is roughly on par with that of the BMHs-as-arrays approach (see
below).
The new webrev is at http://cr.openjdk.java.net/~
Hi Kumar,
> On 9/16/2016 10:34 AM, Volker Simonis wrote:
>
>> Hi Christoph,
>>
>> I think your change is fine as a quick-fix to fix the build. But
>> you're completely right that this should be reworked in the long term.
>> I hate to see that we now have the third version of these routines in
>>
22 matches
Mail list logo
