Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

I don't remember what happened in 2005, but records say that I wrote: """Why not .. - add to the spec of Future.cancel() a guarantee that subsequent calls to Future.isDone() always return true? """ which led to the spec: """After this method returns, subsequent calls to isDone()

Re: We need to add blocking methods to CompletionStage!

On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang wrote: > >> > Test methods, >> > > Yeah, I thought so as well, but it turns out that when you have tons of > async tests, not being able to start new tests until either that timeout or > result makes for a very slow test suite, so that's why most seri

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Not at all, you could just have a call to cancel() block until the future completes. *ducks* Attila. > On 25 Sep 2016, at 16:34, Viktor Klang wrote: > > If that truely is the case then the only way of implementing a readonly > Future is by throwing an exception from cancel... > > -- > Cheer

RFR 9: 8155760 Implement Serialization Filtering - revised for extensibility

To more easily support future enhancement of the information provided to the serial filter the API has been modified to pass the information to the filter via an interface with methods for the class, array length, references, depth and stream bytes. Complete webrev supporting Serialization Filt

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

> On Sep 26, 2016, at 12:25 AM, Alan Bateman wrote: > > Do we have any issues tracking the issue of direct access to types in > com.sun.org.apache.xerces.internal.**. Those will need to be addressed if > JAX-WS is to be truely standalone without needing --add-exports options on > the command

RFR: 8165944 jar utility doesn't process more than one -C argument

Hi, Please review these changes to the jar tool to fix a capability regression I introduced in an earlier revision. The issue is that this $ jar -cf test.jar -C test1 . -C test2 . only puts the files under test1 in the jar and ignores the files under test2. The DoubleCs test verified the pro

Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

Hi John, all, thank you very much for your reviews - may I ask for a second round? The updated webrev is at http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ ; an accompanying specdiff, at http://cr.openjdk.java.net/~mhaupt/8151179/spec

RE: Proposal for adding O_DIRECT support into JDK 9

Alan, you mean readv0/write0 or read0/write0? I just want to make sure :-) Anyone else has other opinions on where is the best home for O_DIRECT flag? The flags under jdk.unsupported will eventually be removed in the future JDK release? If we agree ExtendedOpenOpen is the best home for O_DIRECT

Re: Proposal for adding O_DIRECT support into JDK 9

On 26/09/2016 19:17, Lu, Yingqi wrote: Hi All, The second version of the patch is now available at http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as a StandardOpenOption. The reason we d

RE: Proposal for adding O_DIRECT support into JDK 9

Hi All, The second version of the patch is now available at http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as a StandardOpenOption. The reason we did not make it as one of the ExtendedOpenO

Re: We need to add blocking methods to CompletionStage!

On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz wrote: > No one is suggesting we add cancel to CompletionStage - I agree that would > break users, by making an immutable interface mutable. > +1 > This also means that CompletionStage cannot extend Future. > +1 > I also would not wa

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

> On 25 Sep 2016, at 22:49, Martin Buchholz wrote: > ...Say you are implementing some existing function with a traditional > synchronous API. Your implementation is multi-threaded, but that's an > implementation detail. Before you return to the caller, you must wait for > the various parts o

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Cancellation: David, I can see your point. Future.cancel(true) was discussed 8/27/05 and the extra text was added to make it clearer that the state of Future after cancel is called is separate from the state of any associated thread or task. However, I think the added text corresponded too closely

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

This statement regarding what happens after cancel is called is correct: "*After this method returns, subsequent calls to **isDone**() will always return true*. Subsequent calls to isCancelled() will always return true if this method returned true." After cancel returns, the future is completed,

Re: We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang wrote: > > > On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz > wrote: > >> No one is suggesting we add cancel to CompletionStage - I agree that >> would break users, by making an immutable interface mutable. >> > > +1 > > >> This also means th

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

On 09/26/2016 04:00 PM, Alan Bateman wrote: This seems a good use of MR JAR. Will the standalone version also have module-info in the top-level directory of the JAR file so that it can be deployed on the [upgrade] module path too? We are planning to set modularization along with runnable JDK9

Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc

Hi, I've been a little busy with JavaOne but now I've finally pushed this change. Thanks to everybody, Volker On Thu, Sep 15, 2016 at 8:08 AM, Hiroshi H Horii wrote: > Hi Volker, and Sean, > > Thank you for your comments and suggestion. > > I and Gustavo created a webrev that includes Bits and

Re: We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 11:49 PM, Martin Buchholz wrote: > > > On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: > >> >> PS. As a sidenote, Martin, and in all friendliness, "actor purist API"? >> C'mon, I know you're better than that! CompletionStage's design has nothing >> to do with Actor

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 11:22 PM, David Holmes wrote: > Joe, > > > > That is ignoring the error case. If the cancel fails then it is not > complete and it is not cancelled. We added the extra wording back in August > 2005. It is interesting to note that Martin’s initial query then only > related

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 10:01 PM, Martin Buchholz wrote: > > > On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang > wrote: > >> If that truely is the case then the only way of implementing a readonly >> Future is by throwing an exception from cancel... >> > We the maintainers of j.u.c.Future have alw

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

On 26/09/2016 14:07, Roman Grigoriadi wrote: Hi, Thank you for review. We were discussing java.net will go down eventually, links to jaxb.java.net is best we have now (to fix submitted javadoc bug), we will update links again when we know new location of standalone projects documentation.

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

Hi, Thank you for review. We were discussing java.net will go down eventually, links to jaxb.java.net is best we have now (to fix submitted javadoc bug), we will update links again when we know new location of standalone projects documentation. Regarding clean standalone TCK tests - yes they

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

On 26/09/2016 00:41, Aleks Efimov wrote: Hi Alan, Joe, Mandy, Roman, Suggested changes to the comment section (will bring this change to standalone JAXB) and to the exported internal API were made: com.sun.xml.internal.stream.writers, com.sun.org.apache.xml.internal.resolver, com.sun.org.ap

Re: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies

On 25/09/2016 16:16, Sergei Kovalev wrote: If I've drop jdk.jartool, I faced with ClassNotFound error as I showed in #3 java.lang.ClassNotFoundException: jdk.security.jarsigner.JarSigner$Builder As you can see TEST.properties contains both: jdk.compiler and jdk.jartool I didn't suggesting