简介：这是适用于64位Windows开发者的Java开发工具包，对应JDK 7 Update 5，内置JRE与完整开发组件，适合运行或调试Java 7应用的工程师，尤其是需要处理大内存、高并发服务端程序的用户。压缩包大小仅15.69MB，结构紧凑，解压后可直接使用，核心目录jdk1.7.0_05中包含了编译、调试、运行所需的全部环境。Java 7引入了Strings in Switch、Try-with-resources、NIO.2文件系统API、Fork/Join并行计算框架等关键特性，对维护旧项目或学习Java演进历程的人员具有直接参考价值。目前已有271人学习浏览，说明该版本仍有实用场景。许多开发者偏爱64位JDK，以获得更高的内存上限和更优的性能表现，这份资源正好满足此类需求。

1. jdk-7u5-windows-x64-demos：64位示例包到底值得装什么

很多人装完64位JDK，顺手就把jdk-7u5-windows-x64-demos这个压缩包扔进回收站，理由是“示例代码又不能上线”。其实这套demos是官方留给开发者的黑匣子说明书：它不是JDK本体，而是把Applet、Swing、Java2D、JConsole插件、JMX管理这些场景的完整可运行示例打包在一起。对一个正在维护Java 7老项目、或者要在无外网环境查API写法的人来说，它比搜索引擎可靠。适合读这篇的人：已经装了64位JDK 7u5、想跑通官方示例、或者需要从源码里抄作业的开发者。

我拆这套包时有一个明显感受：它不像现在框架的example那样只给你一段启动代码，而是把事件处理、渲染循环、JMX扩展点全部摊开给你看。对于刚转Java 7、又必须处理64位Windows兼容问题的人，这份包能帮你在半小时内建立起对官方示例结构的整体判断。下面的内容会先把解压后的目录边界说清楚，再给出一条能直接复现的启动路径，最后把最容易踩的坑列出来。

2. 拆开demos压缩包：从目录结构看清JDK 7u5官方示例的边界

2.1 先分清三件套：demos、JDK安装包、docs独立包

很多人在下载JDK时只认安装文件，看到demos压缩包就存着不管。这里要先把概念理顺：JDK 7u5在64位Windows下至少需要面对两类东西，一是jdk安装文件本体，二是jdk-7u5-windows-x64-demos.zip示例包。如果你还下载过docs压缩包，那算是第三类。它们之间的关系很简单：安装包负责提供java、javac、jconsole这些可执行程序；demos包负责提供示例源码、构建脚本和可以直接打开的HTML演示；docs包则是API文档。

需要特别强调的是，demos包不是给JDK“增强功能”的补丁。解压之后你手里多的是代码和资源，不是新的java命令。我在第一次接触时也犯过傻，以为把demos解压到JDK安装目录就能让JVM多出什么功能，实际上它只是放在旁边的一份参考资料。对想学习JDK 7内部API写法的人来说，这份包的价值在于它保留了官方当年推广技术时的标准用法。

还有一个容易忽略的点：64位demos和32位demos不能混用。部分示例运行时会读取JVM位数相关的系统属性，如果电脑装的是64位JDK，却解压了一份32位demos包，某些启动脚本会拿不到正确路径，甚至出现“Could not reserve enough space”一类的启动错误。所以下载时认准“x64”或“windows-x64”字样。

2.2 核心目录逐个看：applets、jfc、java2d、jconsole、management

解压后我用tree工具列目录，核心结构大概是这样的：

jdk-7u5-windows-x64-demos/ ├── applets/ ├── docs/ ├── jfc/ ├── java2d/ ├── jconsole/ ├── management/ ├── script/ └── src.zip

这里我把冗余文件都省略了，实际目录里还会有build.xml、README.html、sampleTutorial.md之类的入口文件。这个结构对应的是JDK 7时代官方最看重的几个技术方向：老式Applet、Swing组件集、Java2D渲染、JConsole扩展、JMX管理、脚本引擎。对开发桌面应用的人来说，jfc和java2d最值得花时间；做监控工具的人则应该把jconsole和management放在前面。

applets目录下面是一堆独立的小工程，比如ArcTest、BarChart、Blink、CardTest、Clock、DitherTest、DrawTest、GraphLayout、MoleculeViewer、TicTacToe、WireFrame。这些名字看起来像玩具，但每个目录里都有一个完整的生命周期示例，包括init、start、stop、destroy的调用时机展示。如果你还在维护老系统里的Java Web Start或浏览器插件应用，这些代码能告诉你小程序在JDK 7下的标准写法。

docs目录主要是对示例的说明，不是API文档。里面有每个子目录对应的说明页面，也提到运行示例需要的JDK版本。jfc目录是Java Foundation Classes的缩写，亮点在SwingSet2、Notepad、Stylepad。SwingSet2几乎把JDK 7.0时代主流Swing组件都列了一遍，从JButton到JTable，每个组件都有交互代码。Java2D目录则在渲染层面展开，包含渐变填充、抗锯齿、图像合成、文字排版等示例。jconsole目录里的东西比较少见，它是给JConsole做插件扩展的示例，如果你不想用市面上现成的监控工具，完全可以从这里抄一套。management目录对应JMX管理，里面是MBean定义和远程连接的代码。

2.3 目录与典型用途对照：一张表看懂该优先看哪个

不是每个目录都必须从头啃。我给一份按需求出发的查阅顺序表：

这张表是我给开发者做交流时常列的一张表，核心思路是先看“你当前要解决什么问题”，再决定进哪个目录。比如你现在遇到的是JTable刷新卡顿，那应该看jfc里的SwingSet2源码，而不是去刷applets里的弹球动画。反过来，如果你想研究Java 7 64位环境下的渲染路径，看java2d目录比翻JDK源码更直接。

3. 在64位Windows上跑起来：环境变量、编译命令和第一个Demo

3.1 前置检查：确认本机JVM确实是64位

在碰任何示例之前，我一般先执行下面三条命令，确认当前终端环境没有“裂开”：

java -version javac -version echo %JAVA_HOME%

第一条命令会输出JVM版本和运行模式。如果你看到的是Java HotSpot(TM) 64-Bit Server VM或者64-Bit Client VM，说明当前java命令来自64位JVM。如果只看到Java HotSpot(TM) Server VM且没有64位字样，那多半是32位版本在前面的PATH里被优先命中了。第二条命令是为了确认编译器存在且版本是1.7.0_05，JDK 7u5对应的javac版本号通常显示为javac 1.7.0_05。第三条命令则检查JAVA_HOME变量，如果它是空显示或者指向了JRE目录，后续启动脚本很容易翻车。

这三个输出结合起来能判断一件事：当前终端里的工具链是不是“64位JDK 7u5”。很多人踩坑在只装了32位JDK，却解压了x64的demos，然后运行示例时要么找不到类，要么启动即崩溃。你可以直接用where java查看实际命中的java.exe路径，在纯净环境下它应该指向C:\Program Files\Java\jdk1.7.0_05\bin\java.exe，注意这里一定是Program Files而不是Program Files (x86)。

3.2 解压、JAVA_HOME与PATH：老Java项目的第一道门槛

确认无误后，把demos压缩包解压到一个纯英文、不带空格的路径。我习惯放在D:\workspace\jdk-7u5-windows-x64-demos，因为后续要手动编译和运行Ant脚本，中文目录或空格目录会让老式build.xml里的相对路径处理变得很痛苦。

设置环境变量的常用套路如下：

setx JAVA_HOME "C:\Program Files\Java\jdk1.7.0_05" set PATH=%JAVA_HOME%\bin;%PATH%

setx只设置JAVA_HOME这个系统级变量，不会覆盖当前终端里已有的PATH。第二行的set PATH是在当前终端窗口临时把JDK的bin目录拼到最前面，这样后续执行的java、javac、jconsole都来自我们的64位JDK。这里不推荐直接用setx PATH去改系统PATH，因为老版本Windows的setx对PATH变量长度有限制，一旦超过长度，可能把后面所有既有路径截断，这是典型的“装完JDK后别的命令全废”翻车现场。

解压完成后，我会先看一遍根目录下的README.html，虽然内容老但能确认示例包自带的编号版本。接着执行dir看看src.zip和build.xml是否都在。src.zip不是JDK源码，而是示例源码的压缩集合，build.xml是Ant构建脚本，后面编译SwingSet2时会用到。

3.3 三个可复现的Demo运行命令：Applet、Java2D、JConsole

先跑最容易看效果的Applet示例。进入demos根目录后执行：

cd /d D:\workspace\jdk-7u5-windows-x64-demos appletviewer applets\TicTacToe\example1.html

appletviewer是JDK自带的小工具，会在独立窗口中加载HTML里引用的Applet类。它的优势是不需要浏览器插件，也不会被64位浏览器的安全策略拦下来。这个命令里的TicTacToe只是示例路径，换成applets\Clock\example1.html也能跑。要注意，直接双击HTML文件在现在的Windows浏览器里大概率没反应，原因后面避坑章会展开。

接着看Java2D渲染示例。进入jfc\Java2D目录后，如果目录里已经有编译好的jar，直接执行：

java -jar Java2Demo.jar

如果是裸源码状态，就用javac手动编译：

javac -encoding UTF-8 -cp . src\java2d\Java2Demo.java -d out java -cp out java2d.Java2Demo

这里-encoding UTF-8是为了避免源码中注释里的非ASCII字符变成乱码，-d out表示把class文件输出到out目录。Java2Demo是官方2D渲染展示窗口，里面有抗锯齿、Alpha合成、渐变笔刷等一个个可切换的示例页，选一两个切换就能直观看到64位JVM下2D渲染的表现。

最后验证JConsole能不能正常工作。先开一个Java进程，再用jps查进程号：

jps jconsole 12345

把12345换成jps输出里你自己进程的PID。JConsole是JMX客户端，如果它能在64位环境下连上本机JVM，说明JDK安装没有问题。此时再回头看jconsole目录里的插件示例，就具备跑通环境了。

4. 把示例当训练场：源码阅读顺序与JConsole插件实战

4.1 源码阅读顺序：从Notepad到SwingSet2再到Java2D

很多初学者打开src.zip之后不知道该看哪个文件。我给的建议是先读jfc里的Notepad。它的代码量适中，正好覆盖一个桌面应用最核心的部分：窗口初始化、菜单栏构建、事件监听器注册、文本组件操作。读完Notepad再看SwingSet2，你会看到官方是如何把几十种Swing组件组织在一个可交互的浏览界面里。这里重点关注组件之间的事件传播，而不是单个组件API。

看完Notepad和SwingSet2之后，再进Java2D目录。Java2D示例里最值得看的是渲染引擎如何和Swing事件线程配合，比如在paintComponent里拿Graphics2D对象，设置RenderingHints，再做图形变换。在64位Windows上，这部分代码会比32位环境更频繁地触发字体渲染路径，如果你遇到字体发虚或边缘锯齿问题，直接对照Java2Demo里的抗锯齿参数就能找到方向。

阅读顺序上我建议遵循“一个场景一个目标”的原则：比如今天只研究表格排序，那就只看SwingSet2里和JTable相关的源文件，不要试图一次读懂整个包。官方示例的结构是每个目录相对独立，这给按需查阅提供了很大方便。

4.2 JConsole插件实战：JConsolePlugin扩展点怎么用

jconsole目录提供的示例是把自定义面板塞进JConsole的标签页。这个能力对做监控平台很有用。它依赖JDK安装目录下lib\jconsole.jar里的JConsolePlugin抽象类。一个最简插件长这样：

import com.sun.tools.jconsole.JConsolePlugin; import javax.swing.JPanel; import java.util.LinkedHashMap; import java.util.Map; public class SamplePlugin extends JConsolePlugin { @Override public Map<String, JPanel> getTabs() { Map<String, JPanel> tabs = new LinkedHashMap<String, JPanel>(); tabs.put("示例面板", new JPanel()); return tabs; } }

这个类继承了JConsolePlugin，并且重写了getTabs()方法，返回一个带标签名称和面板实例的映射。JConsole启动时如果通过-pluginpath指定了包含这个类的jar包，就会在工具窗口里多出一个名为“示例面板”的标签。编译时要把jconsole.jar放进classpath：

javac -encoding UTF-8 -cp "%JAVA_HOME%\lib\jconsole.jar" SamplePlugin.java jar cf sample-plugin.jar SamplePlugin.class jconsole -pluginpath sample-plugin.jar localhost:9010

第一行编译依赖jconsole.jar，说明这个API位于JDK私有目录下，不属于标准Java SE API。第二行把class打成jar。第三行启动JConsole并连接本地9010端口的JMX服务，同时加载插件。如果连接的是本机进程，localhost:9010也可以换成PID。

这里有一个值得注意的参数：-pluginpath在JDK 7u5里只接受jar路径，不接受多个路径的分号列表，如果需要加载多个插件，要打包到一个jar里或者使用循环加载。示例里的JConsolePlugin在JDK 9之后被模块化包装了，现在再想编译就必须用更复杂的--add-exports，这也是为什么说这套demos和JDK 7u5绑定很深，只适合老环境复现。

4.3 别把官方示例直接搬进生产工程：三个偏离常规的用法

第一个误区是把JConsolePlugin代码直接复制到业务项目里作为监控模块。这个类属于com.sun.jconsole内部包，JDK 7u5下能编译，但升级到新JDK之后很可能会因为模块封装而崩掉。第二个误区是把src.zip当普通第三方库引用。示例代码里大量使用sun.*和com.sun.*内部API，它们不保证长期存在，你把它们放进依赖等于给工程埋雷。第三个误区是使用demo里自带的ant脚本而不做版本检查。这些脚本写于JDK 7年代，里面可能指定了固定的jar路径，换目录或换JDK版本后会出现找不到文件的报错。

我一般只把它们当作“参考实现”，从中摘出事件处理模式、渲染参数和JMX注册流程，重新写在自己的工程里。比如从Java2D示例里抄RenderingHints配置，从management示例里提取MBean注册结构，但绝不直接把class或源码拷到maven项目的src目录。

5. 避坑排查：7u5 demos在64位Windows上的五个翻车现场

5.1 现象：双击Applet HTML没反应

从压缩包解压后，直接双击example1.html，浏览器里什么都没发生，控制台也没有报错。这个现象在64位Windows下特别常见。

原因是JDK 7时代的浏览器Java插件依赖32位或64位进程的匹配关系，而且现代浏览器早就禁用了Java插件。HTML里虽然有<applet>标签，但浏览器已经没有对应的运行时去加载它。再加上本地file://协议对ClassLoader也有约束，很可能还没走到插件层就被拦下了。

解决方法是放弃浏览器，使用JDK自带的appletviewer。在demos根目录执行appletviewer applets\TicTacToe\example1.html，或者用本地HTTP服务器托管整个demos目录，通过http://localhost:8080/...访问HTML。我个人的习惯是只在调试Applet该有的生命周期时才这么做，平时根本不会去碰浏览器。

5.2 现象：编译SwingSet2报“程序包sun.awt不存在”

手工执行javac编译jfc目录里的示例时，报错说找不到sun.awt下的类。某个示例源码里直接引用了sun.awt.X11或sun.awt.*，在Windows环境下这些类位于rt.jar里，按理说javac能自动找到，但如果你用了-Xlint、-source 1.7同时又手动指定了classpath，javac就可能把内部包隔离掉。

原因是这些老示例写于JDK早期，当时官方并不推荐直接使用内部API，但示例为了展示图形能力还是引用了。另一个常见诱因是classpath里混入了其他版本的rt.jar或tools.jar，导致javac看到的sun包来自另一份JDK。

解决方法是优先使用示例目录里自带的build.xml和Ant构建。避免手工javac。如果必须手工编译，就把当前JDK的tools.jar放进编译classpath，并去掉多余的依赖顺序。还要确认你的JAVA_HOME确实指向jdk目录而不是jre目录，因为tools.jar只存在于JDK。

5.3 现象：插件jar包ClassNotFound

用JConsole的-pluginpath加载插件时，JConsole日志提示ClassNotFoundException，或者插件标签页根本没有出现。排查了插件代码也没有发现缺少依赖。

原因通常是打包时class文件放错位置。比如你编译了带包名的类，却直接在class目录下执行jar cf sample-plugin.jar SamplePlugin.class，这样jar包根目录是class散件，没有按包名建目录。JConsole按二进制类名查找，自然找不到。

解决方法是先用jar tf sample-plugin.jar查看包内结构，确认是否存在SamplePlugin.class且路径和包名一致。如果类声明为package demo;，jar里就必须有demo\SamplePlugin.class。打包时应该进入放置类文件的根目录再执行jar命令，例如jar cf sample-plugin.jar demo\SamplePlugin.class。这个排查法同样适用于任何老式Java插件加载问题。

5.4 现象：-Xmx设得过大导致无法启动

运行Java2D示例时，设置-Xmx2048m，结果启动直接报Could not reserve enough space for object heap，或者JVM启动很慢。有人会把锅甩给64位JDK，认为64位就一定支持超大堆。

原因是在老版本的64位Windows JVM上，堆内存申请需要一段连续地址空间，而且系统还要给代码缓存、线程栈等预留空间。如果机器物理内存本身不大，比如4G，又开了浏览器、开发工具，那么申请2G堆时连续地址空间不足就会失败。

解决方法是不要盲目给示例大堆。Java2D示例用-Xmx512m完全够跑。如果你确实需要更大堆，先确认操作系统是64位，再逐步从1G往上试。通过JConsole的“内存”标签页观察堆占用，找到示例真实需要的堆大小，比随手写大参数更可靠。

5.5 现象：Ant找不到javac编译器

进入示例目录执行ant run，Ant报告Unable to find a javac compiler或tools.jar not found。明明javac能用，Ant却说自己找不到。

原因是Ant默认通过JAVA_HOME变量定位JDK。如果JAVA_HOME指向C:\Program Files\Java\jre7而不是C:\Program Files\Java\jdk1.7.0_05，Ant就找不到javac程序。另一种情况是JAVA_HOME指向的是32位JDK目录，但当前Shell里ant脚本来自64位环境，两者在注册表探测上产生冲突，也会导致编译器丢失。

解决方法是在运行Ant前显式固定JAVA_HOME和ANT_HOME：

set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_05 set ANT_HOME=D:\tools\apache-ant-1.9.15 set PATH=%ANT_HOME%\bin;%JAVA_HOME%\bin;%PATH%

第一行确保Ant找到的是JDK而不是JRE，第二行固定Ant版本，第三行把两个bin目录放在最前面。设置后再执行ant -v，看输出里的编译器和classpath是否对应。

6. 把它变成自己的工具包：三个值得长期保留的技巧

6.1 把demos目录做成离线代码模板库

解压后的demos不要塞进任何业务工程，单独放一个固定目录，比如D:\java-7-templates，然后按场景给子目录建书签。我在维护老项目时，遇到JTable自定义渲染器，直接从SwingSet2源码里找TableCellRenderer的实现方式；遇到文字描边问题，就去Java2D源码里搜TextLayout的用法。这个习惯省掉了反复搜索外部资料的时间。

6.2 用插件示例验证本机JMX端口

你不需要真的写一个监控插件才能验证JMX。利用jconsole目录里的插件骨架，编译后启动一个业务程序，然后用jconsole -pluginpath sample-plugin.jar localhost:9010连接。如果示例面板出现，说明本地JMX服务、端口连通性和JConsole插件扩展点全部正常。这个冒烟测试我每次更换JDK路径后都会跑一遍，确认环境没有隐性破坏。

6.3 一个让我少走弯路的检查习惯

我自己经历过一次JAVA_HOME指向jre目录后所有示例全部启动失败的事，从那以后我每次换JDK路径，都强制先跑三条命令：java -version、javac -version、jconsole -J-Djava.class.path=演示路径，再跑一个Applet示例确认当前终端、当前进程、当前JDK版本三者完全匹配。这个习惯帮我避掉了很多“代码写对了但环境不对”的尴尬。希望帮到你。

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