On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote:
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/java.smartcardio/unix/native/libj
On Sat, 15 Apr 2023 00:17:55 GMT, Vladimir Kozlov wrote:
>> Cesar Soares Lucas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address PR review 3. Some comments and be able to abort compilation.
>
> New test failed in tier1 on all platf
Thanks for the reply!
If it is not happening until 22 or later that gives us more time. I
understand we already had lots of years, I guess that is the problem with code
that has just worked for so many years. You don’t look at it until it breaks.
Fortunately I noticed this before it breaks…
On Sat, 15 Apr 2023 at 11:16, Eirik Bjørsnøs wrote:
> Hi,
>
> JDK-8227024 [1] and the associated CSR JDK-8227395 [2] suggests removing
> the deprecated classes in javax.security.cert.
>
> The CSR was withdrawn last year following ecosystem compatibility concerns:
>
> Given the compatibility risks
>
> Ideally javax.security.cert would have been removed a long time ago but
> the references from classes in javax.net.ssl make it difficult for both
> implementers and users of the API. So I think we are forced to kick it down
> the road for now.
>
I think we may disagree a bit on the assessment
On 17/04/2023 10:03, Eirik Bjørsnøs wrote:
Sure we can delay this a few releases, but I honestly don't see
how that will materially change the situation.
Rethinking this, perhaps there are some benefits to not introducing
this in an LTS release. Doing it in a release immediately follo
- Make functions 'static' when feasible:
- throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
- throwByName(), throwIOException() and throwNullPointerException() in
src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
- throwByName() in
src/jdk.crypto.cryptoki/shar
> Can I please get reviews for this PR?
>
> The most common and frequent use of NonEscaping Phis merging object
> allocations is for debugging information. The two graphs below show numbers
> for Renaissance and DaCapo benchmarks - similar results are obtained for all
> other applications that
Hi John, thanks for reaching out!
I just happened to notice this on the list this morning. We have a 20+
> year old commercial Java cryptographic toolkit at Entrust that we maintain
> and implement security protocols and algorithms which makes use of API’s in
> the javax.security.cert package. I
I just happened to notice this on the list this morning. We have a 20+ year
old commercial Java cryptographic toolkit at Entrust that we maintain and
implement security protocols and algorithms which makes use of API’s in the
javax.security.cert package. It is in used by many customers. It lo
I refactored tests in the test/jdk/sun/security/ssl directories to use the test
template classes.
-
Commit messages:
- 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or
SSLEngineTemplate
Changes: https://git.openjdk.org/jdk/pull/13495/files
Webrev: https://w
I refactored tests in the test/jdk/javax/net/ssl directories to use the test
template classes.
-
Commit messages:
- 8306014: Update javax.net.ssl TLS tests to use SSLContextTemplate or
SSLEngineTemplate
Changes: https://git.openjdk.org/jdk/pull/13494/files
Webrev: https://webrevs
>
> Sure we can delay this a few releases, but I honestly don't see how that
> will materially change the situation.
>
Rethinking this, perhaps there are some benefits to not introducing this in
an LTS release. Doing it in a release immediately following an LTS would
allow the wider ecosystem maxi
>
> I also be concerned that existing releases of this frameworks/libs with
> dependences on javax.security.cert.X509Certificate will be in use for some
> time.
>
Based on my interaction with ecosystem projects so far, the prevalent
sentiment seems to be "we plan to deal with this once OpenJDK rem
>
> I reached out to the BouncyCastle project [3] and they are basically OK
> with the OpenJDK project to go ahead and remove the APIs:
>
> I reached out to the Conscrypt team with a PR. While the PR cannot be
integrated in its current form, the ensuing discussion was instructive:
https://github.c
15 matches
Mail list logo
