简介jdk-7u5-windows-x64-demos 对应 Java SE 7 Update 5 的 64 位 Windows 开发包解压后得到 jdk1.7.0_05 目录内含 JRE 运行环境以及 javac 编译器、调试器等开发工具适合需要搭建 Java 7 编译环境、维护旧版本项目或系统学习 Java 7 语言特性的初中级开发者。压缩包为 zip 格式体积约 15.69MB上游未提供文件数量与类型明细从发行内容看包内以 JDK 标准目录为主开发工具与运行环境两部分齐备。资源已有 272 人学习下载。就内容而言Java 7 引入的 switch 支持字符串、try-with-resources 自动关闭资源、钻石操作符与泛型类型推断改进、NIO.2 文件系统 API、Fork/Join 并行框架以及多异常捕获等特性都能在该版本中实际编码验证配合 64 位寻址与 G1 收集器还可观察大内存场景下的运行表现便于对照旧项目代码理解版本兼容性差异对需要向后兼容旧系统的团队来说是一个可直接部署的参考基线。1. 一个装完就被忘掉的目录jdk-7u5-windows-x64-demos 这个包多数人是在装 64 位 JDK 7 时顺手勾上的装完就再没打开过。它不是运行时也不是文档而是一批能直接编译、直接跑的官方示例源码Swing 的自定义组件、JNI 的本地库调用、JMX 的 MBean 注册、NIO 的选择器与文件锁几乎每个都能单独拎出来当一个最小工程看。这类东西的价值不在于“学 Java 语法”而在于你能看到一套完整程序从入口、资源加载到线程调度的真实写法而不是被教程截断过的片段。先给一个反直觉的结论这个包里绝大部分示例是纯 Java跟 32 位还是 64 位没有半点关系真正和 x64 强绑定的只有 JNI 那一小撮。所以别一上来就担心位数问题先跑起来再说。2. 拆包demos 目录里哪几块还值得动手拿到包后第一件事不是编译是认清结构。JDK 7 时代的 demo 目录分区相对固定但不同小版本之间会有增删我见过有人拿一份整理好的清单去对照另一份包结果对不上就以为包是坏的。正确的做法是自己先dir一遍再决定从哪个目录下手。2.1 目录分块与对应的技术栈先按用途给一个粗分方便你决定时间花在哪目录主要内容今天还值不值得看jfcSwing 组件、文本编辑器、表格、字体与 2D 渲染值得Swing 在内部工具里仍然在跑appletsApplet 演示含 2D 动画与绘图参考绘图代码运行方式已过时jniJNI 调用与 Invocation API值得DLL 那套流程十年没变jmxMBean、监控与管理端点值得思路可直接迁移nioChannel、Selector、文件锁值得网络编程入门材料rmi远程方法调用了解即可启动顺序有讲究security签名、策略文件、权限控制概念仍然通用soundJava Sound 的播放与采集冷门但代码完整scriptingJSR-223 脚本引擎调用接口层面的最小样例如果你只有一两个晚上的时间我建议按 jfc → jni → nio 的顺序看这三块覆盖了桌面、本地库、网络三条主线其余按兴趣挑。applets 和 rmi 可以先跳过前者跑起来麻烦后者在现代工程里基本被替换掉了。2.2 先跑 jar三行命令验证 64 位工具链很多示例目录里已经带了打好的 jar不用编译就能先确认环境是对的。以 jfc 下那个经典的 Swing 演示集为例命令很短set JAVA_HOMEC:\Java\jdk1.7.0_05 set PATH%JAVA_HOME%\bin;%PATH% java -version三行之后输出里必须出现64-Bit Server VM字样。如果显示的是Client VM或者干脆没有位数信息说明PATH里排在前面的不是这份 64 位 JDK后面所有编译都会跑偏。确认完再执行cd /d %JAVA_HOME%\demo\jfc\SwingSet2 java -jar SwingSet2.jarcd /d里的/d是必须的否则在当前盘符之外切换会失败这是批处理里最常见的低级错误之一。java -jar走的是 jar 内的 Manifest 主类所以不需要写 classpath也不需要管源码在哪。窗口能弹出来、组件能拖拽、主题能切换就说明这份 demos 和你机器上的 JVM 是配套的。提示JAVA_HOME路径里不要带空格和中文。带空格的路径在某些示例的构建脚本里不会被引号包住报错信息还特别含糊。2.3 编译第一个源码示例先找 main 方法jar 能跑不代表源码能编。挑一个纯 Java、无外部依赖的示例目录先定位入口类别靠猜文件名。Windows 下用findstr扫一遍最快cd /d %JAVA_HOME%\demo\jfc findstr /s /c:public static void main *.java输出会直接告诉你哪个文件里有主方法。这一步看起来笨但能省掉“我以为是 Main.java 结果是 Demo.java”的来回折腾。定位到之后进到该示例的src目录编译cd /d %JAVA_HOME%\demo\jfc\某示例\src javac -encoding UTF-8 -d ..\classes *.java java -cp ..\classes;. 主类名-d ..\classes让编译产物和源码分开避免.class文件撒得整个 src 都是-cp里的;.是把当前目录也加进去因为不少 Swing 示例会按相对路径读同目录下的图片和配置文件。如果启动后界面正常但缺图标、缺皮肤八成就是资源没进 classpath这个坑在第 5 章还会细说。3. 用 7u5 的 javac 编译示例编码、target 与 classpath编译这些示例真正的门槛不在语法而在工具链对齐。demos 里的代码是按 JDK 7 的 API 写的有些地方会碰到当时还没被封禁的内部实现用你机器上现装的 JDK 17、JDK 21 去编报错会非常难看。所以第一条原则很硬编示例就用包里这套 7u5 的 javac。3.1 环境对齐先确认 amd64 而不是 Client VMjava -version只能看到运行时的位数看不到java.home指向哪里。真正确认要用属性输出java -XshowSettings:properties -version 21 | findstr /i java.home os.arch java.version三个关键值java.home应当指向jdk1.7.0_05\jreos.arch应当是amd64java.version应当是1.7.0_05。三者有任何一项不对后面的编译结果都不可信。os.arch显示x86是 32 位 JVM 的典型特征这种情况下你编出来的 class 仍然能跑但一旦涉及 JNI 就必然崩因为 64 位 JVM 拒绝加载 32 位 DLL。还要确认javac和java来自同一套 JDKwhere java where javac两条输出应该在同一目录下。装过多个 JDK 的机器上PATH里经常是java指向新的、javac指向旧的或者反过来症状是编译通过的代码运行时报UnsupportedClassVersionError版本号差一截。这种情况不要试图改代码先改PATH。3.2 批量编译脚本与每个参数的作用示例多的时候一个个手敲不现实。写个批处理把常见参数固化下来注意每个参数都不是装饰echo off setlocal set JAVA_HOMEC:\Java\jdk1.7.0_05 set SRC%~1 set OUT%~2 if not exist %OUT% mkdir %OUT% %JAVA_HOME%\bin\javac -encoding UTF-8 -source 1.7 -target 1.7 ^ -Xlint:-options -d %OUT% -cp %OUT% %SRC%\*.java if errorlevel 1 ( echo 编译失败检查 classpath 与编码 exit /b 1 ) echo 编译完成%OUT%参数逐个说清楚-encoding UTF-8决定源码里非 ASCII 字符按什么解码示例代码本身多是英文但你自己加的注释大概率是中文不加这条在某些终端下会直接报“编码 GBK 的不可映射字符”-source 1.7 -target 1.7是显式钉死语言级别和字节码版本防止有人把脚本挪到新 JDK 上跑出意外行为-Xlint:-options只是把“source 7 已过时”这类警告压掉不影响结果-d和-cp同时指向输出目录是为了让同一批源码里互相引用的类在编译期就能找到。errorlevel判断别省。批处理不会因为 javac 失败就自动停后面接着跑java会得到一个更难懂的NoClassDefFoundError反而掩盖了真正的问题。3.3 资源文件与第三方 jar 的处理不少示例不是单个类它依赖同目录的 properties、图片、音频甚至依赖 demo 目录下某个共享的 jar。判断方法很直接dir /s /b *.jar dir /s /b *.properties先看示例根目录有没有lib之类的子目录再看源码里getResource或getResourceAsStream的路径字符串。Swing 示例里的皮肤、图标通常走Class.getResource它按 classpath 查找所以资源必须和 class 在同一个 classpath 根下或者你手工把资源目录也加进-cp。java -cp ..\classes;..\resources;. 主类名第三方 jar 用分号追加即可Windows 上分隔符是;不是:这一点从 Linux 迁过来的人经常写错。如果示例的 README 里提到某个 jar 但目录里找不到先别急着去外面找替代品翻一遍上一级目录很可能整个 demo 树共享一个公共 lib。4. JNI 与 applet64 位 DLL 和已经死掉的插件这两块是 demos 里最容易劝退人的部分原因完全不同JNI 是位数和编译工具链的问题applet 是整个运行载体没了。分开处理别混在一起调试。4.1 JNI 示例的完整链路javah、gcc -m64、java.library.path注意一个时代细节JDK 7 还没有javac -h这个选项生成头文件要用javah。很多照着新教程操作的人卡在这一步以为命令写错了其实是版本差异。最小可跑的例子长这样public class NativeMath { static { // 库名不带前缀和后缀Windows 下对应 nativemath.dll System.loadLibrary(nativemath); } public native int add(int a, int b); public static void main(String[] args) { System.out.println(2 3 new NativeMath().add(2, 3)); } }生成头文件并编译本地库javac -encoding UTF-8 NativeMath.java javah -jni -classpath . NativeMath gcc -m64 -shared -I%JAVA_HOME%\include -I%JAVA_HOME%\include\win32 ^ -o nativemath.dll NativeMath.c java -Djava.library.path. NativeMathjavah -jni产出的头文件里函数签名是固定的JNIEXPORT jint JNICALL Java_NativeMath_add这个JNICALL在 32 位 Windows 上展开成__stdcall在 64 位下被忽略——所以 32 位时代常加的-Wl,--add-stdcall-alias在 x64 上可以不加加了也不影响但不要以为它是必须的。gcc -m64这个参数是整条链路的核心。MinGW 如果装的是 32 位版本-m64会直接报不支持这时候换工具链比改代码快。-I两个 include 目录一个都不能少jni.h在第一个jni_md.h在win32子目录下少一个就是编译期找不到类型定义。-Djava.library.path.是运行时告诉 JVM 去哪找 DLL。这个属性必须在启动命令行上传程序里System.setProperty改它是无效的因为 native 库的搜索路径在 JVM 初始化阶段就定了。这是血泪经验见过太多人把setProperty写在main第一行然后对着一模一样的UnsatisfiedLinkError怀疑人生。4.2 applet 示例的最后可用方式与改写骨架applets 目录下的示例现在只有一种方式能跑起来用 7u5 自带的appletviewer。浏览器端的 Java 插件早已不被现代浏览器支持装插件这条路走不通也不用浪费时间找。cd /d %JAVA_HOME%\demo\applets\某个示例 %JAVA_HOME%\bin\appletviewer 示例.html注意appletviewer在更高的 JDK 版本里已经被移除所以你只能用这套 7u5 的。这也是为什么建议把整个 demos 和它配套的 JDK 放在一起别指望用新 JDK 去跑老载体。如果你真正想要的是里面的绘图逻辑改写比修环境划算。Applet 到 JPanel 的映射关系很固定// 原 Applet 写法init / paint / destroy public class DemoApplet extends java.applet.Applet { public void init() { /* 初始化组件 */ } public void paint(Graphics g) { /* 绘制 */ } } // 改写后构造器 / paintComponent public class DemoPanel extends JPanel { public DemoPanel() { /* 原 init 的内容搬到这里 */ } Override protected void paintComponent(Graphics g) { super.paintComponent(g); // 必须先调用否则背景残留 // 原 paint 的绘制代码 } }三个要点paint改成paintComponent且方法首行必须super.paintComponent(g)init里的组件装配搬到构造器Applet上用到的getParameter改成从配置或构造参数传入。搬完之后套一个JFrame就能跑比折腾插件省事得多。4.3 需要多进程的示例RMI 与 JMX 的启动顺序rmi 和 jmx 目录下的示例不是单进程能跑通的顺序错一步就卡住。RMI 的固定顺序是先起注册表再起服务端最后起客户端。start rmiregistry 1099 java -cp . -Djava.rmi.server.codebasefile:/%CD%/ 服务端主类 java -cp . 客户端主类rmiregistry必须单独起一个窗口它是个常驻进程。codebase指向的是类文件的根目录用file:协议时路径分隔符在 Windows 上仍然是/写成反斜杠会解析失败。JMX 示例反过来服务端先起并开管理端口再用jconsole连java -Dcom.sun.management.jmxremote.port9999 ^ -Dcom.sun.management.jmxremote.authenticatefalse ^ -Dcom.sun.management.jmxremote.sslfalse 服务端主类 %JAVA_HOME%\bin\jconsole关掉认证和 SSL 只适合本机调试别把这个参数组合带到任何对外暴露的环境里。JMX 示例本身是用来演示 MBean 注册与属性暴露的把jconsole连上、能在 MBean 树里看到自己注册的条目这个示例就算吃透了。5. 避坑与排查五个真实翻车现场5.1 装完发现根本没有 demo 目录现象JDK 装好了bin、jre都在就是找不到demo。原因安装器里 Demos and Samples 是独立组件默认不一定勾选另外只装 JRE 的机器上永远不会有这个目录。解决重新运行安装程序在组件选择里勾上示例那一项或者单独取这个 demos 包解压到 JDK 根目录下目录名保持一致即可示例不依赖安装注册表。5.2 UnsatisfiedLinkError 与位数错配现象JNI 示例编译通过运行时抛UnsatisfiedLinkError提示里带Cant load IA 32-bit .dll on a AMD 64-bit platform。原因DLL 是 32 位编译器产出的而 JVM 是 64 位。位数必须严格一致没有兼容模式。解决用-m64重编 DLL同时确认where gcc指向的是 64 位工具链。判断 DLL 位数可以用dumpbin /headers nativemath.dll看 machine 字段x64 对应 8664。5.3 用新 JDK 编译老示例报内部 API 错误现象程序包 sun.misc 不存在或com.sun.* 是内部专用 API可能会在未来版本中被删除编译直接失败。原因这些示例是按 JDK 7 的 API 面写的部分代码碰了当时的内部实现新版 JDK 把它们封了。解决换回 7u5 自带的javac。如果一定要在新 JDK 上编只能逐个改源码替换内部 API成本远高于直接用老工具链不划算。5.4 Swing 示例能起窗口但资源全丢现象界面出来了但图标是空白、皮肤不生效控制台偶尔打印getResource返回 null 的堆栈。原因资源文件没进 classpath。Class.getResource是按 classpath 根查找的源码目录里的图片不会自动跟着.class走。解决把资源目录显式加进-cp或者编译后手工把 properties、图片拷到输出目录对应位置。稳妥做法是编译前先看一遍源码里的资源路径字符串按路径结构在输出目录里建同样的层级。5.5 appletviewer 找不到或 applet 白屏现象appletviewer命令不存在或者窗口开了但一片白。原因前者是用了更高版本的 JDK那个工具已被移除后者多半是 html 里的applet标签路径写错或者示例本身要求文件读写权限被安全策略拦了。解决用 7u5 的bin目录下的appletviewer白屏先看 html 里code和archive属性的相对路径再考虑权限问题涉及本地文件访问的示例在 appletviewer 里会抛SecurityException这类示例直接走 4.2 的改写路线更省时间。6. 把示例改成自己的骨架一份验证清单示例看懂了不等于会用。我的习惯是挑一个结构清晰的 Swing 示例把包名、类名全改掉删到只剩窗口骨架再从零往上加自己的逻辑。删的过程中如果编译不过说明你还没真正理清类之间的依赖能删到只剩一个空窗口还编译通过这套骨架才算你的。抽取分三步走先把入口类和主窗口分离入口只留main和启动调用再把界面构建拆成独立方法或独立类所有add、setLayout集中在一处最后把资源加载统一收口到一个工具方法里路径只写一次。三步做完示例就变成了可复用的模板而不是一坨不敢动的代码。改造完交付前按这张表跑一遍比凭感觉靠谱检查项命令期望结果JVM 位数java -XshowSettings:properties -versionos.arch amd64编译产物版本javap -verbose 主类 | findstr majormajor version: 51本地库加载java -Djava.library.path. 主类无UnsatisfiedLinkError资源可达启动后逐个点开菜单与图标无空白图标、无 null 堆栈多进程示例按注册表→服务端→客户端顺序启动三段日志依次出现major version: 51对应 Java 7 的字节码如果你看到 61 或 65说明编译用的不是这套 7u5 的javac混进了新工具链。最后说个教训。早年我图省事直接拿机器上现装的新 JDK 去编这些示例报错信息看得一头雾水改了两天源码才发现问题根本不在代码而在工具链版本对不上。从那以后我每次碰这种带版本烙印的示例包都先把JAVA_HOME、where java、os.arch这三项强制走一遍确认干净了再动手编译省下来的时间远超这几条命令的开销。这套 demos 现在还在我硬盘里留着偶尔要写个 Swing 小工具或者调一段 JNI翻出来比搜教程快。希望帮到你。本文还有配套的精品资源点击获取