企业官网建设流程全解析

简介：JDK 1.7.0_13 是 Oracle Java 7 系列的一款完整 Java 开发工具包，面向需要维护历史项目、复现旧版编译环境或学习 Java 基础工具链的开发者。它提供 javac 编译器、Java 运行时与虚拟机，以及 javadoc、jdb、jconsole、jmap、jhat 等诊断与文档工具，可用于源码编译、程序调试、内存分析和 API 文档生成，也适合在 Eclipse、IntelliJ IDEA 等 IDE 中配置旧版 SDK。压缩包共 1240 个文件，约 79.07MB，以 jar 类库与可执行程序为主，辅以 xml 配置、properties 属性文件、dll 本地库、exe 工具及 bat 脚本，并包含 src 源码、许可证和时区数据等支撑内容，目录层次对应标准 JDK 安装结构。已有 373 人学习下载，对需要兼容 Java 7 的遗留系统维护、课程实验和环境比对场景具有一定参考价值。

1. 为什么现在还有人翻出 jdk1.7.0_13 这个包

上个月帮人排查一个内网系统，源码在开发机上跑得好好的，换到一台干净服务器上编译，javac直接甩出一行Unsupported major.minor version 52.0。敲java -version一看，那台机器上装的是更新的 JDK，而项目锁死在这套 Java 开发环境上，连pom.xml里的source都写着 1.7。这类场景里，jdk1.7.0_13 就是答案：它是 JDK 7 更新线上的第 13 个更新包，压缩包解开后顶层目录名就叫jdk1.7.0_13，bin、jre、lib一整套齐全。它解决的不是“学 Java”，而是让一台新机器复刻出与当年完全一致的编译期和运行期——字节码版本 51.0、默认 PermGen、老版本 cacerts 信任库。适合谁：手上攥着 2012 到 2015 年间遗留系统、需要原样复现构建环境的人。

2. 先摸清 JDK 7 的底盘：51.0 字节码和它真正带来的东西

装老 JDK 最容易犯的错，是把它当成“低配版的新 JDK”来用，结果在编译参数和运行参数上到处撞墙。先把 JDK 7 的边界画清楚，后面装环境、写构建脚本才不会反复返工。

2.1 为什么老项目会锁死在 7，而不是 6 或 8

锁在 7 上的项目，通常不是因为喜欢 7，而是被两头夹住。往下看，JDK 6 没有 NIO.2、没有 try-with-resources、没有字符串 switch，很多 2013 年之后写的代码在 6 上根本编不过；往上看，JDK 8 把永久代换成了元空间，字节码跳到 52.0，一批做字节码增强、动态代理、反射注入的老框架在 8 上会出各种VerifyError和ClassCastException，而这些框架的维护早已停滞。

所以 7 成了“刚好够用”的那一档：语法糖够现代，运行时模型又还是老样子。判断自己的项目属不属于这一档，看三个信号就够了——pom.xml或build.xml里写死1.7；依赖树里有一批 2014 年前后就不再发版的 jar；启动脚本里带着-XX:MaxPermSize。三条中两条，基本可以判定要走原样复现这条路。

这张表最实用的一列是 major 号。后面排查UnsupportedClassVersionError时，报错里那个52.0、55.0，对照的就是这一列——报错说的是“你拿高版本编出来的 class 丢到低版本 JVM 上跑了”，而不是“JDK 装错了”。

2.2 JDK 7 里真正会被用到的几个特性

JDK 7 的语法糖不多，但每一个在遗留代码里出现频率都很高，装完环境后写验证 Demo 时正好可以一次性覆盖：

有一点必须说透：invokedynamic 指令在 51.0 里已经有了，但真正用它的是 JDK 8 的 Lambda。所以在 1.7.0_13 上你能写MethodHandle，却写不了() -> {}，看到教程里拿 Lambda 举例的，直接跳过。同理，java.time包、Nashorn 引擎、默认方法这些也都是 8 的东西，在 7 上编译会直接报“找不到符号”。

2.3 1.7.0_13 在更新线上的位置，以及它确定没有的东西

1.7.0_13这个编号里，1.7.0是特性版本，_13是更新序号。它属于 7 系列偏早的一批更新包，之后的更新线还有若干更晚的包，主要累积的是安全修复、时区数据、根证书和 TLS 相关改动。这个位置决定了它的两个特点。

好处是“干净”：它离 JDK 7 GA 不远，运行时行为最接近当年项目刚上线时的样子，不会因为你换了个更新的 7 而出现行为漂移。坏处也很明确——它自带的cacerts信任库是当年的快照，里面没有这几年新签发的一批根证书；客户端默认启用的 TLS 协议版本也偏低，去连只接受 TLS 1.2 的对端时会握手失败。这两点不是“配置错了”，是版本本身的年代局限，后面第 5 章会给出具体处理办法。

另外要清楚它确定没有的东西，省得在搜索引擎上浪费时间：没有 Metaspace（还是 PermGen），没有 Lambda 和 Stream，没有java.time，没有模块系统，没有-release这个编译参数（那是后来的 JDK 才有的）。把这些记住，遇到“为什么这个参数不生效”时能少绕半小时。

3. 三种系统上的落地安装：目录、环境变量与验证

安装 JDK 本身没什么技术含量，翻车的全是路径和环境变量。我一般遵循两条硬规矩：安装目录不带空格、不带中文；JAVA_HOME只指到 JDK 根目录，绝不带bin也不带引号。下面按系统分开写，命令可以直接抄。

3.1 Windows：路径别带空格，JAVA_HOME 别指到 bin

解压或安装到D:\jdk\jdk1.7.0_13这种短路径下。不要往C:\Program Files里放，那个空格会让一批老构建脚本里的路径拼接直接断掉，而且部分老工具会拿到 8.3 短名，日志里出现PROGRA~1这种看不懂的路径。

环境变量按这个顺序配：新建系统变量JAVA_HOME，值为D:\jdk\jdk1.7.0_13；编辑Path，把%JAVA_HOME%\bin放到最前面，如果系统里还装着别的 JDK，这一步决定谁生效；CLASSPATH设成.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar，开头那个点不能丢。

配置完开一个新的 cmd 窗口验证，注意java -version的输出走的是标准错误流，重定向一下才抓得全：

echo %JAVA_HOME% where java java -version 2>&1 javac -version 2>&1

where java如果列出多条，第一条才是真正生效的那个，跟%JAVA_HOME%\bin\java.exe对不上就说明 Path 顺序有问题。javac -version也要能出结果，只出java不出javac，说明装的是 JRE 而不是 JDK，或者 Path 指到了jre\bin。

3.2 Linux：解包、alternatives 与 profile.d 三选一

Linux 上的坑集中在权限和切换方式。用 tar.gz 包解开后，bin目录下的可执行位通常是保留的；如果你拿到的是 zip 包再解压，可执行位会丢，表现就是java: command not found或者Permission denied，很多人会误以为是包坏了。

# JDK_PKG 换成你手上的包名，解压后顶层目录固定是 jdk1.7.0_13 sudo tar -xzf /tmp/${JDK_PKG} -C /opt sudo chmod -R +x /opt/jdk1.7.0_13/bin /opt/jdk1.7.0_13/bin/java -version 2>&1

能打印出版本，说明包本身没问题，接下来才谈环境变量。切换方式有三种，我按推荐程度排：

第一种是update-alternatives，适合一台机器上装多套 JDK、需要按项目切换的场合。--install的最后一个数字是优先级，数值大的优先，我用版本号尾数当优先级，一眼能看出对应关系：

sudo update-alternatives --install /usr/bin/java java /opt/jdk1.7.0_13/bin/java 1713 sudo update-alternatives --install /usr/bin/javac javac /opt/jdk1.7.0_13/bin/javac 1713 sudo update-alternatives --config java

第二种是/etc/profile.d里的独立脚本，适合整机只跑一套 JDK 的构建机，好处是登录即生效、不用记命令，也方便在脚本里统一改：

sudo tee /etc/profile.d/jdk7.sh >/dev/null <<'EOF' export JAVA_HOME=/opt/jdk1.7.0_13 export PATH="$JAVA_HOME/bin:$PATH" export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF source /etc/profile.d/jdk7.sh

这里写的是JAVA_HOME而不是直接把/opt/jdk1.7.0_13/bin写进PATH，因为绝大多数构建工具是靠读JAVA_HOME找 JDK 的，只配PATH的话命令行能跑、构建工具照样报找不到编译器。

第三种是只对当前会话生效的临时 export，调试时最省事，关掉终端就没了，不建议写进任何脚本。

3.3 装完必须跑的验证清单

光看java -version不够，那只证明 JVM 能起来，证明不了编译器、位数、默认编码这些真正会咬人的东西。写一个几行的检测类，把关键系统属性打出来，比查文档快：

cat > /tmp/EnvCheck.java <<'EOF' public class EnvCheck { public static void main(String[] args) { System.out.println("java.version = " + System.getProperty("java.version")); System.out.println("java.home = " + System.getProperty("java.home")); System.out.println("java.vm.name = " + System.getProperty("java.vm.name")); System.out.println("os.arch = " + System.getProperty("os.arch")); System.out.println("file.encoding = " + System.getProperty("file.encoding")); System.out.println("sun.jnu.encoding = " + System.getProperty("sun.jnu.encoding")); } } EOF $JAVA_HOME/bin/javac -encoding UTF-8 -d /tmp /tmp/EnvCheck.java $JAVA_HOME/bin/java -cp /tmp EnvCheck

几个输出怎么读：java.version应该是1.7.0_13；java.home如果指向.../jre而不是.../jdk1.7.0_13，说明JAVA_HOME有人给你指到了 jre 子目录，后面构建工具一定会炸；java.vm.name里带64-Bit说明是 64 位版本，装 32 位 JDK 跑大堆内存会直接起不来；file.encoding在 Windows 上多半是GBK，在 Linux 上取决于 locale，这个值直接决定了javac读源码时用什么编码，第 5 章的乱码问题根子就在这。

4. 拿这个 JDK 跑通一个 Demo：编译参数、字节码校验与构建工具配套

环境装好只是第一步，真正的验证是“能编、能跑、产物版本对得上”。下面这份 Demo 刻意只用了 JDK 7 存在的语法和 API，跑通它等于把整个工具链走了一遍。

4.1 一份只用 JDK 7 语法的样例工程

功能很简单：递归扫描目录下的.log文件，统计含指定关键字的行数，用 Fork/Join 并行跑，顺便把 try-with-resources、NIO.2、钻石语法、字符串 switch 全用上。

// src/demo/LogScanner.java package demo; import java.io.BufferedReader; import java.io.IOException; import java.nio.charset.Charset; import java.nio.file.DirectoryStream; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.util.ArrayList; import java.util.List; import java.util.concurrent.ForkJoinPool; import java.util.concurrent.RecursiveTask; public class LogScanner { // Fork/Join 的分治任务：RecursiveTask 适合有返回值的场景 static class DirTask extends RecursiveTask<Long> { private final Path dir; private final String keyword; DirTask(Path dir, String keyword) { this.dir = dir; this.keyword = keyword; } @Override protected Long compute() { long hit = 0L; List<DirTask> subs = new ArrayList<>(); // 钻石语法，JDK 7 起可用 // try-with-resources：异常路径下 DirectoryStream 也会被 close try (DirectoryStream<Path> ds = Files.newDirectoryStream(dir)) { for (Path p : ds) { if (Files.isDirectory(p)) { subs.add(new DirTask(p, keyword)); } else if (p.toString().endsWith(".log")) { hit += countInFile(p, keyword); } } } catch (IOException e) { System.err.println("skip " + dir + " : " + e.getMessage()); } for (DirTask t : subs) { t.fork(); // 子任务丢进工作线程队列 } for (DirTask t : subs) { hit += t.join(); // 汇总结果 } return hit; } private long countInFile(Path file, String keyword) throws IOException { long n = 0L; // 显式指定 Charset，避免跟随平台默认编码导致中文关键字匹配不上 try (BufferedReader br = Files.newBufferedReader(file, Charset.forName("UTF-8"))) { String line; while ((line = br.readLine()) != null) { if (line.contains(keyword)) { n++; } } } return n; } } public static void main(String[] args) throws Exception { Path root = Paths.get(args.length > 0 ? args[0] : "."); String keyword = args.length > 1 ? args[1] : "ERROR"; String mode = args.length > 2 ? args[2] : "text"; ForkJoinPool pool = new ForkJoinPool(4); // 并行度按核数给，别拍脑袋开太大 long hit = pool.invoke(new DirTask(root, keyword)); pool.shutdown(); // 字符串 switch 是 JDK 7 的语法糖，编译后是 hashCode 分派 + equals 校验 switch (mode) { case "json": System.out.println("{\"keyword\":\"" + keyword + "\",\"hits\":" + hit + "}"); break; case "text": default: System.out.println("keyword=" + keyword + " hits=" + hit); } } }

代码里有三处值得留意。Files.newBufferedReader显式传了Charset，因为不传的话会走平台默认编码，中文关键字在 GBK 环境下匹配不上，这类问题排查起来极其费时。ForkJoinPool的并行度给了 4，是保守值，磁盘 IO 密集的场景开太多线程只会互相抢 IO。t.fork()和t.join()分两个循环，是为了让子任务先全部提交再统一收结果，避免退化成串行。

4.2 编译命令与三个关键参数

cd /path/to/project /opt/jdk1.7.0_13/bin/javac \ -source 1.7 -target 1.7 \ -encoding UTF-8 \ -Xlint:all \ -d out \ src/demo/LogScanner.java

逐个说清楚：-source 1.7限定语法级别，用了更高版本的语法会直接报错而不是悄悄放过；-target 1.7决定生成的字节码版本，也就是 major 51；-encoding UTF-8告诉编译器源文件是 UTF-8，不加的话在 Windows 上会用 GBK 去读，中文注释立刻报“不可映射字符”；-Xlint:all把所有警告打开，老代码里常见的unchecked和deprecation一次性暴露出来；-d out指定输出目录，避免 class 文件散落在源码旁边。

如果你是在更新的 JDK 上交叉编译出 51.0 的产物，还得加-bootclasspath $JAVA_HOME/jre/lib/rt.jar，否则编译器会拿新 JDK 的 API 去校验，代码里用到新方法照样编过，跑起来才NoSuchMethodError。不过这个参数在新 JDK 上已经被移除，只在真正用 JDK 7 编译时才顺手。

编完必须验证字节码版本，这是唯一能证明产物对不对的办法：

/opt/jdk1.7.0_13/bin/javap -verbose out/demo/LogScanner.class | grep -E "major|minor"

输出major version: 51才算过关。看到 52 说明编译器根本没走-target 1.7，或者你调用的javac压根不是/opt/jdk1.7.0_13/bin下的那个——javac -version对一下就知道。

4.3 构建工具怎么配套：Maven 版本与 compiler 插件

实际项目很少手敲javac，都是构建工具代劳。这里有个容易被忽略的事实：构建工具本身也是 Java 程序，它自己得能在这个 JDK 上跑起来。更新版本的构建工具，jar 包是用更高版本 JDK 编译的，丢到 1.7.0_13 上直接UnsupportedClassVersionError，报错信息指向的还是构建工具自己的类，很容易误判成项目代码有问题。

Maven 这边，本体选 3.0.x 到 3.2.x 这一段比较稳，编译插件用 2.3.2，它兼容性好、依赖少：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.7</source> <target>1.7</target> <encoding>UTF-8</encoding> <compilerArgument>-Xlint:all</compilerArgument> </configuration> </plugin>

encoding这一项在插件配置里写死比在MAVEN_OPTS里设-Dfile.encoding=UTF-8更可靠，因为后者只影响 Maven 进程自己，编译子进程未必继承。compilerArgument里放的是直接透传给javac的参数，-Xlint:all放这儿等价于命令行加同一项。

如果项目里同时存在多套 JDK，靠改JAVA_HOME切换很容易误操作，更稳的做法是在 Maven 里配 toolchains，把“哪个项目用哪个 JDK”写进配置文件，构建时自动选。这一步在遗留系统迁移里价值很高，因为它把环境依赖从“人的记忆”变成了“可提交的文件”。

4.4 跑起来看结果

/opt/jdk1.7.0_13/bin/java \ -server -Xms256m -Xmx256m \ -XX:PermSize=128m -XX:MaxPermSize=256m \ -cp out demo.LogScanner /var/log/app ERROR json

-Xms和-Xmx设成一样，避免运行期反复扩容；-XX:PermSize和-XX:MaxPermSize是 PermGen 时代的参数，在 1.7.0_13 上有效，换到更高版本的 JDK 会被忽略并打警告——这也是为什么启动脚本不能跨版本复用。跑出来的hits数量，跟你用grep -c手工数一遍对得上，才说明并行汇总逻辑没问题。

5. 避坑与排查：JDK 7 上最容易翻车的五件事

下面五条都是我实际遇到过、并且能稳定复现的。每条按现象、原因、解决写，遇到报错可以直接对号入座。

5.1 编译期：字节码版本与源文件编码

坑一：UnsupportedClassVersionError ... Unsupported major.minor version 52.0

现象是程序启动瞬间就崩，堆栈最上面一行指向某个类的静态初始化，看起来像是那个类写错了，实际上跟类本身毫无关系。

原因只有一个：这个 class 是用更高版本的javac编出来的，major 号高于当前 JVM 支持的 51。常见于两种情况——项目在自己机器上用新 JDK 编过一遍，产物被打进 jar 带到了服务器；或者依赖里混进了新版本 JDK 编译的三方包，这种情况最隐蔽，因为你的代码一行没错。

解决办法分两步。先定位是哪个 jar 的问题，用javap挨个查，或者直接看报错里给出的类名反查所属 jar；然后把构建环境统一到 1.7.0_13，javac和java都走同一套JAVA_HOME。如果确实必须用新 JDK 编译，就加-target 1.7 -bootclasspath $JAVA_HOME/jre/lib/rt.jar，但要注意新 JDK 未必还支持 7 这个 target，支持列表是随版本逐步收窄的。

坑二：错误: 编码GBK的不可映射字符

现象是编译在某个中文注释或中文字符串处中断，报错行号指向的位置看起来完全正常，把那一行删掉错误就转移到下一行中文。

原因是javac默认用平台默认编码读源文件，Windows 上file.encoding是 GBK，而文件本身是 UTF-8 保存的，字节序列按 GBK 解出来就是乱码，解码失败就报这个错。

解决就是在所有编译入口加-encoding UTF-8，包括命令行、Maven 插件配置、IDE 的编译选项。别指望改系统区域设置，那个改动影响面太大，而且在 CI 机器上未必有权限。顺带说一句，运行期的乱码是另一回事，那是file.encoding决定的，得用-Dfile.encoding=UTF-8启动，两个参数别混。

5.2 运行期：JAVA_HOME、PermGen 与并行度

坑三：JAVA_HOME is set to an invalid directory

现象是命令行敲java -version一切正常，一跑mvn或构建脚本就报这个，很多人会以为是 Maven 装坏了。

原因基本是JAVA_HOME指错了层级：指到了bin目录、指到了jre子目录、值里带了引号、末尾多了个斜杠，这四种写法在 shell 里都能让PATH生效，但构建工具做的是“在$JAVA_HOME/bin下找javac”这种拼接，多一层少一层立刻对不上。

解决方法是把JAVA_HOME规范化成 JDK 根目录，不带引号不带尾斜杠，用ls $JAVA_HOME/bin/javac确认能列出来。Windows 上还要注意改完环境变量必须新开窗口，老窗口读的还是旧值，这一条每年都能坑到人。

坑四：java.lang.OutOfMemoryError: PermGen space

现象是应用跑一段时间后崩，或者热部署几次之后必崩，堆内存看着还很空，jstat里老年代也没满。

原因是 1.7.0_13 还在用永久代，类元数据、常量池、动态生成的代理类都堆在里面，而默认的MaxPermSize在 64 位机器上通常只有几十兆。用反射、动态代理、字节码增强比较多的老框架会持续往永久代里塞类，塞满就崩。

解决是显式给永久代划空间：-XX:PermSize=256m -XX:MaxPermSize=512m，具体数值按应用实际生成类的规模调，先给 512m 观察jstat -gc里 PGCMX 和 PGC 的差值。如果加了还在涨，那多半是热部署没卸载干净，属于代码问题，继续加参数只是拖时间。

此外，并行度也需要设置上限。ForkJoinPool的并行度我一般按 核数 给，-Djava.util.concurrent.ForkJoinPool.common.parallelism也是同理，因为磁盘 IO 为主的场景，多开线程只会增加上下文切换。另外不要在这套版本上尝试-XX:+UseG1GC来省事，它在 7 系列里可用但不成熟，出现长暂停时基本没有可用的排查手段。

5.3 网络期：证书与 TLS 协议

坑五：PKIX path building failed或Received fatal alert: protocol_version

现象是应用启动后连外部服务超时或直接抛异常，本机用浏览器访问同一个地址却完全正常，两边现象对不上，很容易被当成网络问题查半天。

原因有两层。第一层，1.7.0_13 自带的cacerts是当年的信任库快照，对端换了新根证书签发的新证书链，本地认不出来，就报PKIX path building failed。第二层，JDK 7 早期更新包的客户端默认启用的 TLS 协议版本偏低，对端只接受 TLS 1.2 时握手直接失败，报protocol_version。

第一层的解决办法是把对端的根证书导进信任库，导之前先备份原文件：

cp $JAVA_HOME/jre/lib/security/cacerts $JAVA_HOME/jre/lib/security/cacerts.bak $JAVA_HOME/bin/keytool -importcert -alias internal-ca \ -file internal-ca.crt \ -keystore $JAVA_HOME/jre/lib/security/cacerts \ -storepass changeit -noprompt $JAVA_HOME/bin/keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit | grep internal-ca

-alias是给证书起的别名，重复导入会报已存在，先-delete再导。-storepass changeit是信任库的默认口令，没改过就是这个。

第二层，启动参数里显式抬高协议版本：-Dhttps.protocols=TLSv1.2。这个属性对走HttpsURLConnection的客户端有效，但如果项目用的是自带的 HTTP 客户端，就得在客户端配置里单独设。还有一点要清楚：1.7.0_13 这个位置上，部分只在新更新包才引入的 TLS 相关系统属性未必被识别，别指望一个参数包打天下，实测为准。

6. 多版本共存与退出路径：一条命令切 JDK，一个脚本查字节码

一台机器上同时躺着 7、8、17 是常态，改JAVA_HOME改到手滑的代价不小。我现在的习惯是在 shell 里放一个切换函数，从固定的基础PATH重建，避免反复拼路径把PATH越叠越长：

# 追加到 ~/.bashrc，固定基础 PATH，每次切换都从它重建 export BASE_PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" jdk() { case "$1" in 7) export JAVA_HOME=/opt/jdk1.7.0_13 ;; 8) export JAVA_HOME=/opt/jdk1.8.0_202 ;; 17) export JAVA_HOME=/opt/jdk-17 ;; *) echo "usage: jdk {7|8|17}"; return 1 ;; esac export PATH="$JAVA_HOME/bin:$BASE_PATH" java -version 2>&1 | head -n 1 }

关键在最后那行head -n 1：切换完立刻打印版本，切错了当场就能看见，不用等到构建失败才发现。java -version走标准错误，2>&1不能省。这套写法比update-alternatives更适合开发机，因为它是会话级的，开两个终端可以分别跑不同版本，互不干扰。

配套还有一个批量校验脚本，用来确认整个产物树里没有混进高版本字节码。思路是把所有 jar 解开、对每个 class 跑javap，把 major 不是 51 的都列出来：

for j in $(find . -name "*.jar"); do unzip -o -q "$j" -d /tmp/scan 2>/dev/null || continue find /tmp/scan -name "*.class" | while read c; do m=$(/opt/jdk1.7.0_13/bin/javap -verbose "$c" 2>/dev/null | grep "major version" | awk '{print $3}') [ "$m" != "51" ] && echo "$j -> $c -> major=$m" done rm -rf /tmp/scan done

这个脚本我只在依赖变更后跑，一次跑完能揪出所有偷偷升级的三方包。血泪经验是：不要在本地用新 JDK 编一遍再传到服务器，中间只要有一个环节版本对不上，排查成本就是从几分钟变成几小时。从那以后我每次动构建环境，都强制先跑一遍javac -version加javap -verbose | grep major，两个输出对上了才继续往下走。这套流程把 90% 的“玄学启动失败”挡在了编译阶段。

至于退出路径，我的建议是分两步走，不要一步跳到最新版本。先把编译目标抬到 8，在 8 上跑通全量测试并稳定一段时间，这个阶段能暴露掉绝大部分依赖字节码增强的暗坑；再考虑往更高的 LTS 走。真正急着上线的时候，把 jdk1.7.0_13 这套环境原样留一份在离线仓库里，比任何迁移方案都可靠。希望帮到你。

本文还有配套的精品资源，点击获取