📚 课程目录第4章开发环境准备

4、开发环境准备：JDK版本、Maven/Gradle配置、依赖管理

好了，到了真要动手的时候了。

集成TDE SDK之前，先把开发环境捋顺。这一步要是踩了坑，后面排查问题会非常痛苦。我个人习惯先把环境调稳定了，再开始写代码。

4.1 JDK版本选择：别小看这个基础

TDE SDK对JDK版本有硬性要求。我用的版本是JDK 8 (1.8.0_202+) 或 JDK 11。为什么是这两个？因为SDK底层依赖Java Cryptography Extension (JCE)，JDK 8和11对JCE的支持最稳定。

⚠️ 重要提醒： 不要用JDK 9、10这类过渡版本。我在项目中遇到过JDK 9下JCE策略文件加载失败的问题，排查了整整一天。后来发现官方文档里明确写了只支持LTS版本。

JDK版本	TDE SDK兼容性	建议
JDK 8 (1.8.0_202+)	✅ 完全兼容	首选，生产环境验证最多
JDK 11 (LTS)	✅ 完全兼容	如果你已经迁移到JDK 11，放心用
JDK 17+	⚠️ 部分兼容	需要额外配置模块化参数，不建议新手尝试
JDK 9/10	❌ 不兼容	踩坑过，直接换版本

还有一个细节：确认JCE Unlimited Strength Jurisdiction Policy已经安装。JDK 8默认有限制，需要手动替换policy文件。JDK 11及以后默认就是unlimited，省心很多。

💡 我的小技巧： 用这个命令检查JCE是否已开启：

jrunscript -e "print(java.lang.System.getProperty('java.version')); print(java.security.Security.getProvider('SunJCE').getInfo())"

。如果输出里有"Unlimited"字样，说明没问题。

4.2 Maven配置：依赖声明与版本锁定

我建议用Maven做依赖管理。Gradle也行，但Maven对于企业级项目的可读性更好。

在pom.xml里，首先要声明TDE SDK的私有仓库地址（如果你的SDK没有上传到Maven中央仓库）。

<repositories>
    <repository>
        <id>tde-sdk-repo</id>
        <url>https://your-private-repo.com/repository/tde-sdk/</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>

然后添加SDK的核心依赖。以我集成过的某厂商SDK为例：

<dependency>
    <groupId>com.example.tde</groupId>
    <artifactId>tde-sdk-core</artifactId>
    <version>2.3.1.RELEASE</version>
</dependency>

<!-- 如果涉及数据库连接池集成，还需要 -->
<dependency>
    <groupId>com.example.tde</groupId>
    <artifactId>tde-sdk-druid</artifactId>
    <version>2.3.1.RELEASE</version>
</dependency>

坦白讲，版本号一定要锁定。不要用RELEASE或LATEST这种范围版本。我曾经见过同事因为用了LATEST，导致CI流水线突然拉到一个不兼容的新版本，整条业务线都跟着乱了。

4.3 Gradle配置：喜欢DSL的话可以这么配

如果你的项目用Gradle，配置思路是一样的。我在一个微服务项目里用过Gradle，配合Spring Boot效果不错。

repositories {
    mavenCentral()
    maven {
        url "https://your-private-repo.com/repository/tde-sdk/"
    }
}

dependencies {
    implementation 'com.example.tde:tde-sdk-core:2.3.1.RELEASE'
    implementation 'com.example.tde:tde-sdk-druid:2.3.1.RELEASE'
}

注意一点：Gradle的依赖传递默认是开启的。如果TDE SDK引入了某些你不想用的传递依赖（比如旧的log4j），记得用exclude排除掉。

implementation('com.example.tde:tde-sdk-core:2.3.1.RELEASE') {
    exclude group: 'org.apache.logging.log4j', module: 'log4j-core'
}

嗯，这里要小心。排除依赖之前，最好先确认SDK是否真的依赖log4j-core做核心功能。我之前盲目排除过一次，结果SDK启动时报了ClassNotFoundException，白白浪费两小时。

4.4 依赖管理：BOM与版本集中控制

多模块项目里，我习惯用Maven BOM (Bill of Materials) 来集中管理TDE SDK的版本。这样所有子模块的版本都统一，不会出现“A模块用2.3.0，B模块用2.3.1”这种尴尬局面。

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.example.tde</groupId>
            <artifactId>tde-sdk-bom</artifactId>
            <version>2.3.1.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

之后，子模块引用时就不需要写版本号了，Maven会自动从BOM里继承：

<dependency>
    <groupId>com.example.tde</groupId>
    <artifactId>tde-sdk-core</artifactId>
</dependency>

表格对比一下集中管理和分散管理的优劣：

管理方式	优点	缺点
BOM集中管理	版本统一、升级方便	需要额外维护BOM模块
各模块独立声明	配置简单，一眼看到版本	版本容易散落各处，升级易遗漏

我强烈建议企业级项目用BOM方式。版本统一带来的维护成本节省，远大于那点额外配置。

4.5 依赖冲突：一个绕不开的坑

依赖冲突是集成SDK时最容易遇到的问题。TDE SDK很可能依赖了某个特定版本的netty、protobuf或者日志框架，和你项目里现有的版本不兼容。

怎么排查？我个人习惯用mvn dependency:tree。

mvn dependency:tree -Dincludes=com.example.tde

这条命令会打印出TDE SDK的所有传递依赖树。如果发现有版本冲突，比较直接的办法是在pom.xml里显式声明你要用的版本：

<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-all</artifactId>
    <version>4.1.75.Final</version>
</dependency>

📌 冲突解决原则：
优先使用项目已有版本，除非SDK明确要求新版本。
如果SDK要求新版本，评估对其他模块的影响。
实在解决不了，联系SDK厂商获取兼容版本。

我曾经遇到过一个案例：项目用了netty 4.0.x，TDE SDK需要netty 4.1.x。强行升级后，另一个依赖netty 4.0.x的模块直接起不来了。最后我们升级了所有netty依赖到4.1.x的中位版本，才解决了问题。你想想看，这种问题早发现比晚发现好得多。

4.6 开发环境准备工作清单

最后，我整理了一个清单。你可以照着一步步确认：

JDK：确认版本为JDK 8 (1.8.0_202+) 或 JDK 11，并开启JCE Unlimited。
私服仓库：确认可以访问到TDE SDK的私有Maven仓库。
依赖声明：在pom.xml或build.gradle中添加SDK核心依赖，版本锁定。
依赖树检查：执行mvn dependency:tree，确认没有版本冲突。
编译测试：执行mvn clean compile，确保SDK可以被正常编译。

💡 建议： 在集成前，先在一个独立的测试项目里验证SDK能否正常编译和运行。别直接往生产项目里加，风险太高。

4.7 本章知识结构

先看这张图，后面就好理解了。