Java示例代码包实战：从javac编译到Maven改造与避坑

简介：这套 Java for Programmers 2nd Edition examples 面向已具备一定编程基础、希望系统梳理 Java 核心技术的开发者，也可作为高校课程与培训的配套练习素材。内容围绕《Java for Programmers》第2版的示例代码展开，覆盖基本语法与数据类型、条件与循环、数组和集合、方法与参数传递、面向对象中的继承封装多态、异常处理、文件 I/O、多线程同步，以及反射、注解、泛型与 JavaFX 界面编程等主题，便于读者通过阅读、修改和运行样例并配合注释观察设计取舍，理解语言机制。压缩包为 rar 格式，约 34.9MB，文件总数与类型明细上游未提供，暂无法按文件类别展开说明。页面显示已有 119 人学习，适合用作课堂示例、自学对照和项目练习的代码参考，帮助读者把零散语法知识落到可运行的程序结构中，并积累调试与问题定位经验。

1. 示例代码包不是用来读的：先让你本机编译出第一个 class

把一份 Java 示例代码包下载下来，第一件事不该是打开 IDE 逐行读，而是先让它在你自己的机器上编译出第一个 class 文件。Java for Programmers 第 2 版配套示例属于典型的“书配码”资源：从头到尾都是可运行的 java code 片段，覆盖语法基础、集合、泛型、并发、IO 几条主线，章节之间递进清楚，适合正在系统过一遍 Java、又不想只啃伪代码的人。它的价值不在读完，而在改：把每个示例当成一个最小实验体，改参数、加断言、看输出怎么变。读一遍只能记住语法长相，跑一遍才会撞上那些默认值、编码、版本带来的真实摩擦。下面按“先跑通、再拆解、后改造、最后避坑”的顺序走一遍。

2. 拆开示例包的目录骨架：javac 手动编译与 Maven 改造两条路

拿到压缩包解压之后，多数人的第一反应是整包拖进 IDE，然后等它慢慢索引、报出一屏红。更稳的顺序是先用手工命令跑通一个章节，确认 JDK 版本、编码、包结构三件事都对得上，再决定要不要转成构建工具工程。手动编译这一步看着原始，但它是唯一能把“到底是代码问题还是环境问题”分开的办法。

2.1 先摸清包里到底有什么：目录分层与命名规律

书配示例的目录结构有很强的共性，基本绕不开“按章分目录 + 每章一个可运行入口”这个套路。解压后先别急着编译，用两三条命令把结构扫一遍，比在 IDE 里点树状图快得多。

# 看顶层结构，判断是按章分还是按主题分 ls -1 # 统计 java 文件数量与分布，心里有个规模预期 find . -name "*.java" | wc -l find . -name "*.java" | sed 's|/[^/]*$||' | sort | uniq -c | sort -rn | head -20 # 找出所有带 main 方法的类，这些才是能直接跑的入口 grep -rl "public static void main" --include="*.java" .

第一条命令看顶层是 ch01、ch02 这种章节命名，还是 collections、concurrency 这种主题命名，决定了你后面按目录批量编译的粒度。第二条统计每个目录下的源文件数量，如果某个目录下只有一两个文件，多半是零散的知识点演示；如果有十几个，通常是围绕一个完整小项目的多类协作，编译时必须整目录一起编。第三条最实用：示例包里大量类是“被调用”的辅助类，只有带 main 的才是入口，先把入口清单列出来，后面逐个跑通就有了路线图，不至于对着一堆文件无从下手。

扫完结构，你对这个包的形态应该有一张表：

表里最后一行是血泪经验。很多示例包在打包时把作者本机的.class和bin目录一起塞进去了，如果你不小心把bin加进 classpath，运行时加载的可能是几年前用 JDK 8 编出来的字节码，而你的源码是 JDK 17 语法，报的错会指向一个看起来完全正确的源文件，排查半天找不到原因。解压后的第一件事就是把所有.class删干净。

提示：删除前先确认包里没有只提供 class 而不提供源码的第三方 jar，只删散落的 .class 文件，jar 保留。

2.2 用 javac 手动编译：最短路径验证环境

确认结构之后，挑一个依赖最少的章节（通常是讲语法基础的前两章）做第一次编译。这一步的目的是验证 JDK 版本和文件编码，不是验证代码质量。

# 1. 确认本机 JDK 版本，示例若用了较新语法，版本必须对得上 java -version javac -version # 2. 建独立输出目录，绝不让 .class 混进源码树 mkdir -p out/ch03 # 3. 按目录批量编译，显式指定编码和输出位置 javac -encoding UTF-8 -d out/ch03 $(find src/ch03 -name "*.java") # 4. 运行入口类，类名要带完整包名，classpath 指向输出目录 java -cp out/ch03 com.example.ch03.Main

第 3 条里的-encoding UTF-8不是可选项。示例代码里的中文注释、甚至字符串常量里的中文，在 javac 默认使用平台编码（中文 Windows 上通常是 GBK）时会直接变成乱码，编译能过但输出全是问号，新手很容易误判成“代码有问题”。-d指定输出根目录，javac 会按 package 声明自动建子目录，所以你在out/ch03下面看到的是com/example/ch03/Main.class这样的层级，运行时 classpath 指向out/ch03，类名写全限定名，两者必须对应上，否则就是经典的NoClassDefFoundError。第 4 条如果忘了包名只写Main，报错信息是“找不到或无法加载主类”，这个错九成不是编译失败，而是类名写短了。

如果只是想快速验证单个文件的行为，JDK 11 之后有个更省事的写法：

# 单文件源码直接运行，不产生 .class，适合验证一小段逻辑 java src/ch03/com/example/ch03/Hello.java

这种方式适合确认“这段示例到底输出什么”，但它对多文件依赖支持有限，同一个包里互相引用的类必须都在 classpath 上，所以只能当快速探针用，不能替代正式编译。

2.3 改造成 Maven 工程：依赖与编码两个必改项

手动编译跑通一两章之后，你大概率会遇到需要第三方库的示例——JSON 解析、单元测试、日志框架。这时候继续手写-cp就很不划算，转成 Maven 工程更省事。改造的关键是把源码目录挪到src/main/java下，让 Maven 的约定生效，然后补一份最小 pom。

<project xmlns="http://maven.apache.org/POM/4.0.0"> <modelVersion>4.0.0</modelVersion> <groupId>local.examples</groupId> <artifactId>java-examples</artifactId> <version>1.0.0</version> <properties> <!-- 与示例使用的语法级别对齐，不要盲目调高 --> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> <!-- 必须写，否则构建日志里一路编码告警 --> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <!-- 示例里出现过的测试框架，版本按需调整 --> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter</artifactId> <version>5.10.0</version> <scope>test</scope> </dependency> </dependencies> </project>

maven.compiler.source和target这两个参数最容易设错。设低了，示例里用的var、switch表达式、record全部编不过；设高了，你本地 JDK 又支撑不住。一个可靠的判断方法是搜一遍源码里有没有这些关键字：grep -rn "record \|-> \|var " src/ | head，如果有record，目标级别至少 16；如果只有var和 lambda，11 就够。project.build.sourceEncoding必须显式声明，不写的话 Maven 会用平台默认编码读源文件，前面 javac 遇到的乱码问题会原样复现一遍。

改造完之后，先只把跑通过的那一章源码挪进去，执行一次mvn -q compile，确认能编过再把剩下的章节分批搬。一次性全搬进去，报错会混在一起，分不清是缺依赖还是语法版本不对。

3. 四类示例的读法：集合、泛型、并发、IO 各自该盯哪个参数

示例代码最容易犯的错是“看懂了”，但说不出为什么这么写。每一类示例其实都有一两个关键参数或关键约束，抓住它比通读十遍有效。下面按四类分开说，每类给出可以直接抄下来改造的最小片段。

3.1 集合与泛型示例：从扩容行为看泛型的类型擦除

集合示例里最值得动手改的是容量。书上的写法通常直接new ArrayList<>()，看不出任何东西，把它改成给一个小初始容量，再往里塞超过容量的元素，扩容行为就暴露出来了。

import java.util.ArrayList; import java.util.List; public class GrowDemo { public static void main(String[] args) { // 故意给一个很小的初始容量，让扩容发生得足够早 List<String> list = new ArrayList<>(2); for (int i = 0; i < 10; i++) { list.add("item-" + i); // 每加一个就打印一次，观察输出顺序与容量无关，与元素顺序有关 System.out.println("size=" + list.size() + " elem=" + list.get(i)); } } }

这段代码要看的不是输出内容，而是size的变化节奏：ArrayList在元素数量超过当前容量时按大约 1.5 倍扩张，并把旧数组整体复制过去，所以往一个初始容量为 2 的列表里连续添加 10 个元素，会触发多次数组复制。示例里如果给了构造参数，那就是作者在暗示这个点；如果没给，默认容量是 10，你加前 10 个元素时一次扩容都不会发生，反而看不出东西。参数怎么改：初始容量设成 2 或 3，元素数量设成 10 以上，扩容就一定会出现。

泛型示例的关键约束是类型擦除。示例里常见的写法是List<String>和List<Integer>并存，getClass()一打印，两个列表的运行时类型都是java.util.ArrayList。这个点光看文字说明记不住，动手加一行System.out.println(list.getClass())才有感觉。顺带提醒：擦除意味着不能在运行时用instanceof List<String>判断，示例里如果出现这种写法，说明那份代码是配合特定编译器或旧版本的，直接跳过。

注意：不要为了“看到扩容”去用反射读 ArrayList 的内部数组，那需要--add-opens参数，且不同 JDK 版本字段名不一样，学习成本远高于收益。

3.2 并发示例：线程池的七个参数在示例里怎么被藏起来

并发章节的示例有两种写法：一种是直接new Thread(...)，另一种是Executors.newFixedThreadPool(4)。后者看着干净，但它把线程池最关键的几个参数藏起来了，其中队列是无界的。无界队列意味着任务永远不会触发拒绝策略，任务堆积到内存耗尽为止——这在演示代码里没问题，照搬到生产就是事故。

把示例改成显式构造，参数含义就一目了然：

import java.util.concurrent.*; public class PoolDemo { public static void main(String[] args) { ThreadPoolExecutor pool = new ThreadPoolExecutor( 2, // corePoolSize：常驻核心线程数 4, // maximumPoolSize：峰值线程上限 60L, TimeUnit.SECONDS, // keepAliveTime：非核心线程空闲回收时间 new ArrayBlockingQueue<>(2), // 有界队列，容量 2 new ThreadPoolExecutor.CallerRunsPolicy() // 队列满后由提交线程自己执行 ); for (int i = 0; i < 10; i++) { final int id = i; pool.execute(() -> System.out.println( "task-" + id + " on " + Thread.currentThread().getName())); } pool.shutdown(); } }

这段代码的执行顺序值得盯着输出看几遍：先占满 2 个核心线程，第 3、4 个任务进队列，队列满（容量 2）之后再开第 3、4 个线程，线程也到上限之后，剩下的任务交给拒绝策略处理。所以 10 个任务里，前面 8 个（2 核心 + 2 队列 + 2 扩容线程……具体分配取决于提交速度）由池内线程执行，后面的被CallerRunsPolicy交给 main 线程跑，输出里会看到main这个线程名混在里面。这个细节是理解线程池的第一道分水岭，很多人背了“core → queue → max → reject”的顺序，但没在输出里亲眼见过。

参数怎么改：把maximumPoolSize调到和corePoolSize相等，拒绝策略就会提前触发；把队列换成SynchronousQueue，任务会直接往扩容线程上走。这两种改法各跑一次，线程池的行为模型就立住了。

3.3 IO 与 NIO 示例：字符集和资源关闭是两处必查项

IO 示例里的坑集中在两处：没写字符集，以及没关流。书上的老示例常写new FileReader("data.txt")，用平台默认编码读，换台机器就乱码。现代写法应该显式指定字符集并用 try-with-resources 管住关闭。

import java.io.BufferedReader; import java.io.IOException; import java.nio.charset.StandardCharsets; import java.nio.file.Files; import java.nio.file.Path; public class ReadDemo { public static void main(String[] args) throws IOException { // 路径从命令行传入，避免写死相对路径 Path path = Path.of(args.length > 0 ? args[0] : "data/sample.txt"); // try-with-resources 保证异常路径下也会关闭 try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) { String line; while ((line = reader.readLine()) != null) { System.out.println(line); } } } }

Files.newBufferedReader的第二个参数是字符集，必须显式给。跳过去的话，JVM 会用file.encoding系统属性，而这个属性在 JDK 18 之后默认是 UTF-8、之前则跟随平台，所以你在一台机器上跑得好好的示例，换到同事机器上就乱码。Path.of加上命令行参数的做法是为了避开相对路径问题：相对路径是相对于“启动 JVM 时的当前工作目录”，不是相对于源文件位置，在 IDE 里跑和在命令行里跑，工作目录往往不同，这是新手最常见的“文件明明在那儿却说找不到”的原因。

参数怎么改：把StandardCharsets.UTF_8换成GBK读一个 UTF-8 文件，看乱码长什么样；把args[0]传一个不存在的路径，看异常堆栈的第一行指向哪里。两次实验比读十页 IO 章节管用。

4. 把示例改成自己的练习：断言、参数化、断点三步验证

示例跑通只能说明它能跑，不能说明你懂了。真正的检验是改一处、看输出怎么变、并且能预期到变成什么样。这一步需要三个动作：把控制台输出变成可断言的结果，把硬编码的常量变成可调的参数，把“为什么是这个结果”交给断点和日志。

4.1 用 JUnit 断言把控制台输出固定下来

大量示例的验证方式是System.out.println，你只能用眼睛看。改成返回值的写法之后，就能挂上断言，后面每次改动都能自动回归。

import org.junit.jupiter.api.Test; import java.util.List; import static org.junit.jupiter.api.Assertions.*; public class SortExampleTest { @Test void shouldKeepInsertionOrder() { // 把示例里直接打印的逻辑抽成一个纯函数再断言 List<String> result = Demo.sorted(List.of("b", "a", "c")); assertEquals(List.of("a", "b", "c"), result); } @Test void shouldNotChangeOriginalList() { List<String> input = new java.util.ArrayList<>(List.of("b", "a")); Demo.sorted(input); // 这条断言专门防“示例里悄悄改了入参”这种副作用 assertEquals(List.of("b", "a"), input); } }

第一条断言验证顺序，第二条断言验证副作用。第二条比第一条有价值得多：书上的示例为了演示方便，经常在方法内部直接对入参排序再返回，代码短、看着清楚，但照抄进项目就会埋下“调用方数据被改”的隐蔽缺陷。给每个改造过的示例都补一条“入参没被修改”的断言，这个习惯能挡掉很多后期排查成本极高的 bug。

Demo这个类需要你自己写，做法是把原示例里带 main 的类拆成“纯逻辑方法 + 一个薄薄的 main”。拆分的时候注意保持方法签名里只出现 JDK 自带类型，不要出现Scanner、System.out这些和交互绑定的东西，否则没法在测试里调用。参数怎么改：assertEquals的期望值先故意写错一次，确认测试真的会红——没红过的测试等于没写。

4.2 把硬编码常量抽成配置或命令行参数

示例里到处都是硬编码：文件路径、线程数、循环次数、端口号。这些值在书上是为了让代码短，你拿来练手时必须外置，否则每次实验都要改源码、重新编译。

public class ConfigurableDemo { public static void main(String[] args) { // 有参数走参数，没参数走默认值，保证直接运行也能跑 int threads = args.length > 0 ? Integer.parseInt(args[0]) : 4; String path = args.length > 1 ? args[1] : "data/sample.txt"; System.out.printf("threads=%d path=%s%n", threads, path); // 后面用这两个变量替换原来写死的字面量 } }

这种“参数优先、默认兜底”的写法有两个好处：直接java ConfigurableDemo能跑，java ConfigurableDemo 16 data/big.txt也能跑，不需要改代码。Integer.parseInt这里没做异常处理，是有意的——参数传错就应该立刻炸出来，而不是静默回退到默认值，那样你会以为实验成功了。参数怎么改：把线程数依次设成 1、4、16 跑同一批任务，记录耗时，多核机器上一般能看到先降后平的曲线，这就是“线程数不是越多越好”的直观版本。

4.3 断点与日志：定位示例之间的隐性依赖

有些示例单独跑没问题，放在一起跑就出错，典型原因是静态变量。示例类里如果有static int count这种计数器，同一个 JVM 里跑第二个示例时它不会归零，输出会莫名其妙。这种问题靠读代码很难发现，得靠断点和日志。

在 IDE 里给静态字段的写操作打断点（条件断点设成count > 0更省事），跑一遍完整流程，看是谁在什么时候改了它。命令行环境下可以用jdeps先看依赖关系：

# 查看某个 class 依赖了哪些包，快速判断它是否引用了外部库 jdeps -summary out/ch05 # 递归列出所有类之间的依赖，找循环引用 jdeps -verbose:class out/ch05 | head -40

jdeps的输出能告诉你某个示例类是不是偷偷依赖了第三方 jar。如果-summary里出现了not found，说明这个类引用了包里没提供的库，编译能过是因为你本地恰好有，换台机器就崩。日志这边，最省事的做法是在每个示例的入口方法第一行打一条带类名的日志，跑批量的时候就能看出执行顺序和重复执行：

private static final System.Logger LOG = System.getLogger("demo"); // 入口第一行，标记这次执行，批量跑时特别有用 LOG.log(System.Logger.Level.INFO, "start " + ConfigurableDemo.class.getSimpleName());

用 JDK 自带的System.Logger而不是第三方日志框架，是为了不给示例包引入额外依赖，验证阶段够用就行。

5. 排查清单：示例包在 JDK 版本、编码、路径上的五个翻车点

下面这五条是我在不同机器上重复踩过的，每条按“现象 → 原因 → 解决”写，遇到对应症状可以直接对号入座。

5.1 编译期：语法报错与找不到符号

现象一：javac报illegal start of expression或';' expected，错误位置指向一行看起来完全合法的代码，比如var list = new ArrayList<String>();或者一个switch表达式。

原因：本机 JDK 版本低于示例使用的语法级别。var需要 JDK 10 以上，switch表达式需要 14 以上，record需要 16 以上，文本块需要 15 以上。示例包不会标注每个文件的最低版本，只能靠报错位置反推。

解决：先javac -version确认版本，再决定是升 JDK 还是降级代码写法。不要试图用-source 8之类的方式压过去，语法级别设低了这些结构根本编不过，设高了目标 JDK 又跑不了。稳妥做法是装一个和示例匹配的 JDK，用JAVA_HOME切换，别在同一个环境里反复改。

现象二：报cannot find symbol，符号是一个第三方类，比如ObjectMapper、JSONObject。

原因：示例依赖了外部库，但包里只给了源码没给 jar，作者默认读者会用构建工具自己拉依赖。这类示例往往单独看毫无破绽，编起来就卡住。

解决：先从 import 语句反查包名，判断属于哪个库，再在 pom 里补上。补依赖时版本不要随手填最新，找一个和示例语法风格接近的版本更稳，跨大版本的 API 改动经常让示例直接编不过。补充一条命令，能批量列出所有 import 里非java.*的包：

grep -rh "^import " --include="*.java" . | grep -v "import java" | sort -u

5.2 运行期：编码乱码与路径找不到

现象三：程序能跑，但中文输出全是???或者一堆方块，源文件里的中文注释在 IDE 里也是乱码。

原因：javac 编译时用了平台默认编码读源文件，源文件本身是 UTF-8，两边不一致。运行时的输出编码又是另一套（file.encoding和stdout.encoding），两处都可能出问题。

解决：编译加-encoding UTF-8，运行加-Dfile.encoding=UTF-8，Maven 工程则在 pom 里写死project.build.sourceEncoding。三个地方都要管，只改一处经常还是乱码，容易让人怀疑人生。验证方法很简单：写一个只打印“中文测试”四个字的类，跑通它再回去跑示例。

现象四：NoSuchFileException或者FileNotFoundException，但路径在文件管理器里明明存在。

原因：示例里写的是相对路径，而相对路径的基准是 JVM 的当前工作目录。在 IDE 里跑，工作目录通常是模块根目录；在命令行里跑，工作目录是你执行命令时所在的目录。两者不同，同一个相对路径就指向了不同位置。

解决：先在入口打印System.getProperty("user.dir")确认基准，再把路径改成基于它的绝对路径，或者干脆把数据文件放到 classpath 下用getResourceAsStream读。临时排查可以用Path.of("data/x.txt").toAbsolutePath()打印真实路径，一眼就能看出差在哪一层。

5.3 构建期：同名类互相覆盖

现象五：单独编译某一章没问题，把几章一起编到一个输出目录后，运行时行为变成另一章的逻辑，或者报duplicate class。

原因：不同章节的示例用了相同的包名和类名（比如每章都有一个Main），全量平铺编译时会互相覆盖，后编译的把先编译的顶掉。

解决：按章分输出目录，-d out/ch03、-d out/ch04各自独立，运行时 classpath 只挂当前章。转成 Maven 工程的话，按章拆成多个 module，或者至少在包名上补一层章节前缀。这个问题在 IDE 里反而不容易出现，因为 IDE 通常按模块隔离，所以命令行跑通、IDE 里跑不通（以及反过来）的情况，优先怀疑这一条。

6. 收尾技巧：把示例整理成可检索的片段库

示例包跑通、改造完之后，真正的收益在于沉淀。我的做法是建一个独立的snippets目录，每个示例抽成一个能独立运行的最小类，类名统一带上主题前缀，比如Coll_ArrayListGrow、Conc_PoolReject、Io_BufferedReaderUtf8。前缀的意义在于排序和检索：所有集合相关的片段排在一起，想找线程池的时候敲Conc_就能过滤出来。

配套维护一张索引表，放在目录根下的 README 里，列四栏就够：片段名、对应知识点、关键参数、我踩过的坑。这张表不需要写得多漂亮，它的作用是三个月后你回头找“那个队列满了会怎样的例子”时，能在三十秒内定位到文件，而不是重新翻一遍原包。

整理的节奏上，我一般是一章跑完就沉淀一章，不攒到最后一起做。攒着做的结果是你会对着几十个文件回忆“这个当时是干嘛的”，回忆成本远高于当场写一句备注。

验证环节有一个很实用的习惯：每换一次 JDK 大版本，把 snippets 目录整体重跑一遍。用jshell交互式验证单个片段最快，把片段里的核心几行粘进去，看输出是否符合预期；完整类则用单文件源码启动方式跑。这个回归动作花不了十分钟，但能提前发现“某个 API 在新版本被废弃或行为变了”这类问题。我就吃过亏：一次升级后，某个依赖默认字符集的片段输出全变了，当时没重跑，等到在别处引用这段逻辑时才炸出来，排查了两天才定位到根因在编码默认值上。

从那以后我每次拿到新的示例包，都会先把编译脚本和一份 README 索引跑一遍再动代码，哪怕是看起来最熟的那类语法示例。这套动作看着啰嗦，但它把“环境问题”和“代码问题”彻底分开了，后面所有的排查都省一半力气。希望帮到你。

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