Hi ,
Please review the code change for below issue.
Webrev : http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html
BugId : https://bugs.openjdk.java.net/browse/JDK-8179905
This issue is duplicate of "JDK-8165437", where pushed code change
failed on 32 bit platforms so we rever
This looks fine to me Vyom.
Thanks,
Michael
On 09/05/2017, 10:55, Vyom Tewari wrote:
Hi ,
Please review the code change for below issue.
Webrev :
http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html
BugId : https://bugs.openjdk.java.net/browse/JDK-8179905
This issue is du
Hello,
Please review the following change:
http://cr.openjdk.java.net/~prappo/8179021/webrev.00/
Along with refactoring this change contains a number of critical fixes for
WebSocket. Critical fixes are applied to Receiver, WebSocketImpl and
OpeningHandshake.
Also this change removes 2 conveni
Hi Pavel,
A few nits:
jdk/incubator/http/WebSocket.java:
line 501: should use {@linkplain
Also (line 46 and 501) the link target #sendClose may cause trouble
if sendClose is overloaded - so I wonder if it may be better to
have the full prototype there:
#sendClose(int, String)
(though I gue
Hi,
doesn't this need to consider numerical overflows, e.g., what happens if
someone sets a timeout value near 0x7fffL before and after
this change?
/Claes
On 2017-05-09 11:55, Vyom Tewari wrote:
Hi ,
Please review the code change for below issue.
Webrev :
http://cr.openjdk.
Hi Claes,
thanks for review, timeout is "int" so even if you set max(2147483647)
value that int data type can hold, there will not be any overflow. If
you try to set very large number like "0x7fff" to int data
type you will get compile time error(integer number too large:
7fff
