On Wed, Sep 21, 2016 at 2:38 PM, Pavel Rappo wrote:
> On Wed, Sep 21, 2016 at 9:43 PM, Martin Buchholz
> wrote:
> > What is happening instead is API providers not using CompletionStage as
> > return values in public APIs because of the lack of
(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.html, but: we need to
re-add (safe, read-only) blocking methods
On 09/21/2016 09:33 PM, Martin Buchholz wrote:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
Looks fine. Multi-story predicates sure look better now...
-Aleksey
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.minimalCompletionStage().toCompletableFuture() useful.
Lots of boring changes to
> On Sep 21, 2016, at 6:38 AM, Kumar Srinivasan
> wrote:
>
>
> 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
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 . The root
cause is a debugging assertEquals method that printed out debugging
message without throwing Exception. I've searched the jaxp/test to make
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
long pushed the changes mentioned below.
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
the OpenJDK. Unfortunately a