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, 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
Hi,
Please find my small patch[1] to javadoc in java.net.URL that adresses
JDK-4906983(javadoc-fix)[2].
I signed the SCA/OCA some time ago. Feel free to check at the OCA
Signatures-List[3]
thanks to david buck for hosting this patch on cr.openjdk.java.net.
-- Sebastian Sickelmann
[1] http://cr
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
> 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
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 configuration
comes from the HttpClient that the WebSocket belongs t
Hi,
On Tue, Sep 1, 2015 at 10:45 PM, Pavel Rappo wrote:
> That's a very good question. The only way sending could be "back pressured" in
> the current API is by blocking completion of the returned
> CompletableFuture. But given the intention to provide a fully
> asynchronous
> non-blocking API,
that's true, the documentation is a bit nebulous on this issue.
but the inference is that the file descriptors are indeterminate state.
some older man pages allude to this
as per solaris man pages, close will
" If close() is interrupted by a signal that is to be caught,
it will return -1 with
On 03/09/15 09:28, Andrej Golovnin wrote:
Hi Michael,
Can you explain why you need j.n.Proxy rather than the
String/InetSocketAddress
combination proposed for HttpClient?
String is not type safe. And allowing to define proxy only for the
specific protocol is not enough from my experience. Some
On 7 Sep 2015, at 17:41, Mark Sheppard wrote:
> a couple of other considerations in the context of this issue perhaps?
>
> in this s is being duped onto fd, and part of the dup2 operation is the
> closing of fd, but
> what's is the expected state of file descriptor fd in the event of a dup2
>
On 8 Sep 2015, at 05:56, David Holmes wrote:
> Hi Sebastian,
>
> On 8/09/2015 1:54 PM, Sebastian Sickelmann wrote:
>> Hi,
>>
>> please find the link to the webrev[1] hosted at my dropbox in my first mail
>> in this thread at the buttom of this mail.
>>
>> A direkt link to the including patch
10 matches
Mail list logo
