hg: jdk8/tl/jdk: 7193463: Improve registering signal handlers in java.lang.Terminator.setup()
Changeset: e7b53fe85540 Author:dingxmin Date: 2012-08-23 16:28 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7b53fe85540 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Reviewed-by: dholmes, alanb ! src/solaris/classes/java/lang/Terminator.java ! src/windows/classes/java/lang/Terminator.java
Re: Review of new Http client API
On 22/08/12 22:09, Sam Pullara wrote: On Aug 22, 2012, at 1:17 PM, Chris Hegarty wrote: On 22/08/12 21:05, Michael McMahon wrote: On 22/08/12 15:29, Chris Hegarty wrote: Michael what you have looks good. But, I think what Sam is suggesting ( or maybe not, but I like it ;-) ), is something like this. (I'd need to think more about what effect this has on the different modes, async/blocking ) Yep, this is exactly what I was suggesting. Thanks for clarifying with code. class HttpResponse { HttpResponse onHeaders(Block); HttpResponse onError(BiBlock); HttpResponse onBodyPart(BiBlock); } Right. I see what you mean in terms of making the setting of the callbacks fluent. I assume that Block and BiBlock are types associated with Lambda Right, these are types defined in the lambda repo, that will most likely be part of JDK8. Worth a look, and we should also confirm with the lambda folks before build them into this API. Briant Goetz would be the right person to ask. In the meantime, there shouldn't be an issue using custom interfaces with a single method (HeaderCallback, ErrorCallback, BodyCallback, etc). Yes, I think that gives us a good fall back in case things develop differently in Lambda. For the moment, I will use three different interfaces, and put some text in the apidoc suggesting they might be replaced with standard Lambda types before JDK8 is finished. Thanks Michael. Sam somehow, but otherwise this is unfamiliar territory to me response.onHeaders(r -> headers(r)) .onError((r,t) -> error(t)) .onBodyPart((r,bb) -> body(r, bb)); So, headers() and body() would be methods on HttpResponse ... Right ? What is error()? No, sorry for the confusion. headers(), error(), and body() are just examples of what some user code could be ( rather than cluttering the example with too much code ). -Chris. - Michael. Alternatively, I believe something like this would also be compatible with lambda (since there is a default implementation for on Error): interface HTTPResponseHandler { public void onHeaders(HttpResponse resp); public void onError(HttpRequest request, Throwable exception) default { throw exception; } } -Chris. On 21/08/2012 14:57, Michael McMahon wrote: Sam, Thanks for the comments. Some discussion below. On 17/08/12 00:13, Sam Pullara wrote: I suggest that you make it a more fluent API rather than having multiple callback methods in your callback interface. As it stands it isn't compatible with lambdas. You might take some inspiration for the asynchronous callbacks from my work porting Twitter's Future/Promise to JDK8: I agree with the above. In a previous version of the API the main callback was lambda compatible. Originally we used HttpResponse to encapsulate everything related to a response including errors. But, some preferred to keep HttpResponse aligned to an actual response from a server in all cases. There might be other ways to get around that by combining HttpResponseHeadersHandler.{onError(), onHeaders()} back into a single method. Maybe, drop the onError() method and add the exception/throwable as a parameter to onHeaders() But, we also wanted to provide notification of body data (through the sub-interface HttpResponseHandler). Keeping the two interfaces distinct meant that applications could get asynchronous notification of the response headers, but then possibly read the response body in a blocking manner. Or alternatively, applications can use the handler to be notified of both headers and body. So, if we revert HttpResponseHeadersHandler back to having a single method, the sub-interface now would have two methods (instead of three). One way around that could be to have two unrelated interfaces: interface HttpResponseHeadersHandler { public void onHeaders(HttpResponse response, Exception e); } interface HttpResponseBodyHandler { public void onBodyPart(HttpResponse resp, ByteBuffer buffer, boolean last); } // Then a HttpResponseBodyHandler would be added to HttpClient.sendRequest() as below: public void sendRequest(HttpRequest, HttpResponseHeadersHandler, HttpResponseBodyHandler); Both of the interfaces would be lambda compatible (again) though at the cost of having to specify two separate handlers. So, the following might be how it could be used (and using a builder for HttpClient) HttpClient client = HttpClient.createBuilder() .setAsynchronousChannelGroup (..) .setCookieManager(..) .setDefaultTimeout(..) .setProxy(...) .addFilter(...) .buildClient(); HttpRequest request = client.createRequest(new URI("http://www.foo.com/";)) .setBody("Hello world".getBytes()) .setMethod(HttpMethod.POST); client.sendRequest ( request, // handle headers (HttpResponse response, Exception e) -> { if (response.getResponseCode() != 200) { // handle error response } // handle normal case }, // handle body (HttpResponse response, ByteBuffer buf, boolean last) -> { // handle data in buf } ); It seems fairly r
hg: jdk8/tl/jdk: 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx]
Changeset: de5a85353f4d Author:alanb Date: 2012-08-23 13:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de5a85353f4d 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Reviewed-by: alanb Contributed-by: Jason T Greene ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
Re: Review of new Http client API
Hi, A potential simplification of the HttpResponseHeadersHandler interface is to turn it into a functional interface: HttpResponseHandler onHeaders(Future dresp) throws InterruptedException, ExecutionException; [Chris, i am not sure if an interface with two methods, one default, is classified as a functional interface.] - mirrors the pull-based asynchronous approach - dresp.isDone() always returns true - the Future encapsulates the underling exception, if any - harder to swallow errors, since the exception from drep.get() will propagate if not caught. - a return of a null HttpResponseHandler means "not interested in the body". FWIW the use of Future is the approach i chose for the Jersey client. HttpResponseHandler would also be a functional interface: void onBodyPart(Future bb) throws InterruptedException, ExecutionException - there is no inheritance relationship between HttpResponseHeadersHandler and HttpResponseHandler. - a "bb" with a capacity of 0 indicates the last part. - the HttpResponse is not required as a parameter because the implementation can obtain it from the onHeaders method. If the use of Future is a bit extreme for some :-) then things can still be simplified by following the above approach with an additional, and optional, functional interface to handle errors when HttpClient.sendRequest is called. -- Rather than setting the bytes on the HttpRequest with numerous methods i wonder if it is better to have a functional interfaces for both OutputStream and the NIO equivalent: interface EntityWriter { // Oh for disjunct types! /** * @return true if there is more to write */ boolean write(T t) throws IOException; } I believe the above can support all the existing functionality currently expressed as methods, including the Iterable/Iterator. There can be instances of EntityWriter for common functionality: EntityWriters.fromBytes(byte[] b, ...); The same might be applicable to HttpResponse with an EntityReader: interface EntityReader { U read(T t) throws IOException; } Of course i might be missing something obvious here in terms of optimisation currently performed by the implementation! -- It somewhat bugs me that blocking and asynchronous pull/push functionality is all defined using the same artifacts. But, my imagination is currently is failing me on how to improve on such matters. Perhaps something better may come out of fluent-based API? Paul. On Aug 14, 2012, at 2:01 PM, Michael McMahon wrote: > Hi, > > (apologies for sending this again) > We have just published a draft of a proposed new Http client API [1] for JDK > 8. > > This message has been cc'd to jdk8-dev so that as many people as possible > know about it, but the discussion will be on the net-dev list > (net-dev@openjdk.java.net). > So, folks will have to join that list [2], in order to take part. > > Thanks, > Michael. > > [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev
Re: Review of new Http client API
Paul, All good feedback, and I will leave it to Michael to reply to the specifics. On thought I had on separation of modes is something list this: interface HeaderHandler { onHeaders(HttpResponse); } interface ErrorHandler { onError(HttpResponse, Throwable); } interface BodyHandler { onBodyPart(HttpResponse, ByteBuffer, boolean); } class HttpRequest { AsyncHttpRequest async(HttpRequest); } class AsyncHttpRequest extends HttpRequest { // no public constructors AsyncHttpRequest onHeaders(HeaderHandler); AsyncHttpRequest onError(ErrorHandler); AsyncHttpRequest onBodyPart(BodyHandler); } class HttpClient { OutputStream sendHeaders(HttpRequest request, long contentLength) Future sendRequest(HttpRequest req) void sendRequest(AsyncHttpRequest req) } Then user code may do: AsyncHttpRequest request.async() .onHeaders(r -> dumpHeaders(r)) .onError((r,t) -> handleError(r,t)); .onBodyPart((r,bb,c) -> transformBody(r,bb,t)); client.sendRequest(request); void dumpHeaders(HttpResponse r) { System.out.println(r); } void handleError(HttpResponse r, t) { throw t; } void transformBody(HttpResponse r, bb, boolean complete) { System.out.println("Hello there!"); } Some experimentation is necessary to find a good balance here. -Chris. On 23/08/2012 15:20, Paul Sandoz wrote: Hi, A potential simplification of the HttpResponseHeadersHandler interface is to turn it into a functional interface: HttpResponseHandler onHeaders(Future dresp) throws InterruptedException, ExecutionException; [Chris, i am not sure if an interface with two methods, one default, is classified as a functional interface.] - mirrors the pull-based asynchronous approach - dresp.isDone() always returns true - the Future encapsulates the underling exception, if any - harder to swallow errors, since the exception from drep.get() will propagate if not caught. - a return of a null HttpResponseHandler means "not interested in the body". FWIW the use of Future is the approach i chose for the Jersey client. HttpResponseHandler would also be a functional interface: void onBodyPart(Future bb) throws InterruptedException, ExecutionException - there is no inheritance relationship between HttpResponseHeadersHandler and HttpResponseHandler. - a "bb" with a capacity of 0 indicates the last part. - the HttpResponse is not required as a parameter because the implementation can obtain it from the onHeaders method. If the use of Future is a bit extreme for some :-) then things can still be simplified by following the above approach with an additional, and optional, functional interface to handle errors when HttpClient.sendRequest is called. -- Rather than setting the bytes on the HttpRequest with numerous methods i wonder if it is better to have a functional interfaces for both OutputStream and the NIO equivalent: interface EntityWriter { // Oh for disjunct types! /** * @return true if there is more to write */ boolean write(T t) throws IOException; } I believe the above can support all the existing functionality currently expressed as methods, including the Iterable/Iterator. There can be instances of EntityWriter for common functionality: EntityWriters.fromBytes(byte[] b, ...); The same might be applicable to HttpResponse with an EntityReader: interface EntityReader { U read(T t) throws IOException; } Of course i might be missing something obvious here in terms of optimisation currently performed by the implementation! -- It somewhat bugs me that blocking and asynchronous pull/push functionality is all defined using the same artifacts. But, my imagination is currently is failing me on how to improve on such matters. Perhaps something better may come out of fluent-based API? Paul. On Aug 14, 2012, at 2:01 PM, Michael McMahon wrote: Hi, (apologies for sending this again) We have just published a draft of a proposed new Http client API [1] for JDK 8. This message has been cc'd to jdk8-dev so that as many people as possible know about it, but the discussion will be on the net-dev list (net-dev@openjdk.java.net). So, folks will have to join that list [2], in order to take part. Thanks, Michael. [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev
Re: Review of new Http client API
Paul, Thanks for looking at it. Yes, this is an area that needs some more work. The current thinking is along the lines that Chris just posted and I hope to have another version of the API to look at tomorrow. What you suggest seems like an unusual usage of Future<> as we have tried to provide a mode of operation where applications can get a Future which would work in the conventional way of returning the result "in the future". But, it raises a question in that while we currently have callback interfaces for both headers and data, we only have a Future based interface for headers (but not data). - Michael On 23/08/12 15:20, Paul Sandoz wrote: Hi, A potential simplification of the HttpResponseHeadersHandler interface is to turn it into a functional interface: HttpResponseHandler onHeaders(Future dresp) throws InterruptedException, ExecutionException; [Chris, i am not sure if an interface with two methods, one default, is classified as a functional interface.] - mirrors the pull-based asynchronous approach - dresp.isDone() always returns true - the Future encapsulates the underling exception, if any - harder to swallow errors, since the exception from drep.get() will propagate if not caught. - a return of a null HttpResponseHandler means "not interested in the body". FWIW the use of Future is the approach i chose for the Jersey client. HttpResponseHandler would also be a functional interface: void onBodyPart(Future bb) throws InterruptedException, ExecutionException - there is no inheritance relationship between HttpResponseHeadersHandler and HttpResponseHandler. - a "bb" with a capacity of 0 indicates the last part. - the HttpResponse is not required as a parameter because the implementation can obtain it from the onHeaders method. If the use of Future is a bit extreme for some :-) then things can still be simplified by following the above approach with an additional, and optional, functional interface to handle errors when HttpClient.sendRequest is called. -- Rather than setting the bytes on the HttpRequest with numerous methods i wonder if it is better to have a functional interfaces for both OutputStream and the NIO equivalent: interface EntityWriter { // Oh for disjunct types! /** * @return true if there is more to write */ boolean write(T t) throws IOException; } I believe the above can support all the existing functionality currently expressed as methods, including the Iterable/Iterator. There can be instances of EntityWriter for common functionality: EntityWriters.fromBytes(byte[] b, ...); The same might be applicable to HttpResponse with an EntityReader: interface EntityReader { U read(T t) throws IOException; } Of course i might be missing something obvious here in terms of optimisation currently performed by the implementation! -- It somewhat bugs me that blocking and asynchronous pull/push functionality is all defined using the same artifacts. But, my imagination is currently is failing me on how to improve on such matters. Perhaps something better may come out of fluent-based API? Paul. On Aug 14, 2012, at 2:01 PM, Michael McMahon wrote: Hi, (apologies for sending this again) We have just published a draft of a proposed new Http client API [1] for JDK 8. This message has been cc'd to jdk8-dev so that as many people as possible know about it, but the discussion will be on the net-dev list (net-dev@openjdk.java.net). So, folks will have to join that list [2], in order to take part. Thanks, Michael. [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev
Re: Review of new Http client API
On Aug 23, 2012, at 5:05 PM, Chris Hegarty wrote: > Paul, > > All good feedback, and I will leave it to Michael to reply to the specifics. > On thought I had on separation of modes is something list this: > > interface HeaderHandler { > onHeaders(HttpResponse); > } > interface ErrorHandler { > onError(HttpResponse, Throwable); > } > interface BodyHandler { > onBodyPart(HttpResponse, ByteBuffer, boolean); > } > > class HttpRequest { > > AsyncHttpRequest async(HttpRequest); > > } > > class AsyncHttpRequest extends HttpRequest { > // no public constructors > > AsyncHttpRequest onHeaders(HeaderHandler); > AsyncHttpRequest onError(ErrorHandler); > AsyncHttpRequest onBodyPart(BodyHandler); > } > > class HttpClient { > > OutputStream sendHeaders(HttpRequest request, long contentLength) > Future sendRequest(HttpRequest req) > void sendRequest(AsyncHttpRequest req) > } > OK, i would be inclined to separate out the instance used for building from the instance passed around, so one cannot muck around with the state of the latter. > Then user code may do: > > AsyncHttpRequest request.async() > .onHeaders(r -> dumpHeaders(r)) > .onError((r,t) -> handleError(r,t)); > .onBodyPart((r,bb,c) -> transformBody(r,bb,t)); > client.sendRequest(request); > If these calls are on* calls are optional and one is not interested in when the headers have been received one could omit the onHeaders call, infact all those methods could be optional. That certainly simplifies things. > > > void dumpHeaders(HttpResponse r) { > System.out.println(r); > } > void handleError(HttpResponse r, t) { > throw t; > } > void transformBody(HttpResponse r, bb, boolean complete) { > System.out.println("Hello there!"); > } > FWIW you could use method references: AsyncHttpRequest request.async() .onHeaders(whateverthatclassiscalled::dumpHeaders) ... Paul. > Some experimentation is necessary to find a good balance here. > > -Chris.
Re: Review of new Http client API
On Aug 23, 2012, at 5:16 PM, Michael McMahon wrote: > Paul, > > Thanks for looking at it. Yes, this is an area that needs some more work. > The current thinking is along the lines that Chris just posted and I hope to > have another version of the API to look at tomorrow. > > What you suggest seems like an unusual usage of Future<> as we have tried to > provide > a mode of operation where applications can get a Future > which would work in the conventional way of returning the result "in the > future". Agreed, it fit well with the underlying asynchronous support in Jersey, which was already using the Future, and it bugged me using callback interfaces with two methods, where most of the time the error would be swallowed. If there was a listener concept for Future in the JDK I would have used that instead. I think the approach Chris shows easily allows for a default handler when one is not supplied. > But, it raises a question in that while we currently have callback interfaces > for both > headers and data, we only have a Future based interface for headers (but not > data). > Indeed! Paul. > - Michael > > On 23/08/12 15:20, Paul Sandoz wrote: >> Hi, >> >> A potential simplification of the HttpResponseHeadersHandler interface is to >> turn it into a functional interface: >> >> HttpResponseHandler onHeaders(Future dresp) throws >> InterruptedException, ExecutionException; >> >> [Chris, i am not sure if an interface with two methods, one default, is >> classified as a functional interface.] >> >> - mirrors the pull-based asynchronous approach >> >> - dresp.isDone() always returns true >> >> - the Future encapsulates the underling exception, if any >> >> - harder to swallow errors, since the exception from drep.get() will >> propagate if not caught. >> >> - a return of a null HttpResponseHandler means "not interested in the body". >> >> FWIW the use of Future is the approach i chose for the Jersey client. >> >> HttpResponseHandler would also be a functional interface: >> >> void onBodyPart(Future bb) throws InterruptedException, >> ExecutionException >> >> - there is no inheritance relationship between HttpResponseHeadersHandler >> and HttpResponseHandler. >> >> - a "bb" with a capacity of 0 indicates the last part. >> >> - the HttpResponse is not required as a parameter because the implementation >> can obtain it from the onHeaders method. >> >> If the use of Future is a bit extreme for some :-) then things can still be >> simplified by following the above approach with an additional, and optional, >> functional interface to handle errors when HttpClient.sendRequest is called. >> >> -- >> >> Rather than setting the bytes on the HttpRequest with numerous methods i >> wonder if it is better to have a functional interfaces for both OutputStream >> and the NIO equivalent: >> >> interface EntityWriter { // Oh for disjunct types! >> /** >> * @return true if there is more to write >> */ >> boolean write(T t) throws IOException; >> } >> >> I believe the above can support all the existing functionality currently >> expressed as methods, including the Iterable/Iterator. There can be >> instances of EntityWriter for common functionality: >> >> EntityWriters.fromBytes(byte[] b, ...); >> >> The same might be applicable to HttpResponse with an EntityReader: >> >> interface EntityReader { >> U read(T t) throws IOException; >> } >> >> Of course i might be missing something obvious here in terms of optimisation >> currently performed by the implementation! >> >> -- >> >> It somewhat bugs me that blocking and asynchronous pull/push functionality >> is all defined using the same artifacts. But, my imagination is currently is >> failing me on how to improve on such matters. Perhaps something better may >> come out of fluent-based API? >> >> Paul. >> >> On Aug 14, 2012, at 2:01 PM, Michael McMahon >> wrote: >> >>> Hi, >>> >>> (apologies for sending this again) >>> We have just published a draft of a proposed new Http client API [1] for >>> JDK 8. >>> >>> This message has been cc'd to jdk8-dev so that as many people as possible >>> know about it, but the discussion will be on the net-dev list >>> (net-dev@openjdk.java.net). >>> So, folks will have to join that list [2], in order to take part. >>> >>> Thanks, >>> Michael. >>> >>> [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>> >>> [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev >
Re: Review of new Http client API
On 23/08/2012 16:34, Paul Sandoz wrote: ... OK, i would be inclined to separate out the instance used for building from the instance passed around, so one cannot muck around with the state of the latter. Agreed, HttpResponse could use a builder pattern. Then user code may do: AsyncHttpRequest request.async() .onHeaders(r -> dumpHeaders(r)) .onError((r,t) -> handleError(r,t)); .onBodyPart((r,bb,c) -> transformBody(r,bb,t)); client.sendRequest(request); If these calls are on* calls are optional and one is not interested in when the headers have been received one could omit the onHeaders call, infact all those methods could be optional. That certainly simplifies things. Right. void dumpHeaders(HttpResponse r) { System.out.println(r); } void handleError(HttpResponse r, t) { throw t; } void transformBody(HttpResponse r, bb, boolean complete) { System.out.println("Hello there!"); } FWIW you could use method references: AsyncHttpRequest request.async() .onHeaders(whateverthatclassiscalled::dumpHeaders) Ok, great. -Chris. ... Paul. Some experimentation is necessary to find a good balance here. -Chris.
Code review request 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource()
Could I get the change reviewed please This behavior is seen on Windows. Logic in URLClassPath.getLoader() does not take care of an URL which looks like "jar:file:/C:/test/xyz.jar!/". The logic ends up choosing a FileLoader instead of a JarLoader. JarLoader has provision for closing file handles, so choosing a JarLoader will solve the problem. Secondly the constructor of JarLoader blindly adds a prefix and suffix to the provided URL to make it look like a jar URL. Changed the code here to conditionally append/prepend The change set can be found at http://cr.openjdk.java.net/~shirishk/7183373/webrev.0/ -Shirish