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
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 lik
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 Gree
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
classifi
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 B
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 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 ErrorHa
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
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:
AsyncHttp
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 hand
10 matches
Mail list logo
