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
!
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
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
Hi,
A potential simplification of the HttpResponseHeadersHandler interface is to
turn it into a functional interface:
HttpResponseHandler onHeaders(FutureHttpResponse dresp) throws
InterruptedException, ExecutionException;
[Chris, i am not sure if an interface with two methods, one default,
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
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
On Aug 23, 2012, at 5:05 PM, Chris Hegarty chris.hega...@oracle.com 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);
}
On Aug 23, 2012, at 5:16 PM, Michael McMahon michael.x.mcma...@oracle.com
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
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
