简介这是适用于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-demos64位示例包到底值得装什么很多人装完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 目录与典型用途对照一张表看懂该优先看哪个不是每个目录都必须从头啃。我给一份按需求出发的查阅顺序表目录主要内容优先看的场景appletsApplet生命周期示例维护老系统、理解浏览器内小程序jfcSwing组件、Notepad、Stylepad桌面界面开发、事件分发java2d2D图形渲染示例绘图、图表、图像处理jconsoleJConsole插件模板开发JVM监控面板managementJMX管理示例MBean封装、指标采集script脚本引擎示例在Java中集成脚本语言这张表是我给开发者做交流时常列的一张表核心思路是先看“你当前要解决什么问题”再决定进哪个目录。比如你现在遇到的是JTable刷新卡顿那应该看jfc里的SwingSet2源码而不是去刷applets里的弹球动画。反过来如果你想研究Java 7 64位环境下的渲染路径看java2d目录比翻JDK源码更直接。3. 在64位Windows上跑起来环境变量、编译命令和第一个Demo3.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_05JDK 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.htmlappletviewer是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 MapString, JPanel getTabs() { MapString, JPanel tabs new LinkedHashMapString, JPanel(); tabs.put(示例面板, new JPanel()); return tabs; } }这个类继承了JConsolePlugin并且重写了getTabs()方法返回一个带标签名称和面板实例的映射。JConsole启动时如果通过-pluginpath指定了包含这个类的jar包就会在工具窗口里多出一个名为“示例面板”的标签。编译时要把jconsole.jar放进classpathjavac -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同时又手动指定了classpathjavac就可能把内部包隔离掉。原因是这些老示例写于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 runAnt报告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_05Ant就找不到javac程序。另一种情况是JAVA_HOME指向的是32位JDK目录但当前Shell里ant脚本来自64位环境两者在注册表探测上产生冲突也会导致编译器丢失。解决方法是在运行Ant前显式固定JAVA_HOME和ANT_HOMEset JAVA_HOMEC:\Program Files\Java\jdk1.7.0_05 set ANT_HOMED:\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版本三者完全匹配。这个习惯帮我避掉了很多“代码写对了但环境不对”的尴尬。希望帮到你。本文还有配套的精品资源点击获取
