2022年8月这个时间点JDK 18发布才几个月JDK 17作为长期支持版本已经稳了大半年可翻一翻身边真正在跑的项目十有八九还是JDK 8打底。Eclipse和JDK的安装说起来是入门级操作但每年新来的同事卡在这一步的比比皆是环境变量配完cmd里敲java有反应、敲javac却提示不是内部命令Eclipse双击半天没动静Tomcat一点启动就甩出一句找不到主类。这篇就把JDK安装和Eclipse安装这两件事从头到尾捋一遍重点放在那些教程里不写、但实际一定会撞上的问题上顺带把汉化、Tomcat接入、常见报错的排查思路也一并说清楚。不管你是完全没碰过Java的新手还是换机器重新配环境的老手下面这些内容应该都能直接抄作业。1. 2022年装JDK版本和下载渠道先定下来装JDK最容易犯的错不是操作而是版本随手选。2022年8月这个节点能选的主要是三条线JDK 8、JDK 11、JDK 17。它们不是新旧关系而是三个各自有明确使用场景的分支选错了后面会一直别扭。JDK 8对应的内部版本号是1.8.0_xxx虽然早就停止公开更新但存量项目最多。很多公司的老系统、老框架、老构建脚本都默认跑在它上面尤其是一些十年前起家的业务代码直接升到高版本会因为模块化、反射限制、第三方库兼容问题炸出一堆莫名其妙的错误。如果你接手的是别人写好的项目第一件事就是去看它的pom.xml或者build.gradle里写的source和target是多少再决定装哪个JDK。JDK 11是过渡期的长期支持版本模块系统已经稳定同时保留了足够的兼容性。当年不少中间件和工具链的文档默认环境就是11比如某些版本的Maven插件、某些性能分析工具。JDK 17则是目前最值得用来开新项目的版本语法上带了密封类、记录类型这些实用特性垃圾回收器的默认表现也更好。代价是它移除了一批老API比如javax.xml.bind那一套如果项目里用了JAXB做XML解析升到17就得手动补依赖。提示如果机器上要同时跑老项目和新项目别纠结三个都装用的时候切换JAVA_HOME就行比强行统一版本省事得多。下载渠道这块2022年国内主要有两条路。一条是走官方站点拿Oracle JDK好处是文档和教程都按它写坏处是下载慢而且部分版本需要登录账号才能拿到安装包。另一条是走镜像拿OpenJDK的构建版本速度飞快。清华的镜像站里就有Adoptium项目提供的Temurin构建路径大概长这样https://mirrors.tuna.tsinghua.edu.cn/Adoptium/进去之后按大版本号分目录再按操作系统和架构分最后是tar.gz或者zip包。这种构建和Oracle JDK在功能上几乎没差别日常开发、跑单元测试、搭本地服务完全够用。还有一个容易被忽略的点安装包形式。Windows上你拿到的大概率是两种一种是jdk-17_windows-x64_bin.exe这种安装器另一种是jdk-17_windows-x64_bin.zip这种压缩包。安装器会往系统里写注册表、往C:\Program Files\Common Files\Oracle\Java\javapath塞一套快捷方式这个目录后面会给你带来一个非常经典的坑。压缩包则是解压即用目录干净可控。我个人在开发机上更倾向压缩包因为路径完全掌握在自己手里卸载的时候直接删目录不留尾巴。最后提一句别把JDK装到带空格和中文的路径里。C:\Program Files\底下虽然能装但很多构建工具、老版本插件在处理路径空格时会有解析问题中文路径更是灾难现场。统一放到C:\Java\或者D:\dev\这种纯英文无空格的目录下能省掉后面一大堆玄学问题。2. Windows下从解压到环境变量跑通的完整过程假设你已经下载好了压缩包接下来这十分钟的操作决定了后面几个月顺不顺。整个过程分四步解压、配JAVA_HOME、配Path、验证。先说解压。新建一个D:\dev\目录把压缩包解进去你会得到类似jdk-17.0.4.1这样的文件夹。这里有个细节如果你后面还打算装第二个JDK建议在目录名上做区分比如D:\dev\jdk-8和D:\dev\jdk-17别用jdk1.8.0_301这种带小版本号的长名字。原因很简单将来升级小版本的时候目录名变了所有引用它的配置都得跟着改用大版本号命名升级时直接把内容替换掉配置一行不用动。接下来是JAVA_HOME。在系统属性里找到环境变量面板新建一个系统变量名字叫JAVA_HOME值填JDK的根目录注意是根目录不是bin也不是里面的jre。填D:\dev\jdk-17是对的填D:\dev\jdk-17\bin是错的填D:\dev\jdk-17\jre也是错的。这个错误极其常见因为很多老教程里的截图就是这么配的看着能跑实际上后面用Maven、用Tomcat的时候会因为找不到工具链而报错。然后是Path。在系统变量的Path里新增一条%JAVA_HOME%\bin。这里有个顺序问题Windows查找命令是按Path从上往下找的谁在前面谁生效。如果你之前装过Oracle的安装器版本系统Path里会有一条C:\Program Files\Common Files\Oracle\Java\javapath那个目录里有java.exe但没有javac.exe。它要是排在%JAVA_HOME%\bin前面你会看到一种很迷惑的现象敲java -version能显示版本敲javac -version却提示找不到命令。解决办法就是把%JAVA_HOME%\bin上移到最前面或者干脆把那条javapath删掉。CLASSPATH这个东西现在基本不需要配了。十几年前的教程会让你配.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar其中tools.jar在JDK 9之后就随着模块系统一起消失了再照抄会得到一个指向不存在文件的路径。现代Java的类加载靠的是模块路径和构建工具CLASSPATH留空反而更干净。真要配也只需要一个半角句点加英文分号表示当前目录。配完之后必须重开命令行窗口已打开的cmd和PowerShell不会自动读取新变量。验证用下面这几条java -version javac -version echo %JAVA_HOME% where java在PowerShell里写法略有不同$env:JAVA_HOME where.exe java java -version四条命令各有用意。前两条确认运行时和编译器都在且版本一致第三条确认JAVA_HOME指向正确第四条最有价值它会列出系统里所有叫java的可执行文件及其路径如果输出的第一行不是你配的JDK目录那就说明Path顺序还有问题。这个where命令是我排查环境问题时的第一招比反复检查环境变量面板快得多。还有一种情况值得一提你改的是系统变量但用户变量里也有一条同名的JAVA_HOME或者Path条目。Windows的规则是用户变量和系统变量会合并用户变量的Path会被追加到系统Path后面但同名的独立变量比如JAVA_HOME用户变量会覆盖系统变量。所以如果你发现改了半天没效果去用户变量那一栏也看一眼八成是那里藏了一个。3. Eclipse解压启动这一步卡住的人比想象中多Eclipse的下载比JDK要简单一些但版本和包类型的选择同样有讲究。Eclipse是每年四个发布节奏3月、6月、9月、12月各一版2022年8月能拿到的最新稳定版是2022-06内部版本号4.24。这个命名方式的好处是你能一眼看出它有多老遇到问题搜资料时也方便对号入座。下载页面里最让人眼花的是那一串包类型。对大多数人来说只需要在下面这两个之间选Eclipse IDE for Java Developers和Eclipse IDE for Enterprise Java and Web Developers。前者精简适合写普通的Java程序、做算法练习、跑单元测试后者预装了Web开发相关的一大堆插件包括JPA、JSF、Web服务工具、Maven集成等要做Servlet、JSP、Spring项目就选它。如果你现在不确定直接选企业版多出来的插件占不了多少空间但需要的时候能省一次折腾。下载地址除了官网的https://www.eclipse.org/downloads/packages/国内镜像同样可用清华的https://mirrors.tuna.tsinghua.edu.cn/eclipse/下面按版本分目录速度会快很多。拿到的一般是个zip包Eclipse是绿色软件解压就能用不需要安装。解压路径的规则和JDK一样纯英文、无空格。我见过太多人把Eclipse放在D:\我的软件\开发工具\eclipse下面结果启动时报一堆找不到路径的错。workspace的选择也值得单独说一句。第一次启动时Eclipse会让你指定工作空间目录这个目录是放你所有项目的地方默认会在用户目录下建一个eclipse-workspace。我的建议是主动指定到D:\workspace\这样的独立目录理由有两个一是路径短某些老插件对长路径支持不好二是好备份直接整个目录拷贝走就行换机器的时候省事。真正让人卡住的是启动本身。双击eclipse.exe之后没反应或者弹一个对话框说A Java Runtime Environment (JRE) or Java Development Kit (JDK) must be available in order to run Eclipse这是最典型的症状。原因只有一个Eclipse没找到可用的JDK。虽然你已经配了JAVA_HOME但Eclipse启动器的查找逻辑和命令行不完全一样它优先读的是自己目录下的eclipse.ini。解决方式是手动在配置文件里指定。用文本编辑器打开Eclipse根目录下的eclipse.ini你会看到一堆-vmargs之类的参数。要让Eclipse用指定的JDK需要加两行-vm D:/dev/jdk-17/bin/javaw.exe两个注意点。第一这两行必须写在-vmargs这一行的前面写在后面会被当成JVM参数处理直接报错。第二路径分隔符用正斜杠或者双反斜杠都行单反斜杠会被当转义符。还有一种情况是路径里有空格那就把路径单独占一行不要和-vm挤在同一个行里。启动成功之后有几个设置我建议第一次进去就改掉省得后面被编码问题折磨。打开Window Preferences General Workspace把Text file encoding从默认的GBK改成UTF-8。这一步不做的话中文注释在团队协作时会出现乱码而且往往是你这边看着正常同事那边打开一堆问号。顺手在同页面下面把换行符统一成Unix格式跨平台协作时能少很多无意义的diff。字体在General Appearance Colors and Fonts Basic Text Font里改Consolas或者等宽中文字体都行看代码眼睛舒服很多。4. 汉化、Tomcat和第一个能跑起来的Web页面汉化这件事我的态度是可以装但要想清楚代价。Eclipse官方不提供多语言包中文界面靠的是Babel项目。安装路径是Help Install New Software在Work with里填Babel的更新站点地址大概是https://download.eclipse.org/technology/babel/update-site/latest/等它把可选项拉出来之后展开Babel Language Packs in Chinese (Simplified)勾上主语言包和需要的子包一路下一步装完重启就行。有两个坑。第一个是版本匹配Babel的站点地址带年份和月份如果你拿latest去装老版本的Eclipse可能出现装完没效果或者插件冲突。第二个坑更实际汉化之后网上搜到的教程、报错信息、菜单路径全是英文的你对着中文界面找不到对应的选项反而更慢。所以我个人的做法是界面保持英文只在明确需要展示给不熟悉英文的人看的时候才装汉化包。Tomcat的接入是很多人装完Eclipse之后的第一件正事。流程是这样先在Window Preferences Server Runtime Environments里点Add选你本地的Tomcat大版本然后勾上Create a new local server再把Tomcat installation directory指到你解压Tomcat的目录。这一步的目录同样要求纯英文无空格。然后切到Servers视图新建一个Server实例把项目添加进去。这里有个概念要分清Eclipse默认不会用你Tomcat目录里的webapps而是在工作空间里复制一套配置叫Servers项目。你在Eclipse里改了端口、改了部署路径改的是这套副本跟原始Tomcat目录没关系。很多人改完server.xml重启发现没生效就是因为改错了文件。找不到或无法加载主类 org.apache.catalina.startup.bootstrap这条报错几乎每个用过Eclipse跑Tomcat的人都见过。它的字面意思是Java虚拟机拿到了一个类名但在classpath里找不到对应的字节码。bootstrap类的全名是org.apache.catalina.startup.Bootstrap它就在Tomcat的bin/bootstrap.jar里面。所以问题一定出在JVM启动时的那条命令行里bootstrap.jar没有出现在classpath上或者路径指向了一个不存在的位置。排查思路是这样别急着改配置先去看Eclipse实际拼出来的那条命令。在Server视图里双击你的Tomcat实例打开配置页面点右下角的Open launch configuration切到Arguments标签你会看到完整的classpath列表。逐条检查找到bootstrap.jar那一条复制路径去文件管理器里粘贴一下看文件到底在不在。绝大多数情况下你要么会发现路径指向的Tomcat目录已经被移走或改名了要么那一条压根就不存在。如果路径不对回头改Tomcat的安装目录配置如果路径不存在说明你的Tomcat包下载不完整或者解压过程中断重新解压一份如果一切看起来都对但还是报错去检查这个Server用的JRE是不是被换成了一个残缺的JDK。还有一个不太常见但确实存在的情况Tomcat目录路径里带了空格或者中文JVM参数在传递过程中被截断classpath从中间断开后面的条目全部失效。至于用Eclipse写HTML并预览这事比想象中简单但也有个必须知道的限制。新建项目的时候可以选Static Web Project或者直接在任意项目里新建一个.html文件。写完之后右键文件Open With Web Browser就能在Eclipse内置的浏览器里打开。问题是内置浏览器的渲染内核非常老旧现代CSS里的flex、grid还有ES6以上的JavaScript基本都不支持。所以我的习惯是右键选Open With System Editor直接调用系统默认浏览器这才是靠谱的预览方式。真要调试页面还是老老实实把浏览器打开用它的开发者工具Eclipse在这方面帮不上太多忙。5. 五类高频报错按现象倒推原因环境配好之后下一个阶段的痛苦来自各种启动报错。这些报错有个共同特点提示信息都很短但原因可能藏得很深。我按出现频率排了排下面这几类基本能覆盖八成情况。报错关键信息真实原因处理方向Unsupported class file version 52.0运行时JRE版本低于编译时JDK版本统一编译级别和运行JRE找不到或无法加载主类classpath里缺目标jar或路径失效检查launch configurationdx unsupported class file version构建工具链条里的JRE版本不匹配换工具链用的JDK找不到jdkEclipse未定位到JDK检查eclipse.ini的-vm项目全红但没有报错Build Path里的JRE被移除重新指定JRE System Library先说Unsupported class file version这一族。Java的class文件里有个版本号不同JDK编译出来的号不一样这里列几个常见的数字对应Java版本52.0Java 855.0Java 1161.0Java 1762.0Java 18看到class file version 61.0但下面接着一句this version of the Java Runtime only recognizes class file versions up to 52.0意思就很明确了字节码是17编的但运行它的JRE只有8。反过来如果是Unsupported class file version 52.0而你装的是JDK 17那说明构建链条里有个环节在用老版本的JRE去读新字节码。Android项目里的dx工具是重灾区它本身要跑在JDK上如果它拿到的JDK版本和项目编译用的版本对不上就会甩出这个错。处理方式是做三处统一Project Properties Java Build Path Libraries里的JRE System LibraryJava Compiler里的Compiler compliance level以及运行配置里用的JRE。这三处必须指向同一个大版本缺一处都会出问题。再说JDK版本切换也就是从17降到8或者反向操作。很多人只知道改Build Path改完发现还是报错因为漏了别的地方。完整清单是这样的Java Build Path里的JRE System Library要换Java Compiler的compliance level要跟着改如果项目是Maven的pom.xml里的maven.compiler.source和maven.compiler.target要改如果是Web项目Project Facets里的Java版本也要改。最容易漏的是最后一项Facets不改Eclipse在某些构建路径下会按老版本处理编译出来的东西和你想的不一样。还有一个隐蔽的坑Maven项目里右键Maven Update Project这个动作会把.classpath和.settings下的配置文件重新生成一遍你在Eclipse界面上手动改的Build Path很可能被覆盖掉。所以在Maven项目里改JDK版本正确做法是先改pom.xml再执行Update Project而不是反过来。找不到jdk这个提示和前面说的Eclipse启动失败是同一类问题但触发场景不同。有时Eclipse能启动但新建项目时提示找不到JDK那说明eclipse.ini里的配置没问题问题出在Installed JREs这个设置上。进Preferences Java Installed JREs看看列表里有没有正确指向JDK根目录的条目没有就手动Add一个类型选Standard VMJRE home指向JDK根目录然后把它勾成默认。项目里全是红叉但Problems视图没有明显报错这种最折磨人。八成是Build Path里的JRE System Library被标记成了unbound也就是绑定的JRE被删了或者换了位置。解决方法是进Java Build Path把那条unbound的库移除重新Add Library选JRE System Library指向当前有效的JDK。6. Linux环境、离线插件和其他几个绕不开的扩展Linux下装JDK的逻辑和Windows完全不同因为你有包管理和手动解压两条路。apt install default-jdk这类命令确实能装上但它装的版本取决于发行版的仓库而且装完之后JAVA_HOME不一定会自动配好多版本切换也要靠update-alternatives。对开发机来说我更推荐手动解压的方式可控性高得多。流程是这样从镜像站下载tar.gz包解压到/usr/local/下面比如/usr/local/jdk-17。然后编辑/etc/profile在末尾加上export JAVA_HOME/usr/local/jdk-17 export PATH$JAVA_HOME/bin:$PATH改完执行source /etc/profile让它生效。注意PATH里要写成$JAVA_HOME/bin:$PATH把JDK的bin放在前面否则系统自带的java还是会抢先。如果只想给当前用户配改~/.bashrc效果一样影响范围小一些。有多版本需求的话可以用update-alternatives --install把几个JDK都注册进去之后用update-alternatives --config java交互式切换。离线插件这个需求在企业内网环境里特别常见比如Activiti的BPMN设计器。正常安装是Help Install New Software然后填更新站点地址但内网机器连不上外网就得走离线路线。做法是在有网的机器上把插件包下载成zip拷到目标机器然后在Install New Software的界面里点Add这次不填URL而是点右边的Archive按钮选中那个zip文件。Eclipse会把它当成一个本地仓库来解析后面的步骤和在线安装一模一样。这里有个经验离线包的依赖必须完整。有些插件在安装时还要拉别的插件作为依赖在线装的时候Eclipse会自动帮你找离线装就找不到。所以要么下载官方打包好的完整版要么提前把依赖关系理清楚。装完重启如果发现功能没出现去Help About Eclipse Installation Details里看看插件有没有被列进去没列进去就是没装成功。内存分析工具MAT是另一个常被提到的扩展。它有两个形态一个是独立的桌面程序一个是能嵌进Eclipse的插件。独立版的好处是不依赖Eclipse版本插件版的好处是能直接在IDE里打开工程关联的heap dump。需要注意的是新版本的MAT对JDK版本有要求跑在JDK 8上的话可能要用老一点的MAT版本版本搭配错了会直接启动失败这一点在下载页面上一般会有说明别跳过。类图查看是阅读别人代码时的刚需。Eclipse本身对类图的直接支持有限社区里比较常用的方案有两个一个是ObjectAid UML Explorer这类插件装上之后能对选中的类生成UML图但它已经很久没更新了在新版Eclipse上不一定能装另一个是用PlantUML写文本描述生成图虽然要手写但稳定性和可维护性好得多也不依赖Eclipse版本。再就是很多团队会直接用外部工具把工程导出去生成这个就看团队习惯了。顺带说一下JNA。你在Eclipse插件列表里偶尔会看到跟JNA相关的条目它是Java Native Access让Java代码能调用本地动态库。Eclipse的一些底层功能会依赖它一般不用手动管安装插件时会自动带上。如果看到JNA相关的报错通常是本地库文件加载失败检查一下操作系统架构和JDK架构是否一致32位和64位混用是最常见的原因。7. 装完之后我每次都会顺手做的几件事环境装完不代表就能安心干活了后面还有几个动作我现在每次配新机器都会顺手做掉能省下未来无数次的重复劳动。这些事不写进任何教程但都是被坑出来的。第一件是确认工作空间的编码。前面提过一次这里再强调因为它的影响是延迟的。你一个人写代码时用GBK可能一直没事等到把代码提交上去、同事拉下来打开满屏乱码那时候再改就麻烦了。所以装完第一件事就是Window Preferences General Workspace里把编码设成UTF-8然后确认General Content Types里Text类的默认编码也是UTF-8。第二件是给Eclipse做一份配置导出。File Export General Preferences可以把当前所有偏好设置导成一个epf文件。换机器、重装系统、换工作空间的时候导入一下就能恢复字体、编码、代码模板、快捷键一次到位。我现在这份epf文件已经跟了我好几年覆盖过至少五台机器。第三件是理清工作空间和项目的关系。Eclipse的工作空间是个强绑定的概念一个工作空间里的项目共享同一套设置切换工作空间会重新加载一遍。我的习惯是按项目性质分工作空间业务项目一个、学习练习一个、临时验证一个。这样做的直接好处是某个工作空间被折腾坏了直接删掉重来不会牵连到正经项目。第四件是装完JDK之后立刻把版本信息记下来。听起来很傻但真的有用。java -version的输出、JAVA_HOME的具体路径、Eclipse的版本号这三条信息记在一个文本文件里将来遇到版本相关的诡异问题时你能立刻知道自己当时的环境是什么而不用靠回忆。我吃过太多次亏后来就在每个工作空间的根目录放一个env.txt记录当时的环境配置配合git一起管理。最后说个我自己的体会。这些年装过的开发环境没有一百也有八十次真正花时间的从来不是点击下一步而是搞清楚每一步背后的机制。JDK为什么要配JAVA_HOME而不是直接配PathEclipse为什么要单独指定-vmTomcat为什么要复制一套配置到工作空间这些问题想明白了遇到任何报错你都能自己推。反过来如果只是照着教程点下次换个版本、换个系统还是得从头再来一遍。插件这东西也一样装之前先问自己一句这个功能我一个月会用几次。很多插件装的时候图个新鲜装完之后再也没打开过反而拖慢启动速度、增加冲突概率。Eclipse本身就够重了能少装一个是一个。真正高频用的那几个比如Git集成、Maven、终端视图装好就够了。