Re: RFR 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec

Hi Pavel, Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8114860/webrev0.2/index.html ). I reverted the commented "hashtest" test. Thanks, Vyom On Monday 20 June 2016 10:53 PM, Pavel Rappo wrote: Same

Re: RFR 8144008: Setting NO_PROXY on an URLConnection is not complied with

Yom, Looking at this again, with fresh eyes, before pushing it for you. I think the change would be clearer if it explicitly used Proxy.NO_PROXY, rather than relying on the fact that the `proxy` field is initialized to NO_PROXY. Since the intent here is to ALWAYS make an non-proxied connection. @

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

I think this is good. Just some ideas to simplify the wording. * After a Close message has been received, the implementation will * close the connection automatically. However, the client may finish * sending the current sequence of partially sent message parts, if any. * To faci

Re: RFR 8144008: Setting NO_PROXY on an URLConnection is not complied with

Hi Chris, I am fine with suggested change( return new java.net.Socket(Proxy.NO_PROXY)); )as this will improve the code readability. Thanks, Vyom On Tuesday 21 June 2016 01:38 PM, Chris Hegarty wrote: Yom, Looking at this again, with fresh eyes, before pushing it for you. I think the change

Re: RFR 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec

Looks good to me. Thanks. > On 21 Jun 2016, at 08:10, Vyom Tewari wrote: > > Hi Pavel, > > Please find the updated > webrev(http://cr.openjdk.java.net/~vtewari/8114860/webrev0.2/index.html > ). I > reverted the commented "ha

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

Thanks Chris, I will update the wording and prepare the actual RFR. > On 21 Jun 2016, at 09:43, Chris Hegarty wrote: > > I think this is good. > > Just some ideas to simplify the wording. > >* After a Close message has been received, the implementation will >* close the connection aut

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

Hi Pavel, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8071660/webrev0.4/index.html ). I had incorporated the review comments. Thanks, Vyom On Monday 20 June 2016 07:27 PM, Pavel Rappo wrote: Vyom, pl

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

The code changes look fine, but the bigger question is whether we want to support actions without any ‘method’ being specified, like “:X-Bar”? Should the constructor throw IAE, or is that even possible now, it would require a spec clarification ( would that invalidate existing code already doing

Re: RFR JDK-8156742: Miscellaneous WebSocket API improvements

Hi, Let me try again to propose the following set of changes: http://cr.openjdk.java.net/~prappo/8156742/webrev.02/ The difference between this version and the previous one is that there are no controversial changes to onClose method [*]. This version also removes `sendText(Stream message)` whi

Re: RFR JDK-8156742: Miscellaneous WebSocket API improvements

> On 21 Jun 2016, at 12:21, Pavel Rappo wrote: > > Hi, > > Let me try again to propose the following set of changes: > > http://cr.openjdk.java.net/~prappo/8156742/webrev.02/ This mainly looks fine, just a small comment: - WebSocket.java "Or to close abruptly call {@link #abort()}.” Rat

Re: RFR JDK-8156742: Miscellaneous WebSocket API improvements

+1 with Chris' suggested rewording. Roger On 6/21/2016 7:45 AM, Chris Hegarty wrote: On 21 Jun 2016, at 12:21, Pavel Rappo wrote: Hi, Let me try again to propose the following set of changes: http://cr.openjdk.java.net/~prappo/8156742/webrev.02/ This mainly looks fine, just a small comme

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

On 21 Jun 2016, at 11:21, Chris Hegarty wrote: > > The code changes look fine, but the bigger question is whether we > want to support actions without any ‘method’ being specified, like > “:X-Bar”? Should the constructor throw IAE, or is that even possible > now, it would require a spec clarifi