On Mon, 28 Jul 2025 19:08:56 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge branch 'master' into 8347938
>> - KeyChoices class
>> - allow expanded to be null
On Wed, 23 Jul 2025 17:30:38 GMT, Koushik Muthukrishnan Thirupattur
wrote:
>> The method sun.security.provider.certpath.Builder#getMatchingPolicies
>> appears to have been intended as a lazy initialization of the
>> matchingPolicies field of the Builder class. However it checks for
>> "matchi
Enhance the memory management/cleanup for `ECDSASignature`.
-
Commit messages:
- Merge remote-tracking branch 'origin/master' into 8364226
- JDK-8364226: better memory management/cleanup in ECDSASignature
Changes: https://git.openjdk.org/jdk/pull/26516/files
Webrev: https://webre
On Mon, 28 Jul 2025 20:14:15 GMT, Coleen Phillimore wrote:
> This change removes the intrinsic for getClassAccessFlagsRaw for reflection
> and initializes an rawAccessFlags field in java.lang.Class instead, that Java
> code can non-natively access.
> Tested with tier1-4.
src/java.base/share/cl
This change removes the intrinsic for getClassAccessFlagsRaw for reflection and
initializes an rawAccessFlags field in java.lang.Class instead, that Java code
can non-natively access.
Tested with tier1-4.
-
Commit messages:
- The only caller for getRawClassAccessFlags in Class.java
On Tue, 10 Jun 2025 14:41:49 GMT, Weijun Wang wrote:
>> The private key encoding formats of ML-KEM and ML-DSA are updated to match
>> the latest IETF drafts at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11
>> and
>> https://datatracker.ietf.org/doc/html/
On Fri, 18 Jul 2025 15:11:20 GMT, Sean Coffey wrote:
> SSLLogger shouldn't be logging at the `ALL` level.
>
> Trivial enough edit so that both the SSLLogger `finer `and `finest `methods
> log at the `System.Logger.Level.TRACE` value
> DebugPropertyValuesTest.java edited to cover this change
T
FYI - The IETF is still mucking around with this. I *think* the
consensus in the LAMPS session in Madrid has happened, but you may want
to wait a small amount of time before going too much further.
Mike
On 7/23/2025 11:52, Wei-Jun Wang wrote:
On Jul 23, 2025, at 11:41, Sebastian Stenzel
On Fri, 25 Jul 2025 20:13:00 GMT, Bradford Wetmore wrote:
> The renegotiation wording should probably updated in both the
> SSLSocket/SSLEngine section. As was pointed out, TLSv1.3 is not a full
> renegotiation.
>
> You could soften some of the wording with something like (needs wordsmithing):
> Add a javadoc paragraph to SSLSocket.startHandshake() and
> SSLEngine.beginHandshake() methods explaining behavioral differences between
> TLSv1.3+ and TLSv1.2- versions.
Artur Barashev has updated the pull request incrementally with one additional
commit since the last revision:
Address P
On Tue, 8 Jul 2025 05:13:49 GMT, Jaikiran Pai wrote:
> Hello Matthew, In recent times we have been adding more of these
> configuration debugging into the -XshowSettings option. I'm unusure to what
> extent this option should be advertized or used for gathering such details of
> the runtime. W
Hi Sean,
Thank you for taking a look on my request for the Suggestion to Improve Debug
Messaging on CertPath.
I hadn’t received the follow-up email earlier, even though I had subscribed to
the mailing list. There was an issue with the subscription, but it's now
resolved and completed successfull
On Tue, 22 Jul 2025 16:03:59 GMT, Alan Bateman wrote:
> There are several places where "IAE" is mentioned but the methods are changed
> to throw CCE.
@AlanBateman, thanks for the tip. Pushed 10cb72cf17b, which improves Javadoc in
such places. While doing so, it also
* Ensures that `String` Ja
On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote:
> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid
> characters, but throw `CharacterCodingException` on encounter. This behavior
> cannot easily be derived from the method footprints, has been a source of
> co
On Mon, 21 Jul 2025 14:00:37 GMT, Volkan Yazici wrote:
> Would you mind elaborating on the rationale behind this preference, please?
If you look at the history of `newStringNoRepl`, you will find it's originally
added for JDK-8201276 in ca487166f4d18c162e8d8e4b2660d5d0381c5438. Since then,
`ne
On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote:
> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid
> characters, but throw `CharacterCodingException` on encounter. This behavior
> cannot easily be derived from the method footprints, has been a source of
> co
On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote:
> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid
> characters, but throw `CharacterCodingException` on encounter. This behavior
> cannot easily be derived from the method footprints, has been a source of
> co
On Mon, 21 Jul 2025 13:01:30 GMT, Chen Liang wrote:
>> `NoRepl`-suffixed `String` methods denote methods that do not replace
>> invalid characters, but throw `CharacterCodingException` on encounter. This
>> behavior cannot easily be derived from the method footprints, has been a
>> source of c
`NoRepl`-suffixed `String` methods denote methods that do not replace invalid
characters, but throw `CharacterCodingException` on encounter. This behavior
cannot easily be derived from the method footprints, has been a source of
confusion for maintainers, and is not uniformly adopted, e.g.,
`ne
19 matches
Mail list logo
