Closed breunouddanedeu closed 10 months ago
hmm what's the alternative classes in jdk17+? i think this is all that's used
import sun.security.provider.certpath.SunCertPathBuilderException;
import sun.security.validator.ValidatorException;
In installcert
case, the classes are used to check an internal JRE behavior. AFAIK there is no replacement for these classes and are still used internally. They are simply no longer publicly exposed.
I propose a simple workaround to avoid the import of these classes :
In InstallCert.java
, replace the use of the class
by using the thrown class name
:
@@ -69,9 +68,6 @@ import org.apache.commons.cli.Options;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-import sun.security.provider.certpath.SunCertPathBuilderException;
-import sun.security.validator.ValidatorException;
-
/**
* <p>
* A program to obtain SSL certificate(s) from a host and save them to a
@@ -465,9 +461,9 @@ public class InstallCert {
// Thus three distinct cases for considering a STARTTLS extension below
catch (SSLHandshakeException e) {
if (e.getCause() != null
- && e.getCause().getClass().equals(ValidatorException.class)
+ && e.getCause().getClass().getSimpleName().equals("ValidatorException")
&& e.getCause().getCause() != null
- && e.getCause().getCause().getClass().equals(SunCertPathBuilderException.class)) {
+ && e.getCause().getCause().getClass().getSimpleName().equals("SunCertPathBuilderException")) {
// this is the standard case: looks like we just got a
// previously unknown certificate, so report it and go
// ahead...
I have an issue using JRE 17,
sun.security
classes are no longer accessible.Can you remove dependency to these classes ?
For information, it is possible to work around this issue by adding
--add-exports=java.base/sun.security.validator=ALL-UNNAMED --add-exports=java.base/sun.security.provider.certpath=ALL-UNNAMED
to java arguments.