企业官网建设流程全解析

简介：一份面向Java开发者的JDK 1.7.0_03免安装版工具包，同时包含JDK与JRE，适用于需要快速部署开发环境、或在受限系统中使用Java的开发者与运维人员。压缩包大小为70.23MB，以rar格式封装，内含编译器、解释器、虚拟机和运行时库等完整组件，解压到指定目录即可使用，无需安装。资源已吸引196人学习下载，适合做Java基础学习、应用调试或环境迁移的备用工具。其中javac负责编译源码，java负责执行字节码，JVM提供内存管理与垃圾回收，javadoc和jar可辅助文档生成与归档，jdb支持断点调试；同时涵盖Java 7新增的try-with-resources、多异常捕获、钻石操作符及字符串switch等特性。无论是新手还是经验丰富的开发者，都能借助这套工具快速编写、测试和运行Java程序，减少环境配置成本。

1. JDK 1.7.0_03 开发工具：都什么年代了，为什么还有人专门找它装

现在的开发环境里，十台机器有八台装的是比 1.7 新得多的 JDK，但如果你接手的是一个跑了好几年的老系统，反倒会满世界找 jdk1.7.0_03 这个开发工具。这个版本号代表两层意思：一是 Java 7 早期的更新版本，二是安装包里同时含 JDK 和 JRE，既能编译源码，也能独立跑程序。它真正擅长解决的场景非常具体：老项目的构建脚本只认 1.7 的环境、第三方依赖库锁定在 Java 7、或者服务器上原本就是拿 1.7.0_03 编出来的部署包。适合维护遗留系统、复现老环境的人；要是从零起新项目，就不建议选这个版本了。

2. 拆开安装包看结构：JDK 与 JRE 的分工，以及 1.7.0_03 的目录里有什么

2.1 为什么一个安装包要拆成 JDK 和 JRE 两套

JDK 的全称是 Java Development Kit，JRE 的全称是 Java Runtime Environment。从用途上讲，JDK 是给开发人员准备的，里面带的 javac、javadoc、jar 这些命令负责把源码变成可执行的 class 文件，再帮你做文档、打包这类杂活；JRE 是给运行环境准备的，只有虚拟机、核心类库和配套的启动命令，目标很单纯，就是把已经编译好的 class 和 jar 跑起来。一个 JDK 安装包里总是连着一个 JRE，是为了让开发者编译完马上能在同一台机器上运行验证，不用再单独去找一份 JRE 装上。

很多第一次装 1.7.0_03 的人会困惑：装完 JDK 之后，文件夹里怎么又冒出一个 jre 子目录？这个子目录就是 JDK 自带的运行时。如果拿工具箱打比方，JDK 是整套工具，JRE 就是里面那把最常用的电钻；生产环境只需要跑 .jar 包时，往往只要一把电钻就够了，不需要整套工具箱。理解这层关系，后面到部署阶段才知道该往服务器上拷什么、不该拷什么。生产环境只跑 jar 的场景下，理论上只装 JRE 就够，但很多老教程千篇一律地让装完整 JDK，结果服务器上堆了一堆用不上的开发工具，既占空间又扩大了出问题的面。

这里还要提醒一个 1.7.0_03 特有的细节：这个时代还允许单独下载一个公共 JRE 安装包，它和 JDK 内部那个 jre 子目录并不完全等价。公共 JRE 会往系统目录里写东西，会注册一些系统级入口；JDK 下的 jre 子目录更干净，跟着 JDK 走。遇到多版本 JDK 共存的机器，我一般只保留 JDK 里的 jre 子目录，不去额外装公共 JRE，少一个干扰源。

2.2 装好后目录里有什么，哪些是每天要碰的

安装完成后，在 JDK 根目录下能看到这样一批东西。

bin 和 jre 这两个目录是重点。bin 目录下的 javac.exe 是编译入口，java.exe 是运行入口。配置环境变量这件事，本质上就是把 bin 目录加进 PATH，让系统知道去哪里找 javac 和 java。要注意的是，bin 目录下的 java.exe 和 jre/bin 目录下的 java.exe 有细微差别：bin 下的启动器会优先去找当前 JDK 所自带的运行环境；jre/bin 下的则是纯运行时入口。日常开发直接用 JDK 的 bin 目录就行，不要自己绕到 jre/bin 里去。

lib 目录里那个 tools.jar 在 1.7 时代经常被老配置引用，但 javac 已经不需要你在 CLASSPATH 里手动指定它了。很多从 JDK 1.5、1.6 时代走过来的教程会说一定要把 tools.jar 和 rt.jar 加进 CLASSPATH，这在 1.7 里纯属添乱，后面第 3 章会展开说。src.zip 是个容易被忽略的好东西，把它加到 IDE 的源码附件里，调试的时候能直接跳进 JDK 内部代码里看实现，比对着网页找类方便得多。db 目录是内嵌的数据库组件，平时基本用不到，留着也不碍事。

3. 装出一个干净的 1.7.0_03 环境：环境变量配置与最小命令

3.1 装之前先定三件事：位数、目录和公共 JRE

第一件事，位版本。1.7.0_03 分 32 位和 64 位安装包，Windows 上如果不确定系统是哪个版本，到系统信息里看一眼。64 位系统装 64 位包，32 位系统只能装 32 位包。混装的后果通常是 java -version 能正常输出，但后面挂本地库，比如用 JNI 调 .dll 时直接失败，而报错信息又绕，很难让人第一时间想到是位数没对上。

第二件事，安装目录。Windows 的默认路径一般落在 C:\Program Files\Java\jdk1.7.0_03，目录名带空格，后面配置环境变量时用 %JAVA_HOME% 和引号就能兜住。如果安装时把路径手动改到带中文或空格的目录，部分老脚本解析环境变量时可能会出问题。Linux 上则注意不要用带空格和中文的路径，避免写 shell 脚本时变量切割出错。

第三件事，公共 JRE 到底装不装。安装向导里默认会勾选“公共 JRE”，如果这台机器上只打算用这一个 JDK，装上也行；如果机器上已经装了其他版本的 JDK，我建议取消勾选。原因前面说过，多个公共 JRE 会在系统里互相注册，把版本选择弄得一团糟。JDK 自带的 jre 子目录完全够用，没必要额外装一个。

Linux 上从官方下载页拿到压缩包后，操作比 Windows 简单，从零开始只需三步：

mkdir -p /opt/java tar -zxvf jdk-7u3-linux-x64.tar.gz -C /opt/java ls /opt/java/jdk1.7.0_03/bin/java

逻辑说明：先把目录建好，再把压缩包解压到 /opt/java 下，最后确认一下 java 可执行文件在不在。tar 后面那串参数里，z 表示解压 gzip 压缩包，x 是解包，v 输出过程，f 指定包文件名。把包名换成你实际下载到的那个 jdk-7u3-linux-x64.tar.gz，系统位数对不上时文件名里也一眼能看出来。

3.2 环境变量配置：JAVA_HOME、PATH 与 CLASSPATH 的取舍

Windows 上我推荐用“编辑系统环境变量”的图形面板操作，比命令行 setx 稳得多。这里给一个命令行写法，方便你写脚本或远程操作时用：

setx JAVA_HOME "C:\Program Files\Java\jdk1.7.0_03" /M setx PATH "%JAVA_HOME%\bin;%PATH%" /M

逻辑说明：第一行把 JAVA_HOME 持久化为系统级变量，/M 表示写进系统环境变量，需要管理员权限；第二行把 JDK 的 bin 目录追加到 PATH 最前面。setx 的作用范围是之后启动的新进程，所以配置完一定要开新的命令行窗口，旧窗口里读到的还是老环境变量。

参数说明：第二行的坑其实不小。setx 对 PATH 这个变量的写入有长度限制，而且把当前 PATH 值带进去再写出来，一旦原来 PATH 里有其他 JDK，旧版本会排在前面，新窗口里 java -version 依然可能命中旧版本。所以我一般不是特别推荐用命令行去改 PATH，图形界面里手动把 %JAVA_HOME%\bin 上移到顶部更直观。如果你就是要用脚本批量部署，记得先备份原 PATH 再操作。

Linux 上的配置就清爽一些，把下面这段写进 /etc/profile.d/java.sh 或当前用户的 ~/.bashrc：

export JAVA_HOME=/opt/java/jdk1.7.0_03 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.

逻辑说明：export 是把变量导出为环境变量，JAVA_HOME 指向 JDK 根目录，PATH 把 JDK 的 bin 放在最前面。CLASSPATH 在这里只设一个点，表示当前目录，甚至可以完全不设置。source 一下让配置立即生效。

source /etc/profile.d/java.sh java -version javac -version

参数说明：JAVA_HOME 就是给后面的 IDE 和构建工具用的，必须精确指到根目录，后面不要多写斜杠，也不要指向 bin。PATH 里 $JAVA_HOME/bin 必须出现在原 PATH 前面，否则系统先找到旧版本。CLASSPATH 保持点号就可以，不要按老教程去加 tools.jar 和 rt.jar；在 1.7 里这类 JDK 内部库已经有自己的加载机制，手动加进全局 CLASSPATH 反而可能引发奇怪的类加载问题。

配置完成后，看到 java version "1.7.0_03" 和 javac 1.7.0_03 这两行输出，就说明安装干净了。如果 java -version 和 javac -version 的结果不一致，直接翻到第 5 章的避坑清单。

4. 用 JDK 1.7.0_03 跑通最小程序：javac、java 与 jar 的完整链路

4.1 写源码并编译：javac 的 -encoding 和 -d 参数

先建一个干净的工作目录：

mkdir -p work/src && cd work/src

把下面的文件保存为 Hello.java，注意让编辑器把文件存成 UTF-8 编码：

public class Hello { public static void main(String[] args) { System.out.println("这是 JDK 1.7.0_03 编出来的程序"); } }

编译命令：

javac -encoding UTF-8 -d ../classes Hello.java

逻辑说明：javac 是 JDK 自带的编译器，-encoding UTF-8 告诉它源码文件按 UTF-8 读，避免中文平台下猜错编码；-d ../classes 指定 class 文件的输出目录，目录不存在时 javac 会顺手创建出来。Hello.java 是源码文件路径，必须给出，javac 不像某些解释型语言那样可以直接执行源码。

参数说明：如果项目引用了第三方 jar，javac 还需要加 -cp 参数，比如 javac -encoding UTF-8 -cp ../lib/commons.jar -d ../classes Hello.java。-cp 和 -classpath 是同义词，后面跟的路径是“需要查看的类所在位置”。等 class 文件多起来，你会发现 -d 这个参数能省很多事，它让源码目录和编译产物目录分家，不会搞出一堆 .class 堆在源码旁边。

编译完检查一下：ls ../classes 应该看到 Hello.class。class 文件名和 public 类名一致，如果一个源码文件里定义了多个类，就会生成多个 class 文件。这个点后面打包时很关键。

4.2 运行：java 命令后面跟的是类名，不是文件名

很多第一次用命令行的人会写成 java Hello.class，这个在 JDK 1.7.0_03 下直接报错。正确写法是：

java -cp ../classes Hello

逻辑说明：-cp ../classes 告诉虚拟机去哪个目录找 class 文件，Hello 是类名，虚拟机根据这个名字去找 ../classes/Hello.class。把类名当成逻辑名称，而不是文件路径，这是 java 和 javac 最容易被忽略的区别。如果你运行后一直报“找不到或无法加载主类”，优先检查当前工作目录、-cp 路径和类名大小写。类名是区分大小写的，Hello 和 hello 不是同一个类。

参数说明：这个例子里的 -cp 是可以替换成 -classpath 的，作用完全一样。有些人会图方便，把 class 文件直接扔到当前目录，然后不加 -cp 直接 java Hello，因为默认 classpath 包含当前目录，这样跑通。但一旦引入第三方依赖，不加 -cp 就寸步难行，所以建议从第一步开始就把 -cp 写明白。

4.3 打包成可执行 jar：jar 命令的 c、f、v、e 参数

编译运行都通了，下一步是打包。先回到 classes 目录：

cd ../classes jar cvfe app.jar Hello .

逻辑说明：c 表示 create，v 是 verbose，输出打包过程中的文件列表，f 指定 jar 文件名 app.jar，e 指定主类 Hello，最后那个点表示把当前目录下所有内容打进去。jar 会把 Hello.class 收进来，并自动生成 META-INF/MANIFEST.MF 清单文件，里面多一行 Main-Class: Hello。有了这一行，运行时才能直接用 java -jar 启动。

运行打包出来的 jar：

cd .. java -jar classes/app.jar

参数说明：如果打包时不用 e 参数，那 MANIFEST.MF 里就没有 Main-Class，java -jar 会报“无主清单属性”。补救办法有两种：重新用 jar cvfe 打一次包，或者先 jar cvf app.jar Hello.class，再用 jar ufe app.jar Hello Hello.class 把主类信息补进去。老项目里更常见的方式是让构建脚本把 Main-Class 写进一份自定义清单文件，然后 jar cvfm app.jar manifest -C classes .，这里 m 表示读取清单文件。1.7 版的 jar 命令还不支持后来流行的那种长参数写法，主流的还是这一套短参数。

这里顺带解释一下 4.3 那个点号的坑：jar cvfe app.jar Hello . 是在 classes 目录里执行的，点号代表当前目录。如果你站在 classes 的上一层，想打 classes 里的内容，要写成 jar cvfe app.jar Hello -C classes .，其中 -C 表示先进入指定目录再取文件。少写 -C，会把 classes 这个目录本身也打进去，运行时就可能找不到主类。

5. JDK 1.7.0_03 避坑实录：版本、路径与迁移的五个翻车点

5.1 java -version 和 javac -version 各说各话

现象：装完 1.7.0_03，java -version 输出 java version "1.8.0_xx" 甚至更高，而 javac -version 输出 javac 1.7.0_03，或者反过来。

原因：操作系统 PATH 里同时存在多个 JDK 的 bin 目录，命令解释器按 PATH 从左到右查找，先碰见哪个就用哪个。很多情况是之前装的旧 JDK 路径没清理，或者装 1.7.0_03 时公共 JRE 把自己注册到了更靠前的位置。

解决：Windows 上先执行 where java 和 where javac，看实际命中的路径；然后打开系统环境变量编辑框，把 %JAVA_HOME%\bin 移到最顶部，或者把旧版本的 bin 路径直接删掉。Linux 上则用 which java 和 which javac 定位，再用 update-alternatives --config java 选择目标版本。改完一定要开新终端，旧窗口里不会自动刷新。

5.2 javac 编译通过，java 运行却找不到主类

现象：在源码目录里执行 java Hello，虚拟机直接报“找不到或无法加载主类 Hello”。这时候扭头一看，Hello.class 明明就在当前目录。

原因：java 命令是按 classpath 找类的，默认 classpath 是当前目录，但如果你用了 -cp 参数却又把路径指错，或者当前终端的工作目录不在 class 文件所在目录，就会扑空。还有一类原因是类名拼写和文件名不一致，大小写没对上也算。

解决：统一改成 java -cp ./classes Hello，并且保证 Hello.class 存在于 classes/Hello.class。养成习惯：编译时用 -d 指定输出目录，运行时用 -cp 指向同一个目录，两者始终配套，这类问题基本不会出现。不要相信“把 class 放当前目录就不用 -cp”这种偷懒写法，它只会让问题晚点暴露。

5.3 整个 JDK 目录拷到另一台机器后，java.exe 直接翻车

现象：为了省事，把安装好的 JDK 文件夹整个打包，复制到另一台同配置机器，解压后 java -version 要么报缺少 jvm.dll，要么窗口一闪而过。

原因：安装版 JDK 在安装时不仅释放文件，还会在系统里写入路径信息，注册组件。JDK 1.7 的运行时依赖 jre/bin/client 或 jre/bin/server 目录下的 jvm.dll，这些 DLL 的相对位置一旦在拷贝过程中被打乱，虚拟机就起不来。公共 JRE 被单独安装到系统目录时，情况更复杂。

解决：不要拿安装版 JDK 的目录整个打包。需要迁移时，优先用官方压缩包在目标机器上重新解压一遍，再配置环境变量。如果只能拷贝，那就单独拷贝 jre 子目录，并在目标机器保持完整的 bin 和 lib 相对关系；拷过去之后一定先 java -version 验证，再交给业务程序。这是环境迁移里最常见的血泪经验，省那几分钟解压时间，后面往往要花几小时排查。

5.4 中文源码在 Windows 下编译成乱码

现象：源码在编辑器里显示正常，用 javac 一编译，字符串里的中文变成“銆愮被”这类乱码，或者编译直接报“编码 GBK 的不可映射字符”。

原因：javac 1.7 默认按操作系统的默认字符集读源文件。中文 Windows 的默认字符集是 GBK，如果源码保存成 UTF-8，javac 就会按 GBK 去读，读出来的字节自然对不上。

解决：编译命令统一加 -encoding UTF-8，这是最直接的解药。更稳妥的做法是把源码文件统一保存为 UTF-8，并在构建脚本里固定这个参数。IDE 工程里把项目编码和编译器编码同时设成 UTF-8。乱码一旦进了 class 文件，运行阶段再想办法转码也没有意义，只能重新编译。

5.5 用新 JDK 编译的 class 放到 1.7.0_03 上运行报版本不支持

现象：在一台装了新版 JDK 的机器上编译出 class，拷贝到只装 1.7.0_03 的服务器上运行，报 UnsupportedClassVersionError，提示 class 文件由更新版本的 Java 运行时编译。

原因：class 文件头部带一个类文件版本号，虚拟机启动时会检查自己支持的最高版本。1.7.0_03 的虚拟机对应版本号是 51.0，新 JDK 默认生成的 class 版本比这个高，自然跑不了。

解决：最稳的方案是在 1.7.0_03 本机上完成编译。如果必须用新版 JDK 来编，那就在 javac 参数里加 -source 1.7 -target 1.7，并且代码里不能用 Java 7 之后新增的 API，否则要么编译报错，要么运行期找不到方法。生产环境里我习惯在构建脚本里固定这两个参数，避免今天这个人编、明天那个人编，最后产出一个谁也跑不了的包。

6. 进阶用法：多版本共存、编译目标控制与 JRE 单飞

6.1 多版本 JDK 切换：一套 Windows 切换脚本

开发机上难免同时有 1.7 和更高版本，推荐用一条批处理脚本：

@echo off set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_03 set PATH=%JAVA_HOME%\bin;%PATH% java -version javac -version

逻辑说明：新开一个命令行窗口执行它，当前窗口的环境变量就切到 1.7.0_03。JAVA_HOME 和 PATH 的修改只对当前进程及其后启动的子进程生效，所以每次切换都开新窗口。这个脚本只改当前窗口，不动系统环境变量，适合临时做多版本测试。

6.2 固定编译目标版本：source 与 target 配合使用

javac -source 1.7 -target 1.7 -encoding UTF-8 -d classes Hello.java

逻辑说明：-source 决定编译器允许使用的 Java 语言版本，-target 决定生成的 class 字节码版本。两个参数要一起给，只给 -target 1.7 但代码里用了高版本语法时，编译器可能通过，可生成逻辑已经超出 1.7 虚拟机能力，运行期容易出 NoSuchMethodError。

6.3 让 JRE 单独上场：运行环境的减法

生产部署时只装 JRE，不装 JDK。把 JDK 目录下的 jre 子目录单独拷到干净路径，或者直接用官方 JRE 包，然后只需要：

export PATH=/opt/jre/bin:$PATH java -jar app.jar

这样目录体积从 JDK 的几百 MB 降到 JRE 的一百多 MB，还少掉了 javac、javadoc 这类开发命令，避免生产环境多出不必要的工具。部署前用 java -version 确认 JRE 版本和编译环境完全一致，别在最后关头发现版本对不上。

我早年图省事，把整个 JDK 目录拷来拷去，翻车过不止一次；后来学聪明了，开发机安安静静装一个 1.7.0_03，生产机只放一个干净的 JRE，两边版本对齐，问题少了大半。希望帮到你。

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