just
WebSocket.newBuilder(String). And please use the class java.net.Proxy to define
a proxy and not just a String and a InetSocketAddress as it is done in
HttpClient.
Best regards,
Andrej Golovnin
e this helps.
Best regards,
Andrej Golovnin
to ensure that firewalls do not close inactive (from
their point of view) connections. And we send some useful data with
the ping which is then processed on the server. Currently all pong
messages from the server are ignored on the client.
Best regards,
Andrej Golovnin
cient for us.
Best regards,
Andrej Golovnin
g. 4001). Depending on the status
code we show the user appropriate messages and the reason submitted by
the administrator.
What we also need, is the method WebSocket.close(int statusCode,
String reason) because the client may also close the connection for
some application specific reason.
Best regards,
Andrej Golovnin
WebSocket.Incoming.onBinary(WebSocket, ByteBuffer),
then no. I expect that this method is only used to process binary
message. For pong messages I would expect a new method:
WebSocket.Incoming.onPong(WebSocket, ByteBuffer). Currently we don't
process the pong messages on the client. And there are no plans to do
it in the near future.
Best regards,
Andrej Golovnin
ient.getDefault() to make clear the behaviour of the
created/returned HttpClient.
Best regards,
Andrej Golovnin
= requireNonNull(subscription)).request(1);
Code like this is difficult to read and understand. Maybe you should rewrite it
using two lines of code.
test/java/net/httpclient/HandshakePhase.java
The copyright header is missed.
Best regards,
Andrej Golovnin
Proxy p;
@@ -198,9 +199,9 @@
}
@Override
-public synchronized List select(URI uri) {
-String scheme = uri.getScheme().toLowerCase();
-if (scheme.equals("http") || scheme.equals("https")) {
+public List select(URI uri) {
+String scheme = uri.getScheme();
+if (scheme.equalsIgnoreCase("http") ||
scheme.equalsIgnoreCase("https")) {
return list;
} else {
return NO_PROXY_LIST;
Best regards,
Andrej Golovnin
I don’t need to call the #orTimeout()-method on every CompletableFuture
returned by
the #sendXXX-methods. But I think the usage the #orTimeout-method is also OK.
BTW, someone should describe in the JavaDocs of CompletableFuture#orTimeout()
what would happen when this method is called multiple times on
> On Sun, Apr 10, 2016 at 2:00 PM, Andrej Golovnin
> wrote:
>> BTW, someone should describe in the JavaDocs of CompletableFuture#orTimeout()
>> what would happen when this method is called multiple times on the same
>> CompletableFuture with different arguments.
>
>
Client branch in the JDK sandbox repository
which adds PATCH to the HttpRequest builder:
java_net_http_HttpRequest_PATCH_method.diff
Best regards,
Andrej Golovnin
java_net_HttpURLConnection_PATCH_method.diff
Description: Binary data
java_net_http_HttpRequest_PATCH_method.diff
Description
t to add it to HTTP Client, then it is
OK for me too. But I think that HttpURLConnection should be changed.
Best regards,
Andrej Golovnin
}
void reset() { startTime.set(0); }
}
Best regards,
Andrej Golovnin
s and
at the wrong times; premature optimization is the root of all evil (or at
least most of it) in programming. ;-)
Best regards and have a nice weekend,
Andrej Golovnin
Hi Daniel,
> Right - here is a better implementation anyway:
> http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.02/
>
Looks much better. Thanks a lot!
Best regards,
Andrej Golovnin
16 matches
Mail list logo
