* Alan Bateman:
> This is a small change to add a method to sun.nio.ch.Net to get the
> number of bytes in the socket input buffer. The motive for adding this
> to make it possible for the socket adaptors to implement
> InputStream::available and also to support an alternative SocketImpl
> based o
On 23/01/2019 09:42, Florian Weimer wrote:
:
Do you plan to read from the socket buffer in the implementation of
available()? The problem is that even if there is currently data in the
socket buffer, further data that arrives later can clear it. I think
this can only happen as part of a connect
* Alan Bateman:
> On 23/01/2019 09:42, Florian Weimer wrote:
>> :
>> Do you plan to read from the socket buffer in the implementation of
>> available()? The problem is that even if there is currently data in the
>> socket buffer, further data that arrives later can clear it. I think
>> this can
Hi,
Please find below a fix for:
8217264: HttpClient: Blocking operations in mapper function do not
work as documented
[1] https://bugs.openjdk.java.net/browse/JDK-8217264
webrev:
[2] http://cr.openjdk.java.net/~dfuchs/webrev_8217264/webrev.00/
The issue here is that if you try to map
Hi
Could I get the following webrev reviewed please?
It is just to remove dead code from SocksSocketImpl.
Most of the code was an (unused) attempt to implement
SOCKS for ServerSockets. getLocalPort() was potentially buggy
and should not override the super class implementation.
So, that was remove
On 23/01/2019 10:55, Florian Weimer wrote:
:
Sorry, what I meant is that available() says that there are bytes, and
then when you try to read them, you get an exception because they are no
longer there. I doubt that's the intent behind the
InputStream::available specification, but as I said, it
Hello,
is this ML the correct place to report problems with HttpClient?
If not, can you please point me to the right place?
Thanks.
> On 18 Jan 2019, at 23:57, Dmitry Sivachenko wrote:
>
> Hello,
>
> I am tasting java.net.http.HttpClient with
>
> openjdk version "11.0.1" 2018-10-16
> Op
Hi Dmitry,
Thanks for reporting this.
Right - the IllegalArgumentException is a bit strange there,
and an IOException (or subclass of it) wrapping the
NumberFormatException would be more appropriate.
If you have OpenJDK author status and a JBS account then you
could log a bug at https://bugs.
On 23/01/2019 11:44, Michael McMahon wrote:
Hi
Could I get the following webrev reviewed please?
It is just to remove dead code from SocksSocketImpl.
Most of the code was an (unused) attempt to implement
SOCKS for ServerSockets. getLocalPort() was potentially buggy
and should not override the su
On 23/01/2019, 12:37, Alan Bateman wrote:
On 23/01/2019 11:44, Michael McMahon wrote:
Hi
Could I get the following webrev reviewed please?
It is just to remove dead code from SocksSocketImpl.
Most of the code was an (unused) attempt to implement
SOCKS for ServerSockets. getLocalPort() was po
Hi,
please review a small test update.
Bug: https://bugs.openjdk.java.net/browse/JDK-8217657
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/
I'd like to move the test for the correct default value of security property
"jdk.includeInExceptions" into an own testcase in the jdk.secu
> On 23 Jan 2019, at 15:32, Daniel Fuchs wrote:
>
> Hi Dmitry,
>
> Thanks for reporting this.
>
> Right - the IllegalArgumentException is a bit strange there,
> and an IOException (or subclass of it) wrapping the NumberFormatException
> would be more appropriate.
>
> If you have OpenJDK au
Hi Christoph,
it is a good idea to keep testing these two matters separately.
Could you please document in the new test that in OpenJDK
it is decided to keep this property empty?
Something like:
@comment In OpenJDK, this property is empty by default and on purpose. This
test assures the default
13 matches
Mail list logo
