Hi everyone,
could you please review my change for JDK-8035158?
DefaultProxySelector uses sun.misc.RegexpPool to parse properties that
configure the proxy settings. This code should be changed to use
java.util.regex public API so that the classes in sun.misc.Regex* can be
removed.
http://cr
s changes is pushed, JDK-8037781: "Remove
> sun.misc.Regexp* classes", can proceed.
>
> -Chris.
>
> On 19/03/14 18:03, Pavel Rappo wrote:
>> Hi everyone,
>>
>> could you please review my change for JDK-8035158?
>>
>> DefaultProxySelector
Hi everyone,
could you please review my change for JDK-8037396:
http://cr.openjdk.java.net/~michaelm/8037396/webrev/
As per API, getQuery() and getFragment() should return the decoded string. But
this seems not to work properly if there are squared brackets around them.
The result of analysis
Hi everyone,
Could you please review my change for JDK-8024832?
http://cr.openjdk.java.net/~prappo/8024832/webrev.00/
Thanks
-Pavel
Basically that's what the attached test verifies.
-Pavel
On 27 May 2014, at 10:49, Michael McMahon wrote:
> On 27/05/14 10:40, Pavel Rappo wrote:
>> Hi everyone,
>>
>> Could you please review my change for JDK-8024832?
>>
>> http://cr.openjdk.java.net/~p
tYetBoundException.
If it's not a concern I'm happy to remove this check.
-Pavel
On 27 May 2014, at 11:03, Alan Bateman wrote:
> On 27/05/2014 10:40, Pavel Rappo wrote:
>> Hi everyone,
>>
>> Could you please review my change for JDK-8024832?
>>
Hi everyone,
Could you please review my change for JDK-8027308?
http://cr.openjdk.java.net/~prappo/8027308/webrev.00/
The issue in question actually consists of 2 issues. The first one is about
supporting zone id syntax in URIs. Which is described in [1]. The second one is
about handling link-
ddress included, is efficient.
>
> I think a test case should be possible for this also.
>
> - Michael.
>
> On 09/06/14 06:40, Chris Hegarty wrote:
>> This looks good to me Pavel.
>>
>> -Chris.
>>
>> On 6 Jun 2014, at 18:42, Pavel Rappo wrote:
>>
Alan, it looks simpler, indeed:
http://cr.openjdk.java.net/~prappo/8027308/webrev.01/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java.sdiff.html
I have removed the StringBuilder completely. It doesn't seem to be a
performance critical part of the code :) But from the readabilit
neId would be nice as well.
>
> cheers
> Andreas
>
> On 09.06.2014 19:06, Pavel Rappo wrote:
>> Alan, it looks simpler, indeed:
>>
>> http://cr.openjdk.java.net/~prappo/8027308/webrev.01/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java.sdiff.html
&
Hi Max,
I don't see any particular reason for this. Maybe it's just a "precaution". It
seems to me it's the only field
of the URL class set directly (without setter) from an outside.
Does it hurt performance a lot? In what cases?
-Pavel
> On 25 Nov 2014, at 12:02, Wang Weijun wrote:
>
> I am
s hard to imagine the opposite).
-Pavel
> On 25 Nov 2014, at 12:58, Wang Weijun wrote:
>
>
>> On Nov 25, 2014, at 20:25, Pavel Rappo wrote:
>>
>> Hi Max,
>>
>> I don't see any particular reason for this. Maybe it's just a "precaution"
> On 25 Nov 2014, at 14:03, Mark Sheppard wrote:
>
> I think this raises a more fundamental question, as to why the URL
> hashCode() and equals() methods delegates to URLStreamHandler
> in the first place? rather than performing the processing within the URL
> class itself, and synchroniz
Peter, thanks a lot for the link and such a detailed explanation. I've been
working with URL/URLStreamHandler recently to make them "modularization ready"
and have noticed some of the problems you were talking about as well. I do
think we should make our best effort to fix it. Give me some time
Hi everyone,
Could you please review my change for JDK-8064925?
http://cr.openjdk.java.net/~prappo/8064925/webrev.01/
The main goal is to see if the proposed spec change and the overall approach are
correct.
---
So what
Thanks Alan. Both issues are fixed now, webrev updated in place.
> On 24 Jun 2015, at 12:31, Alan Bateman wrote:
>
>
>
> On 24/06/2015 12:08, Pavel Rappo wrote:
>> Hi everyone,
>>
>> Could you please review my change for JDK-8064925?
>>
>> http
> Can you please add a license header to the service descriptor file
Done in place.
> Thanks, I think it looks good now. Do you want to finalize the changes now?
Spec & code changes? Yes. Test? No. There are some things that still need to be
done for sufficient test coverage.
Hi,
I would appreciate if you help to review a WebSocket client API proposed for
JDK 9. This work is a part of JEP-110 [1] and has started its public path with
HTTP client review in March this year [2].
Proposed WebSocket API is relatively small and focuses on convenient exchange of
data in a ful
Hi Joakim,
First of all, thank you so much for such a comprehensive list of questions! I'll
try to answer them to the best of my knowledge.
But before, I need to clarify one thing. I've noticed many of the questions are
about lack of some advanced features in the API. Well, they are for sure
nego
Hi Roger, thanks for looking at this!
> On 1 Sep 2015, at 17:05, Roger Riggs wrote:
>
> - The Incoming class combines separate functions that would be easier to
> use if the methods were directly on the Builder.
...
> |WebSocket ws = WebSocket.newBuilder("ws://websocket.example.com")
> .onRec
Hi Andrej, thanks for your reply!
> On 2 Sep 2015, at 21:17, Andrej Golovnin wrote:
>
> Just because you don’t see usages for it, it does not mean that others don’t
> need
> it.
I couldn't agree more. That's the main reasons we have this review. To tease out
things we've completely forgotten,
> On 8 Sep 2015, at 18:27, Michael McMahon wrote:
>
> On 08/09/15 17:29, Simone Bordet wrote:
>> Where is TLS support ? Let's not make the same mistake already done in
>> javax.websocket :) Thanks !
>
> I notice it doesn't say so explicitly but "wss" urls are supported, and the
> relevant co
Hi Simone, thanks for looking at this!
> On 8 Sep 2015, at 17:29, Simone Bordet wrote:
>
> Uh, please no.
>
> JDK 9 will like ship juc.Flow, so I would recommend to base on that
> API rather than reinventing a new API every time to do backpressure.
1. To be honest, I don't think Flow API is a
Hi Simone, thanks. I'm currently looking into this.
> On 8 Sep 2015, at 21:18, Simone Bordet wrote:
>
> Hi,
>
> On Tue, Sep 8, 2015 at 8:34 PM, Pavel Rappo wrote:
>> Hi Simone, thanks for looking at this!
>>
>>> On 8 Sep 2015, at 17:29, Sim
Hi Richard, thanks a lot for having a look at this.
> On 11 Sep 2015, at 00:41, Richard Warburton
> wrote:
>
> Thanks a lot for implementing this by the way - I can see that it would be a
> useful API for many people.
That's the main problem (as usual though). Different people have different
endly
---
[1] https://bugs.openjdk.java.net/browse/JDK-8138949;
That doesn't mean the default implementation won't support
'permessage-deflate'.
-Pavel
> On 31 Aug 2015, at 15:30, Pavel Rappo wrote:
>
> On 8 Oct 2015, at 20:51, Simone Bordet wrote:
>
> What it is still missing is the fact that there is no specification
> about the onXXX methods regarding the lifecycle of the parameters
> passed in.
There is, actually. I have put it as a top-level javadoc, not as a javadoc to
each single meth
Hi Simone,
> On 8 Oct 2015, at 20:51, Simone Bordet wrote:
>
> The *API* should provide a callback to notify when the ByteBuffer has
> been consumed.
Here is a proposed mechanism for managing buffers used by Listener.
1. WebSocket.Builder gets 2 new methods (may not be an actual javadoc):
uture as a means of
asynchronous completion signalling
* StatusCode is now ClosureCode
-Pavel
> On 31 Aug 2015, at 15:30, Pavel Rappo wrote:
>
> Hi,
>
> I would appreciate if you help to review a WebSocket client API proposed for
> JDK 9. This work is a part of JEP-110
> On 16 Oct 2015, at 22:11, Simone Bordet wrote:
>
> Hi,
>
> On Fri, Oct 16, 2015 at 12:35 PM, Pavel Rappo wrote:
>> Hi,
>>
>> Here's a second update on the WebSocket API:
>>
>> webrev: http://cr.openjdk.java.net/~prappo/8087113/webrev.0
Hi Joakim,
> On 17 Oct 2015, at 22:42, Joakim Erdfelt wrote:
>
> You are required, per the RFC6455 spec, to validate incoming and outgoing
> TEXT messages are valid UTF8.
> (also Handshake and Close Reason Messages)
>
> http://tools.ietf.org/html/rfc6455#section-8.1
>
> Relying on the JVM bui
Hi Joakim,
> On 20 Oct 2015, at 13:50, Joakim Erdfelt wrote:
>
> You know that CharBuffer doesn't actually do UTF8, right?
> It's just a ByteBuffer split into equal 2 byte segments.
> CharBuffer is a way to obtain char (the 2 byte number, not the character)
> from the ByteBuffer or String you c
Hi Joakim,
> On 20 Oct 2015, at 14:37, Joakim Erdfelt wrote:
>
> But we *think* we understand what you are trying to do.
>
> Here's a split UTF8 scenario (just whipped up)
> https://gist.github.com/joakime/e34b727a6989ca7cef94
>
> So the JVM implementation side will take the raw bytes (presuma
> On 19 Oct 2015, at 22:37, Simone Bordet wrote:
>
> Now I am confused :)
>
> Are you saying that if you do:
>
> builder.headers("foo", "bar", "baz").headers("one", "two", "three")
>
> then "foo", "bar" and "baz" are removed ?
In the current version it is exactly like you've said. And we're
> On 20 Oct 2015, at 14:32, Simone Bordet wrote:
>
> So why choosing CharBuffer ?
Because in general when an API provides a callback method `c`
c( x)
an application has to implement, it should better be the case that the
is the most specific type possible (with possibly more methods
and
> On 21 Oct 2015, at 12:18, Simone Bordet wrote:
>
> I really hope you meant that Listener is like Flow.Subscriber.
It's obviously a typo. Thanks!
Listener ~ Subscriber
WebSocket ~ Publisher
FlowController ~ Subscription
> On 21 Oct 2015, at 12:18, Simone Bordet wrote:
>
> Speaking of analogies, it's pretty common to implement Publisher *and*
> Subscription in the same class when you can only have one listener,
> which is exactly the WebSocket case.
Well, maybe, I don't know. But implementing interfaces A and B
Hi,
Could you please review my change for JDK-8087113
http://cr.openjdk.java.net/~prappo/8087113/webrev.03/
This webrev contains initial implementation and basic tests for WebSocket API.
Specification conformance & interoperability testing has been performed with
Autobahn Testsuite [1]. As fo
> On 26 Mar 2016, at 11:44, Andrej Golovnin wrote:
>
> src/java.httpclient/share/classes/java/net/http/RawChannel.java
>
> When you don’t plan to have any subclasses of RawChannel, then
> please mark it as final.
>
> 43 private boolean closed;
>
> I think this field should be volatile.
>
> On 29 Mar 2016, at 20:16, Andrej Golovnin wrote:
>
> JEP-280 does not apply in this case. But when you rewrite this code to
> use the plain String concatenation, then JEP-280 would apply:
>
> 211 static String toString(Buffer b) {
> 212 return toStringSimple(b)
> 214
Hi Chris,
> On 31 Mar 2016, at 17:35, Chris Hegarty wrote:
>
> I’ve looked at the API a number of times, and overall I’m happy with it
> ( modulo the known open issues ). Some initial comments.
Thanks a lot for looking into this!
> Generally, I prefer javadoc style comments on members. Even it
Hi Anthony, thanks a lot for looking into this!
> On 3 Apr 2016, at 17:45, Anthony Vanelverdinghe
> wrote:
>
> Here are my suggestions concerning the public types:
>
> java.net.http.WebSocket
> - order the arguments of
> static Builder newBuilder(URI uri, HttpClient client, Listener listener)
Hi Simone, thanks for deep dive into this!
> On 3 Apr 2016, at 18:43, Simone Bordet wrote:
>
> Throwing exceptions.
> ---
> Given that the API is making use of CompletableFuture, throwing
> exceptions instead is in my experience not the right thing to do.
> You want to communicate failure via t
Hi Roger, thanks for looking into this.
> On 5 Apr 2016, at 17:37, Roger Riggs wrote:
>
> It would be helpful if the classnames/filenames reflected the participation
> in the WebSocket implementation
> to keep them distinct from the HTTP 2.0 implementation in the same directory.
> For example,
Hi Simone,
> On 5 Apr 2016, at 21:16, Simone Bordet wrote:
>
> Hi,
>
> Sure, the caller must not block.
> But there is no need to dispatch to achieve that when all code is
> non-blocking already.
Sorry, could you please explain this to me in more detail? I'm not sure I'm
following.
Let's sup
Hi,
Could you please review my change for JDK-8153353?
http://cr.openjdk.java.net/~prappo/8153353/webrev.00/
This is an implementation of HPACK (Header Compression for HTTP/2) [1]
Internal API classes are (package sun.net.httpclient.hpack):
Encoder, Decoder and DecodingCallback
Example of
Hi again Simone :-)
> On 6 Apr 2016, at 20:31, Simone Bordet wrote:
>
> 1) Add a test for the decoder where you have the incoming bytes be
> passed 1 at the time to the decoder.
> Something like:
>
> ByteBuffer data = ByteBuffer.wrap(new byte[]{
>0b, // literal, index=15
> On 4 Apr 2016, at 18:16, Anthony Vanelverdinghe
> wrote:
>
>>> - CompletableFuture sendClose(CloseCode code, CharSequence reason)
>>> change the type of "reason" to String
>> What's the rationale behind this?
> Unlike with the sendText methods, I don't see the added value here. For
> example
> On 6 Apr 2016, at 21:28, Roger Riggs wrote:
>
>>> Reader.java:
>>> - line 137: Why should the reader force a new task? Should it be left to
>>> the subscriber to
>>>decide whether its processing is lightweight and can be done immediately
>>> or to re-submit to its own executor.
>>>
>>
> On 7 Apr 2016, at 11:20, Simone Bordet wrote:
>
> Can I ask how you guys apply webrevs to the JDK 9 source tree ?
> I would prefer to review in an IDE rather than in textual mode, but I
> have not found instructions on how to apply a webrev to a source tree.
Sure, each webrev should contain a
Hi Roger, thanks for looking into this!
Changes are done in-place.
Do you think issues marked as [*] could be addressed incrementally after the
initial push?
> On 11 Apr 2016, at 16:18, Roger Riggs wrote:
>
> Hi Pavel,
>
> Though this is an implementation only package, it could use a few mor
> On 12 Apr 2016, at 16:56, Roger Riggs wrote:
>
> Since you have a TestHelper class you could put it there and not duplicate
> the code in several tests.
Thanks! Done.
http://cr.openjdk.java.net/~prappo/8153353/webrev.00/test/java/net/httpclient/http2/java.httpclient/sun/net/httpclient/hpack
> On 12 Apr 2016, at 19:47, Chris Hegarty wrote:
>
>>> On 12 Apr 2016, at 16:56, Roger Riggs wrote:
>>>
>>> Since you have a TestHelper class you could put it there and not duplicate
>>> the code in several tests.
>>
>> Thanks! Done.
>>
>> http://cr.openjdk.java.net/~prappo/8153353/webrev.0
> On 13 Apr 2016, at 10:10, Chris Hegarty wrote:
>
> A general comment; Quite a number of classes, especially Encoder and Decoder,
> would benefit from a few relatively lightweight comments, e.g. IntegerReader
I would like to address it after the initial push. If possible. Other than that,
I ha
Hi,
Could you please review my change for JDK-8154487?
http://cr.openjdk.java.net/~prappo/8154487/webrev.00/
This shows up only on Windows machines where EOL is '\r\n' rather than '\n'.
I used '\n' as a line separator in expected table state strings in the tests
(e.g. [1]). At the same time act
/testsuite/
> On 25 Mar 2016, at 16:21, Pavel Rappo wrote:
>
> Hi,
>
> Could you please review my change for JDK-8087113
>
> http://cr.openjdk.java.net/~prappo/8087113/webrev.03/
>
> This webrev contains initial implementation and basic tests for WebSo
> On 5 May 2016, at 00:20, Jitendra Kotamraju wrote:
>
> * I see that there is an issue for autoponging. May be this falls under it.
> The default impl of onPing() doesn't send PONG for *every* received PING.
Yes, that's correct. The default implementation sends a Pong in response to a
receive
[1] https://bugs.openjdk.java.net/browse/JDK-8155621
> On 5 May 2016, at 21:28, Simone Bordet wrote:
>
> Hi,
>
> On Tue, May 3, 2016 at 5:23 PM, Pavel Rappo wrote:
>>
>> Hello,
>>
>> Here's an updated webrev
> On 6 May 2016, at 09:16, Felix Yang wrote:
>
> Hi Pavel,
> several comments:
>
> 1. WebSocket.request(long n) is documented as "
>
> @throws IllegalArgumentException if n < -1
> "
>
> It looks meaningless to allow 0.
First of all, the way `request` is defined now is by no means meanin
Hi Simone,
> On 4 Apr 2016, at 20:07, Simone Bordet wrote:
>
> In my experience, once you get rid of exception throwing in async API
> everything becomes much simpler, especially "deep" exceptions related
> to invalid implementation internal states.
Am I right saying that you propose that all e
Hi Michael,
Is there any reason why you don't throw the wrapped `Throwable`
unconditionally?
Thanks.
@@ -144,14 +144,11 @@
}
}
-static Object getProxy(int port, boolean b) throws Exception {
+static Object getProxy(int port, boolean b) throws Throwable {
try {
This looks good, Michael. Thanks.
> On 16 May 2016, at 12:07, Michael McMahon
> wrote:
>
> Could I get the following change reviewed please? There are three small
> changes
>
> 1) enhancements to RawChannel API used by websocket implementation
>
> 2) fix the test case problem where channel m
Hi,
Could you please review the following change for JDK-8156742?
http://cr.openjdk.java.net/~prappo/8156742/webrev.01/
This change addresses the first group of WebSocket API refinements and
enhancements from [1].
1. Change method `Builder#connectTimeout(long, TimeUnit)` to
`Builder#connectTim
Hi Simone, many thanks for taking a close look at this!
> On 31 May 2016, at 23:05, Simone Bordet wrote:
>
> * What is interface Text for ?
> If it does perform a bytes-to-chars conversion, then offering
> asByteBuffer() can be easily done by the application.
> A websocket implementation must ch
user, so I
would like to listen to people who have it (like yourself). YAGNI is one of my
favorite arguments though! It makes the implementation effort feel lighter.
Thanks,
-Pavel
> On 31 May 2016, at 23:05, Simone Bordet wrote:
>
> Pavel,
>
> On Tue, May 31, 2016 at 7:25 PM, Pav
Simone,
> On 1 Jun 2016, at 18:31, Simone Bordet wrote:
>
> I'm not sure it's worth encouraging to write application data from a
> onPing() or onPong() listener.
> My take on the issue is that upon receiving a Ping, the implementation
> should send a Pong "as soon as it is practical".
> I don't
Simone,
> On 31 May 2016, at 23:05, Simone Bordet wrote:
>
> I think this class exposes too many failure codes that applications
> *must not* be able to use.
> For example, 1002 is not something that the application can ever send,
> only the implementation can, and having a public API to create
> On 2 Jun 2016, at 13:00, Simone Bordet wrote:
>
> Furthermore, I'm not convinced there should be a parameterless sendClose().
> The WebSocket protocol itself *mandates* that the Close message must
> have a code
Regardless of your API proposal, where did you find that in the RFC?
Here's what I
Hi,
Could you please review the following change for JDK-8156650?
http://cr.openjdk.java.net/~prappo/8156650/webrev.01/
This change addresses some WebSocket API refinements and enhancements from [1].
1. Remove method `WebSocket#sendText(ByteBuffer message, boolean isLast)`
This API sees Text m
Simone,
> On 2 Jun 2016, at 14:09, Simone Bordet wrote:
>
> I am not opposed to have a utility method sendClose() parameterless,
> but I don't think that it's worth an Optional in onClose(), given the
> semantic defined by 7.1.5.
It all boils down to how apps use contents of Close messages they
et-dev/2015-October/009248.html
[2] http://mail.openjdk.java.net/pipermail/net-dev/2015-October/009242.html
> On 2 Jun 2016, at 21:58, Simone Bordet wrote:
>
> Hi,
>
> On Thu, Jun 2, 2016 at 10:40 PM, Pavel Rappo wrote:
>> 1. Are there any cases where the app needs to know
> On 3 Jun 2016, at 14:58, Simone Bordet wrote:
>
> The implementation should reply to a Close frame with a Close frame
> with the same code.
> Applications do not need to call sendClose() from within onClose().
It's just this thing can be done. We can't prohibit sending a Close message from
wi
Hi,
Could you please review the following change for JDK-8156693?
http://cr.openjdk.java.net/~prappo/8156693/webrev.01/
This change addresses some WebSocket API refinements and enhancements from [1].
WebSocket returns `CompletableFuture` from some of its methods. CFs are used by
an implementati
> On 7 Jun 2016, at 18:42, Roger Riggs wrote:
>
> Hi Pavel,
>
> Looks fine.
>
> WebSocket.java:
> - line 82: I'd replace 'never' with 'does not'; it is more like a statement
> for fact and less a guarantee.
>
> - LIne 54: The notation "{@code .onX}" seems unnecessary, is quite cryptic,
> a
Hi,
Could you please review the following change for JDK-8157273?
http://cr.openjdk.java.net/~prappo/8157273/webrev.01/
This change addresses some WebSocket API refinements and enhancements from [1].
Currently WebSocket API allows only one scheduled but not yet sent message (i.e.
an outstanding
“I’ve been waiting for you”
(Speaking in Darth Vader’s voice)
> On 9 Jun 2016, at 13:38, Simone Bordet wrote:
>
> I'm not sure I understand all this.
>
> I thought the idea was that you always want *at most* one outstanding write.
> Multiple writes should be chained via CS.
> Concurrent
> On 10 Jun 2016, at 11:09, Simone Bordet wrote:
>
> Hi,
>
> On Thu, Jun 9, 2016 at 3:20 PM, Pavel Rappo wrote:
>> Yes, you are correct. Here are some reasons behind this decision:
>>
>> 1. This is more friendly. One doesn't *have to* carefully build a
n chunks in
order to provide better responsiveness when needed?
Thanks,
-Pavel
> On 10 Jun 2016, at 11:09, Simone Bordet wrote:
>
> Hi,
>
> On Thu, Jun 9, 2016 at 3:20 PM, Pavel Rappo wrote:
>> Yes, you are correct. Here are some reasons behind this decision:
>>
>&g
ka once a
> fin==true is encountered in the frame queue)
>
> On Sat, Jun 11, 2016 at 4:20 AM, Pavel Rappo wrote:
> Simone,
>
> What's your opinion on how send(Ping|Pong|Close) should work? I mean with "one
> outstanding send" policy you're advocating for
Hi,
Could you please review the following change for JDK-8159039?
http://cr.openjdk.java.net/~prappo/8159039/webrev.00/
This change contains a fix for 8159039 as well as a number of tiny editorial
changes.
Thanks,
-Pavel
> On 13 Jun 2016, at 12:14, Simone Bordet wrote:
>
> To me, pings (let's leave out unsolicited pongs) are an application
> mean to measure roundtrip; because they can be interleaved at the
> protocol level, I may be interested in knowing when they are fully
> written, but I would not make this i
> On 13 Jun 2016, at 12:14, Simone Bordet wrote:
>
> Close should definitely *not* "jump ahead of the queue", it should be
> sent after queued stuff has been sent.
Why is that? Shouldn't we treat this as an implementation specific detail? I
mean Close, Ping and Pong are control messages. They a
> On 13 Jun 2016, at 14:45, Simone Bordet wrote:
>
> Because contrary to ping, the specification does not say "as soon as
> possible" but:
>
> "An endpoint MAY delay sending a Close frame until its current message is
> sent (for instance, if the majority of a fragmented message is
> already sen
equent tests. But of course it could have other negative
>> affects on itself, but somewhat limited at least.
>>
>> -Chris.
>>
>>> Naoto
>>>
>>> On 6/13/16 3:29 AM, Pavel Rappo wrote:
>>>> Hi,
>>>>
>>>> Could you
> On 13 Jun 2016, at 12:14, Simone Bordet wrote:
>
>> Should the application be in charge of chopping outgoing messages in chunks
>> in
>> order to provide better responsiveness when needed?
>
> Not sure what you mean here.
What I meant here was that Ping's latency doesn't depend on some kind
Looks good!
> On 15 Jun 2016, at 13:50, Chris Hegarty wrote:
>
> 8157045 [1] is blocking folks doing test development for WebSockets. I would
> like to push this “temporary” change, to unblock them, until we can refactor
> some
> of this area to fix what appears to be a more significant issue (
Hi,
Could you please [*] review the following change for the upcoming JDK-8159053?
This change addresses:
1. Listener.onClose/onPing behaviour, making the implementation fully*
responsible of protocol compliance. So reactions on onClose/onPing cannot be
overridden/redefined in a Listener
2. Simp
} if already done
*/
default CompletionStage onPing(WebSocket webSocket,
ByteBuffer message) {
webSocket.request(1);
return null;
}
> Begin forwarded message:
>
> From: Pavel Rappo
> Subject: Preliminary RFR JDK-8159053: Improve onPing/onClose beha
Hi Vyom, thanks for looking into this!
0. * Copyright (c) 2013,2016 Oracle and/or its affiliates. All rights reserved.
If I understand correctly, we're not required to update years in the header
manually. But if you decided to do so, please follow the established pattern (in
both files you've ch
Vyom, please consider the following changes:
1. Append 8071660 to the lists of tests here:
* @bug 8010464 8027570 8027687 8029354 8071660
^
2. Reformat the code the way it's in the rest of the file:
from:
266 URLPermission that = (
enjdk.java.net/%7Evtewari/8114860/webrev0.1/index.html>). I
> incorporated the review comments and remove the "HashCodeTest" where it
> compares the hashcode with hard coded hashcode.
>
> Thanks,
> Vyom
>
>
> On Monday 20 June 2016 03:57 PM, Pavel Rappo wro
Same here. I got this only after I had a look at the history of changes.
> On 20 Jun 2016, at 17:53, Vyom Tewari wrote:
>
> I was not expecting that hashcodetest is testing NPE by comparing the
> "hardcoded" hash values.
I
> reverted the commented "hashtest" test.
>
> Thanks,
> Vyom
>
>
> On Monday 20 June 2016 10:53 PM, Pavel Rappo wrote:
>> Same here. I got this only after I had a look at the history of changes.
>>
>>> On 20 Jun 2016, at 17:53, Vyom Tewari wr
* completion of the returned {@code CompletionStage} or the last part
>* of the current message has been sent.
>
> Otherwise, the simplifications are welcome.
>
> -Chris.
>
>> On 17 Jun 2016, at 16:15, Pavel Rappo wrote:
>>
>> Hi,
>>
>> Could
Pavel
[*] Please note that onClose/sendClose/onPing changes will be addressed in the
upcoming https://bugs.openjdk.java.net/browse/JDK-8159053
> On 31 May 2016, at 18:25, Pavel Rappo wrote:
>
> Hi,
>
> Could you please review the following change for JDK-8156742?
>
>
Hi,
Here's the updated wording. Could you please have a look at it once again so we
fully agree on it?
What has changed?
1. "WebSocket implementation"/"WebSocket connection" -> {@code WebSocket}
2. "Automatically" added to make it clear no user actions needed
3. Fixed typos mentioned by Chris.
4
Thanks Joakim,
Yes, that's the plan. I would also add 1015.
Thanks,
-Pavel
> On 22 Jun 2016, at 13:50, Joakim Erdfelt wrote:
>
> On Wed, Jun 22, 2016 at 5:39 AM, Pavel Rappo wrote:
> *. Please notice the difference between range of status codes accepted in
> `send
Hi Roger,
Thanks for having a look at this!
> On 22 Jun 2016, at 18:03, Roger Riggs wrote:
>
> Hi Pavel,
>
> in general, this treatment is fine, some comments below,
>
>> * When a Close message has been received, the WebSocket Protocol
>> * mandates it is handled in a certain way.
> 'a cer
Simone,
> On 23 Jun 2016, at 14:48, Simone Bordet wrote:
>
> I think you should not use the word "client" since it's not clear if
> you refer to the application or the implementation.
> Here it can be mistaken for both, but it's really the implementation.
> However, the readers of the Javadocs w
1 - 100 of 236 matches
Mail list logo
