On 21/06/2023 8:52 pm, Ron Pressler wrote:
On 21 Jun 2023, at 01:36, Peter Firmstone wrote:
I'm just disappointed that we are being prevented from reimplementing a
replacement authorization layer in Java, without any compromise from OpenJDK
it's not possible. We at least need to retain s
Hi all,
This pull request contains a backport of commit
[bdd81b31](https://github.com/openjdk/jdk/commit/bdd81b31825a9eb6a0f0883fca56a011ac2aebf8)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Sergey Bylokhov on 9 Jun 2023 and
was r
On Wed, 21 Jun 2023 16:59:22 GMT, Stuart Marks wrote:
> Are we using a convention of `implRead` or `readImpl`? Either is ok with me,
> but I think we had been using `readImpl` and similar elsewhere.
This code is already using implXXX so it's just be consistent.
-
PR Review Comment
On Wed, 21 Jun 2023 09:46:35 GMT, Alan Bateman wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added sta
On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote:
> The socket read/write JFR events currently use instrumentation of java.base
> code using templates in the jdk.jfr modules. This results in some java.base
> code residing in the jdk.jfr module which is undesirable.
>
> JDK19 added static su
The socket read/write JFR events currently use instrumentation of java.base
code using templates in the jdk.jfr modules. This results in some java.base
code residing in the jdk.jfr module which is undesirable.
JDK19 added static support for event classes. The old instrumentor classes
should be
In this PR I updated the EC key size and updated the regular expressions used
to parse the output of the jarsigner. In addition to updating default key sizes
base on Java version, I also updated the logic for determining the default
signing algorithm which is based on the version of jarsigner/ja
On Wed, 21 Jun 2023 14:10:20 GMT, Matthias Baesken wrote:
> In src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m there are a few
> JNU_CHECK_EXCEPTION macro usages that could potentially cause leaks.
Marked as reviewed by weijun (Reviewer).
-
PR Review: https://git.openjdk
In src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m there are a few
JNU_CHECK_EXCEPTION macro usages that could potentially cause leaks.
-
Commit messages:
- JDK-8310549
Changes: https://git.openjdk.org/jdk/pull/14590/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr
> In this PR, I added methods to the TransportContext class to synchronize
> access to the handshakeContext field. I also updated locations in the code
> that rely on the handshakeContext field to not be null to use the
> synchronized methods.
>
> Thanks
Matthew Donovan has updated the pull re
On Fri, 16 Jun 2023 14:58:06 GMT, Jamil Nimeh wrote:
>> Yes, socket close is a headache problem for me.
>
> There's a bit of a history with SSLSocket closures since the new handshaker
> was brought into JDK11. Some of it dealt with synchronization, others with
> properly handling full vs. half
> On 21 Jun 2023, at 01:36, Peter Firmstone wrote:
>
>
> I'm just disappointed that we are being prevented from reimplementing a
> replacement authorization layer in Java, without any compromise from OpenJDK
> it's not possible. We at least need to retain some kind of privilege action
> me
On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov wrote:
>> When using the clang compiler to build OpenJDk on Linux, we encounter
>> various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request with a new target base due to a
> merge or a r
13 matches
Mail list logo
