sql-jdbc4与mssql JDBC驱动区别及SQL Server连接报错问题

你遇到的sun.security.validator.ValidatorException: PKIX path building failed报错和SQL Server与JDBC驱动版本不兼容没有关系。
这个是典型的TLS证书信任校验失败问题：从mssql JDBC驱动10.0版本开始，驱动默认开启服务端TLS证书强校验，要求SQL Server返回的证书必须被当前JRE信任库中的受信任CA签发。如果你的SQL Server使用的是自签名证书、或是内部私有CA签发的证书且没有提前导入JRE信任库，就会抛出这个异常。
你添加trustServerCertificate=true参数后可以正常连接，刚好印证了这个根因：该参数的作用就是跳过服务端TLS证书的信任链校验流程，直接信任服务端返回的任意证书，自然绕开了证书校验失败的问题。

你当前使用的JDBC驱动10.2版本、JRE 1.8、SQL Server 2018的组合完全在官方支持的兼容矩阵范围内，不存在版本适配问题，不需要更换驱动或数据库版本。

生产环境不建议长期开启trustServerCertificate=true配置，该参数会跳过证书校验，存在TLS中间人攻击风险。更稳妥的方案是将SQL Server使用的TLS证书导入到JRE的cacerts信任库中，再移除该参数保证连接安全性。

• 版本线定位不同：sqljdbc4是微软早期发布的老旧驱动分支，仅适配JDBC 4.0规范，早已停止功能迭代和安全更新；目前通用的mssql JDBC驱动是微软后续重构维护的持续更新版本线，覆盖JDBC 4.2、4.3等更高规范，长期跟进功能更新和安全补丁。
• 默认安全策略不同：旧版sqljdbc4默认不强制校验服务端TLS证书，无需额外配置即可连接使用自签名证书的SQL Server实例；10.0及以上版本的新版mssql JDBC驱动默认开启TLS证书强校验，也就是你本次遇到报错的直接触发来源。
• 功能覆盖不同：sqljdbc4仅支持SQL Server 2008到2012版本的基础特性，不支持Always On可用性组、Azure AD认证、透明数据加密、TLS 1.3等后续新增的数据库能力和安全特性；新版mssql JDBC驱动全量支持从SQL Server 2008到最新正式版SQL Server、Azure SQL全系列产品的所有功能。
• 环境适配不同：sqljdbc4仅适配JRE 6/7环境，在高版本JRE上运行会出现API不兼容问题；新版mssql JDBC驱动会针对不同JRE版本提供独立编译包，比如10.2版本就分别提供适配JRE 8、JRE 11、JRE 17的分发包，跨版本兼容性更好。

内容的提问来源于stack exchange，提问作者user13746660