Hi,
We found that 8035653 test from jdk9 [1] crashes jdk8u152-b01 on windows
at this point [2] because "ia6_class" is not initialized.
It looks like the following bit of 8035653 is missed in jdk8u152-b01:
diff -r 83726fe0f756
src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
---
m: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
Alex Kashchenko
Sent: Donnerstag, 23. März 2017 00:51
To: net-dev@openjdk.java.net
Subject: [PATCH] 8035653: jdk8u152-b01 windows crash on
DatagramSocket.getLocalAddress
Hi,
We found that 8035653 test from jdk9 [1] crashes jdk8u
Hi,
Please review the backport of JDK-8183369 to 11u:
Bug: https://bugs.openjdk.java.net/browse/JDK-8183369
Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0
11u webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/
Patch to HttpURLConnection applies cleanly
that.
Sorry for tabs on that line, not sure how they got there, updated webrev
after :retab :
http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.01/
Best regards
Christoph
-Original Message-
From: jdk-updates-dev On
Behalf Of Alex Kashchenko
Sent: Dienstag, 24. März 2020 12:29
To
Sent: Wednesday 1 April 2020 16:03
To: Michael McMahon ; Alex Kashchenko
Cc: Mark Sheppard ; net-dev@openjdk.java.net >> OpenJDK
Network Dev list
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
file is not found
Hi Michael et al.,
just looking
On 05/06/2020 01:11 PM, Michael McMahon wrote:
Hi,
Yes, we've had some discussion about it internally, and while others may
yet have an opinion, I think this approach is a reasonable one, with a
spec change
that captures the behavior.
The main thing we need to capture is that while connect()
Thanks for your comments!
On 05/08/2020 06:38 PM, Michael McMahon wrote:
[...]
https://bugs.openjdk.java.net/browse/JDK-8244650
I believe some sort of spec change will be needed, if only to justify
challenging the JCK. Currently, the proposed change trips the following
test:
TestCase: [Jar
Hi,
On 05/12/2020 12:20 AM, Alex Kashchenko wrote:
CSR: https://bugs.openjdk.java.net/browse/JDK-8244650
A question about this CSR: after this new issue was found in the same area:
JDK-8246714: URLClassLoader/JAR protocol handler poisons the global
JarFile cache under concurrent load
On 06/10/2020 03:52 PM, Alex Kashchenko wrote:
Hi,
On 05/12/2020 12:20 AM, Alex Kashchenko wrote:
CSR: https://bugs.openjdk.java.net/browse/JDK-8244650
A question about this CSR: after this new issue was found in the same area:
JDK-8246714: URLClassLoader/JAR protocol handler poisons the
Hi,
CSR: https://bugs.openjdk.java.net/browse/JDK-8244650
On 06/13/2020 10:49 PM, mark sheppard wrote:
Hi,
For JDK-8132359 it now addresses the issue:
Amend JarURLConnection::getJarFile() to return JarFile object reference for
nonexistent JAR file entry URL
The scenario addressed is that
Hi,
On 3/1/20, Alex Kashchenko wrote:
> Hi,
>
> Please review the fix to JDK-8232854 for 11u:
>
> Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854
>
> Webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.00/
>
> Patch is implemented based on a
Hi,
On 8/13/21, Michael McMahon wrote:
> Hi,
>
> A question about this issue. Can you explain why the server/proxy is
> sending a response body to a HEAD request?
>
> My reading of the RFCs suggests this is not allowed.
Thanks for your comment and sorry for the late reply. To put aside the
quest
On 8/23/21, Alex Kashchenko wrote:
> Hi,
>
> On 8/13/21, Michael McMahon wrote:
>> Hi,
>>
>> A question about this issue. Can you explain why the server/proxy is
>> sending a response body to a HEAD request?
>>
>> My reading of the RFCs suggests thi
13 matches
Mail list logo
