简介：这是一份面向Java开发者的64位Windows平台JDK 7u5开发工具包，适合需要在64位系统上编译、调试和运行Java应用的开发者，尤其是维护早期Java 7项目或学习Java 7新特性的技术人员。压缩包内为jdk1.7.0_05，包含JRE运行环境与JDK开发工具，整体约15.69MB，文件以开发工具与运行库为主，便于快速部署本地Java开发环境。该版本对应Java SE 7 Update 5，涵盖switch字符串、try-with-resources、NIO.2文件系统API、钻石操作符、Fork/Join框架等特性，可帮助读者理解Java 7在语法与性能上的改进。目前已有271人学习下载，适合作为旧项目兼容、教学演示与版本对比的参考资源。
1. 别急着删：jdk-7u5-windows-x64-demos 里到底藏着什么
很多人第一次在旧机器或归档目录里翻到jdk-7u5-windows-x64-demos这个文件夹，第一反应是“这玩意儿还有用吗”。它其实是 JDK 7u5 这个 64 位 Windows 发行包附带的官方示例与演示集合，里面既有 JavaFX 的界面样例，也有 Swing、Applet、NIO、JMX、JAX-WS 等模块的可运行 Demo，还包含配套的源码、资源文件和构建脚本。对今天还在维护老系统、做教学演示、或者需要验证某个历史 API 行为的人来说，它不是垃圾，而是一份能直接跑起来的“活文档”。这篇文章就围绕这个 demos 目录，讲清楚它包含什么、怎么在本地跑通、参数怎么调、以及哪些坑会让新手直接翻车。适合手里有旧 JDK 环境、需要做兼容性验证或教学复现的工程师。
2. 先看清目录结构：jdk-7u5-windows-x64-demos 里到底有什么
拿到一个 demos 包，最忌讳的就是直接双击里面的 jar 或 exe。JDK 7u5 的 demos 在 Windows 64 位发行版里通常以独立压缩包或安装目录下的demo文件夹形式存在，解压后你会看到按技术模块划分的子目录。先花十分钟把结构摸清楚，后面跑任何示例都能少走弯路。
2.1 顶层目录的模块划分与识别方法
典型的jdk-7u5-windows-x64-demos解压后，根目录下会有applets、jfc、jmx、jndi、jpda、scripting、webservices等文件夹。jfc是 Java Foundation Classes 的缩写，里面放的是 Swing 和 JavaFX 的界面示例；applets是早期浏览器内嵌小程序示例；jmx是 Java 管理扩展的监控示例；webservices里则是 JAX-WS 的客户端与服务端样例。识别方法很简单：看每个子目录下的index.html或README，JDK 7 时代的 demos 大多带一个静态说明页，用浏览器打开就能看到该模块的示例列表和运行前提。
如果你不确定某个目录属于哪个技术栈，直接看里面的文件后缀。.java是源码，.jar是可执行包，.html是说明页，.jsp或.xml则多半和 Web 服务相关。我一般会先执行一条命令把目录树打印出来，避免在资源管理器里一层层点：
# 在 demos 根目录下执行，列出两层目录结构 find . -maxdepth 2 -type d | sort这条命令只列目录不列文件，输出干净，能快速看出模块边界。-maxdepth 2控制深度，避免把深层资源目录也刷出来。如果你在 Windows 上用的是 Git Bash 或 WSL，同样适用；纯 CMD 环境下可以用dir /s /b /ad替代，但输出会冗长很多。
2.2 哪些示例在 64 位 Windows 上还能直接跑
不是所有 demos 都能在 64 位 Windows 上顺利运行。Applet 类示例依赖浏览器插件，现代浏览器早已移除相关支持，这部分基本只能看源码不能跑界面。JavaFX 示例在 JDK 7u5 时期还需要单独安装 JavaFX runtime，如果你只装了 JDK 没装 JavaFX，运行时会报缺少javafx.application.Application相关类。Swing 和 JMX 示例则相对独立，只要 JDK 环境变量配好，大概率能直接启动。
判断一个示例能不能跑，最直接的方法是看它的启动脚本。JDK demos 里通常附带.bat和.sh两套脚本，Windows 下优先看.bat。如果脚本里引用了JAVA_HOME并且没有硬编码不存在的路径，那它大概率是可运行的。我一般会先跑一个最简单的 Swing 示例来验证环境，比如jfc/SwingSet2这种经典 Demo，它能启动就说明图形环境和 JDK 基本没问题。
2.3 用命令行确认 JDK 版本与 demos 的匹配关系
jdk-7u5 这个版本号意味着 JDK 7 Update 5，demos 包和 JDK 主版本必须匹配。如果你机器上装的是 JDK 8 或更高版本，部分示例会因为 API 变更而编译失败或运行异常。先确认当前java -version的输出：
java -version # 期望输出类似： # java version "1.7.0_05" # Java(TM) SE Runtime Environment (build 1.7.0_05-b05) # Java HotSpot(TM) 64-Bit Server VM (build 23.1-b02, mixed mode)重点看三处：版本号是否为1.7.0_05，是否标注64-Bit，以及 HotSpot 的 build 号。如果版本号对不上，后面跑示例时出现的NoSuchMethodError或UnsupportedClassVersionError基本都是这个原因。确认无误后，把JAVA_HOME指向该 JDK 安装目录，并把%JAVA_HOME%\bin加入PATH，这是后续所有操作的前提。
3. 跑通第一个示例：从解压到看到界面的完整命令
环境确认之后，下一步就是真正把一个示例跑起来。我建议从 Swing 的经典 Demo 入手，因为它对额外依赖要求最少，出问题时排查路径也最短。下面以jfc/SwingSet2为例，把解压、编译、运行三个阶段拆开讲。
3.1 解压与目录切换的注意事项
jdk-7u5-windows-x64-demos 通常是一个 zip 包，解压时要注意路径中不要包含中文或空格。Windows 下如果解压到C:\Users\某用户\Downloads\这种带中文的路径，后续javac编译时可能因为编码问题报unmappable character错误。我一般会解压到一个纯英文短路径，比如D:\jdk7demos\。
# 假设压缩包已下载到当前目录 unzip jdk-7u5-windows-x64-demos.zip -d /d/jdk7demos/ # 进入 SwingSet2 示例目录 cd /d/jdk7demos/demo/jfc/SwingSet2/unzip的-d参数指定解压目标目录，确保目标目录事先存在或由命令自动创建。如果你在纯 Windows 环境没有unzip，可以用资源管理器右键解压，但之后要在 CMD 里用cd /d D:\jdk7demos\demo\jfc\SwingSet2切换盘符和目录。注意cd /d中的/d是 CMD 参数，不是路径的一部分。
3.2 编译与运行 SwingSet2 的最小命令集
进入目录后，你会看到SwingSet2.java以及一堆配套的.java和资源文件。JDK 7 时代的示例通常不依赖 Maven 或 Gradle，直接用javac编译即可。但 SwingSet2 的源码里引用了图片和音频资源，编译时需要把资源路径也考虑进去。
# 编译当前目录下所有 java 文件，输出 class 到当前目录 javac -encoding UTF-8 -d . *.java # 运行主类，注意类名大小写 java -cp . SwingSet2第一行javac的-encoding UTF-8是为了防止源码中的非 ASCII 字符导致编译失败，-d .表示把编译出的.class文件放在当前目录，保持包结构。第二行java -cp .把当前目录加入类路径，然后指定主类SwingSet2。如果一切正常，你会看到一个带标签页的 Swing 窗口，里面包含按钮、表格、树等组件示例。
3.3 运行失败时先看这三个输出信号
如果窗口没出来，不要急着重装 JDK。先看命令行输出，通常三类信息能定位大部分问题。第一类是Exception in thread "main" java.lang.NoClassDefFoundError，说明类路径不对或某个依赖类没编译出来；第二类是java.lang.UnsupportedClassVersionError，说明编译用的 JDK 和运行用的 JDK 版本不一致；第三类是图形相关的HeadlessException，说明当前环境没有可用的显示设备，这在远程桌面或服务端环境下很常见。
针对第一类问题，检查javac是否真的把所有.java都编译了，可以用ls *.class看输出数量。针对第二类，重新确认java -version和javac -version是否指向同一个 JDK。针对第三类，如果你确实在无图形界面的环境里，那 Swing 示例本身就不适合作为验证目标，换 JMX 或 NIO 的命令行示例更实际。
4. 参数与配置：让 demos 按你的环境跑起来
示例能跑起来只是第一步，实际使用中经常需要调整内存、编码、安全策略等参数。JDK 7u5 的 demos 里不少示例对运行参数有隐含要求，不改参数就会遇到各种玄学问题。这一章把常见参数按场景拆开讲。
4.1 内存与编码参数：-Xmx 和 -Dfile.encoding 怎么设
SwingSet2 这类界面示例默认堆内存可能偏小，加载大量图片时容易卡顿甚至 OOM。我一般会显式指定堆上限：
java -Xmx512m -Dfile.encoding=UTF-8 -cp . SwingSet2-Xmx512m把最大堆设为 512MB，对大多数 demos 足够；-Dfile.encoding=UTF-8强制文件编码为 UTF-8，避免读取资源文件时中文乱码。这两个参数在 JDK 7 时代就已是标准选项，不需要额外依赖。注意-D参数必须写在-cp之前或之后但要在主类之前，否则会被当成程序参数传给主类。
4.2 JMX 示例的端口与认证配置
jmx目录下的示例通常需要开启 JMX 远程监控端口。默认配置可能只监听本地，或者要求认证。以jmx里的MBeanServer示例为例，运行时需要加：
java -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=9999 \ -Dcom.sun.management.jmxremote.authenticate=false \ -Dcom.sun.management.jmxremote.ssl=false \ -cp . Main这四个-D参数分别控制：开启 JMX 远程、指定端口 9999、关闭认证、关闭 SSL。authenticate=false和ssl=false只建议在本地实验环境使用，任何对外暴露的场景都必须开启认证和 SSL，否则等于把管理接口裸奔在网络上。端口号如果被占用，换成 9998 或 10000 即可，但要注意防火墙是否放行。
4.3 安全策略文件与权限报错的处理
部分 demos 在启用 SecurityManager 时会读取java.policy文件。如果你看到java.security.AccessControlException: access denied这类报错，说明当前策略文件没有授予示例所需的权限。JDK 7u5 的 demos 目录下有时会附带一个policy子目录或.policy文件，运行时通过-Djava.security.policy=路径指定：
java -Djava.security.manager \ -Djava.security.policy=./demo.policy \ -cp . Main-Djava.security.manager启用安全管理器，-Djava.security.policy指定策略文件路径。策略文件里用grant语句声明权限，格式是grant { permission java.io.FilePermission "<<ALL FILES>>", "read"; };这种。改策略文件时要遵循最小权限原则，不要直接给AllPermission，否则示例跑通了但留下了安全隐患。
5. 避坑与排查：jdk-7u5-windows-x64-demos 最常见的五类翻车
这一章记录的是我在不同机器上复现这些 demos 时真实踩过的坑，每条按现象、原因、解决三段写。新手遇到问题可以先对照这里，大概率能省下不少搜索时间。
5.1 现象：双击 bat 闪退，命令行却能看到报错
原因：.bat脚本里通常有pause或没有，闪退说明脚本执行到某一步失败后窗口自动关闭。解决：不要双击，直接在 CMD 里执行该 bat，或者在脚本末尾手动加pause。更稳妥的做法是打开 bat 看它实际调用了哪条 java 命令，然后手动在命令行执行那条命令，报错信息就能完整看到。
5.2 现象：编译时报“找不到符号”但源码明明存在
原因：JDK 7u5 的某些示例依赖tools.jar或jconsole.jar，这些包不在标准rt.jar里，需要显式加入类路径。解决：在javac和java命令里加-cp "%JAVA_HOME%\lib\tools.jar;."，注意 Windows 下类路径分隔符是分号，Linux 下是冒号。如果还是找不到，检查JAVA_HOME是否指向 JDK 而不是 JRE，JRE 目录下没有tools.jar。
5.3 现象：JavaFX 示例启动时报缺少运行时组件
原因：JDK 7u5 时期 JavaFX 尚未完全并入 JDK，需要单独安装 JavaFX SDK 并配置JAVAFX_HOME。解决：确认是否安装了对应版本的 JavaFX runtime，并在启动脚本里加入-Djavafx.runtime.path指向安装目录。如果只是学习目的，可以跳过 JavaFX 示例，优先跑 Swing 和 JMX 部分，它们对额外组件依赖更少。
5.4 现象：中文资源显示为方块或乱码
原因：示例资源文件可能用 GBK 或 ISO-8859-1 编码保存，而 JVM 默认编码在 Windows 中文环境下是 GBK，在英文环境下是 Cp1252，两边不一致就乱码。解决：统一用-Dfile.encoding=UTF-8启动，并确认源码文件本身也是 UTF-8 编码。如果资源文件是二进制图片，乱码问题通常出在字体缺失，需要在系统里安装对应中文字体。
5.5 现象：JMX 连接被拒绝或超时
原因：端口未监听、防火墙拦截、或者jmxremote.port参数没生效。解决：先用netstat -ano | findstr 9999确认端口是否处于 LISTENING 状态。如果没有，检查-Dcom.sun.management.jmxremote.port是否拼写正确，以及是否被其他 JVM 参数覆盖。如果端口在监听但外部连不上，检查 Windows 防火墙入站规则，临时关闭防火墙测试，确认后再按需放行。
6. 进阶用法：把 demos 改造成自己的验证脚手架
跑通官方示例之后，更有价值的做法是把这些 demos 当成验证脚手架，用来测试你自己在老版本 JDK 上的代码行为。我一般会挑一个结构清晰的示例，比如jfc/CodePointInputMethod或jmx/FullThreadDump，把它的主类改造成一个可参数化的测试入口，然后逐步替换里面的业务逻辑。
具体做法是：先复制整个示例目录到工作区，保留它的构建脚本和资源结构；然后把主类里的main方法改造成读取命令行参数的形式，用args控制测试场景；最后在关键路径上插入日志输出，方便对比不同 JDK 版本下的行为差异。这样做的成本很低，因为示例本身已经解决了类路径、资源加载、图形初始化这些琐碎问题，你只需要关注自己的验证目标。
另一个实用技巧是利用 demos 里的index.html做本地文档索引。JDK 7u5 的 demos 说明页虽然样式老旧，但里面列出了每个示例的用途和运行前提，把它用浏览器打开并加入书签，比每次去翻目录快得多。如果说明页里的链接失效，可以直接看同目录下的README或build.xml，后者往往包含更准确的编译和运行指令。
验证方法上，我习惯用同一份 demos 在 JDK 7u5 和更高版本上各跑一遍，记录哪些示例行为一致、哪些报错、哪些输出不同。这份对比记录本身就是很有价值的兼容性参考。最后说个血泪经验：改 demos 源码之前先备份原始目录，因为有些示例的资源路径是硬编码的相对路径，你挪动一个文件就可能导致整个示例找不到图片或配置文件。希望帮到你。
本文还有配套的精品资源，点击获取
