从基本使用的角度来看，不同之处在于如何初始化生成的 TrustManager，根据Java Cryptography Architecture Oracle Providers Documentation for JDK 8

SunX509：X509ExtendedTrustManager 实例的工厂，根据 IETF PKIX 工作组在 RFC 3280 或其后续版本中定义的规则验证证书链。此 TrustManagerFactory 支持使用 Keystore 对象进行初始化，但目前不支持使用类 javax.net.ssl.ManagerFactoryParameters 进行初始化。

PKIX：X509ExtendedTrustManager 实例的工厂，根据 IETF PKIX 工作组在 RFC 3280 或其后继者中定义的规则验证证书链。此 TrustManagerFactory当前支持使用 KeyStore 对象或 javax.net.ssl.CertPathTrustManagerParameters 进行初始化。

需要注意的一点是，JDK 8 的 Java Cryptography Architecture Standard Algorithm Name Documentation仅将 PKIX 列为 TrustManagerFactory 算法。SunX509 由供应商提供文档，因为它是供应商提供的实现，而 PKIX 由所有供应商提供。例如，如果您在 IBM JRE 上运行，则没有SunX509，而是IbmX509。连续地，如果我们在应用程序中硬编码“SunX509”，我们将收到一个NoSuchAlgorithmException. 因此，为了可移植性，最好使用如下平台默认算法，因为两者都适用于 keystone 文件（目前 Sun 和 IBM JRE 都默认为 PKIX）。

TrustManagerFactory trustManagerFactory=
    TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());

虽然两个工厂都可以使用KeyStore参数进行初始化，但使用 PKIX 允许使用其他选项，可以使用初始化参数进行配置。一个有趣的例子是使用LDAPCertStoreParametersLDAP 证书存储而不是密钥存储文件（这里是一个例子）。

Oracle 的错误跟踪系统中存在一个问题，使这个问题更加清晰

https://bugs.openjdk.java.net/browse/JDK-8169745

从问题：

SunX509 信任管理器在 SimpleValidator.java 中实现仅用于兼容性用途，不会添加任何新功能。PKIX 信任管理器是默认和推荐的信任管理器。

在 SunX509 验证器/信任管理器实现中，我们过去只检查已知的关键扩展。支持的扩展在 sun/security/validator/EndEntityChecker.java 中被列入白名单。如果扩展很重要且不在白名单中，则证书无法通过 SunX509 验证。PKIX 验证器/信任管理器支持更丰富的扩展和功能。

在 Oracle Providers 文档中，它目前说：

“SunX509：X509ExtendedTrustManager 实例的工厂，根据 IETF PKIX 工作组在 RFC 3280 或其后续版本中定义的规则验证证书链。”

这是一种误导，因为它不支持 RFC 3280 的所有必需扩展（可能还有其他要求），并且它不严格符合 RFC 3280 并且可能不支持所有必需的扩展。我们也可以阻止它的使用。我们应该在本文档中将 RFC 3280 引用更新为 5280。