Re: JEP 321 surface-level comments

On 11/06/18 17:02, Chris Povirk wrote: And sorry, I only now remembered that you asked for an acknowledgement of each point. The immutable-HttpRequest change sounds good, too. No problem. I'll push the change to the sandbox, and it will be picked up the next refresh ( hopefully later this

Re: JEP 321 surface-level comments

Chris, On HttpRequest. While everything is functioning as expected, it may be possible to clean up the HttpRequest instances built through the builder, making it easier to reason about the code. It seems like a straight forward change to have WebSocket use an internal API to create its

Re: JEP 321 surface-level comments

Chris, On HttpHeaders, I'll reply to your comments on HttpResponse separately. Given the long thread, I'll try to summarize here rather and answering specific comments inline, but I have read and attempted to address each of them. As you have correctly observed, the current implementation

Re: JEP 321 surface-level comments

Hi Tobias, On 10/05/18 19:51, Tobias Thierer wrote: On Tue, May 8, 2018 at 12:35 PM Chris Povirk > wrote: Commenting inline on just a couple of points. * I second the idea of making HttpHeaders a final class, as proposed as part

Re: JEP 321 surface-level comments

Hi Chris, Tobias, Apologies for the delayed reply. I have spent a significant amount of time on this feedback, both prototyping and determining any potential impact on the API. There are a number of proposals in this email that address some of the comments, as well as explanations for those that

Re: JEP 321 surface-level comments

On Tue, May 8, 2018 at 12:35 PM Chris Povirk wrote: Commenting inline on just a couple of points. > >- I second the idea of making HttpHeaders a final class, as proposed >as part of JDK-8184274 >. While "final >