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
> 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,
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/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
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
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.
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
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
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
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
* 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
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:
> 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
13 matches
Mail list logo
