java 最新版本（java报错使用最新版本但是已经安装最新版本了）

本文目录

• java报错使用最新版本但是已经安装最新版本了
• java选的jdk11为什么变成了17
• JAVA怎么升级啊
• Java8的哪些特性很实用
• 挥别Java8：Devops工具Jenkins宣布本周正式向Java11迁移
• 无畏契约显示java错误怎么办
• JAVA软件编程好学吗

java报错使用最新版本但是已经安装最新版本了

java报错使用最新版本但是已经安装最新版本了卸载重新安装。根据查询相关资料显示，卸载所有的jdk和java，去把安装目录文件都删了，重新换个安装目录，然后安装即可。

java选的jdk11为什么变成了17

Java11升级Java17备忘录

下塘烧饼
白头不厌穷编码，只影孤灯两卷书。
来自专栏一只老程序猿
一、概述
Java17是目前Java最新的LTS版本，SpringBoot从2.5.5开始正式支持Java17，并且计划从3.0版本开始，Java版本要求最低是Java17。
为了顺应Java及其生态的发展，最近对一套JavaWeb开发框架做了版本升级，主要是Java版本和Springboot版本的升级，包括:
Java版本从openJDK11升级到openJDK17
springboot版本从2.1.11升级到2.7.4
本次升级相比从Java8升级到Java11要简单很多，基本没遇到什么问题。
Java8到Java11之间有Java9这个变化很大的拦路虎，包括但不限于：移除了一些以前集成在jdk的lib中的依赖包，引入模块化导致某些内部API不可用，类加载机制变化导致一些第三方依赖包版本不兼容，等等。
而从Java11到Java17，中间并没有Java9那样巨大的变化，只有Java16和Java17中有一些增强Java内部封装的新特性，可能会导致底层类库依赖包的老版本不能兼容Java17。
关于Java8升级Java11的工作，可以参考我以前的文章:
java - Java8升级Java11备忘录_个人文章 - SegmentFault 思否
另外，本篇文章主要讲如何从Java11升级到Java17，以及升级过程中遇到的一些问题。如果想看Java11到Java17有哪些新特性，可以参考我以前的另一片文章:
下塘烧饼：java17相对java11的新特性
二、升级工作内容
升级工作内容大致如下：
2.1 安装openJDK17及其对应的IDEA
这里选择的是eclipse的Adoptium社区版本:
OpenJDK17U-jdk_x64_linux_hotspot_17.0.3_7.tar.gz
下载地址:
***隐藏网址***
更多版本与下载地址请参考文章:
下塘烧饼：java17相对java11的新特性
安装很简单，解压缩到指定目录即可。
只是开发的话，JAVA_HOME与PATH等环境变量不是一定要设置的，比如我这里的环境有多个JDK版本，只要在IDE中添加新的JDK即可。
IDEA的话，使用2021.2.4以上版本即可支持Java17，在其sdk中加入刚刚安装好的JDK目录：
用IDEA任意打开一个java工程，在其Project Structrue -》 Platform settings -》 SDKs中添加JDK17目录。
2.2 配置本地Maven
在本地Maven的配置文件中添加新的JDK17的profile，比如我这里的配置文件是/opt/apache-maven-3.5.0/conf/settings.xml，打开并在其中添加:
***隐藏网址***
JAVA_HOME是本地JDK安装目录。
repository与pluginRepository用来配置maven仓库地址，之后在IDE中启用这里配置的profile。这样maven拉取jar包时，会优先从这里配置的maven仓库拉取，拉取不到时再去中央仓库拉。
配置好settings.xml后，在各个java工程中启用新的profile:
首先在File -》 Settings -》 Maven中确定maven及其配置文件目录:
然后在IDEA的maven插件中选择jdk17的profile:
2.3 修改父工程的pom版本控制
升级对象是一套JavaWeb开发框架，有自己的父工程来控制依赖包的版本，在决定升级Java版本与Springboot版本后，父工程的pom文件中的相关依赖包版本需要更新。
首先是父工程自己的版本需要升级，这样仍然依赖老版本父工程的java工程就不会升级相关版本，只有依赖了新版本父工程的java工程才会升级相关版本。
《artifactId》parent-xxx《/artifactId》 《version》2.0.0《/version》
这里假定老版本是1.x.x，新版本是2.0.0。
实际上父工程的pom是在升级过程中不断修改的，为了不影响使用该父工程的项目开发，你需要与相关开发人员约定好在升级完成后再尝试使用新版本的父工程。
然后修改基本属性与spring相关依赖包的版本，篇幅原因这里只给出版本发生变化的依赖包的修改后版本号，dependency配置略过:
《properties》 《!-- 基本属性 --》 《project.build.sourceEncoding》UTF-8《/project.build.sourceEncoding》 《project.reporting.outputEncoding》UTF-8《/project.reporting.outputEncoding》 《java.version》17《/java.version》 《!-- spring相关版本 --》 《spring-boot.version》2.7.4《/spring-boot.version》 《spring-boot-admin.version》2.7.4《/spring-boot-admin.version》 《spring-cloud.version》2021.0.4《/spring-cloud.version》 《spring-cloud-alibaba.version》2021.0.1.0《/spring-cloud-alibaba.version》 《mybatis-spring-boot-starter.version》2.2.2《/mybatis-spring-boot-starter.version》 《pagehelper-spring-boot-starter.version》1.4.5《/pagehelper-spring-boot-starter.version》 《!-- 插件版本 --》 《spring-boot-maven-plugin.version》2.7.4《/spring-boot-maven-plugin.version》 《mybatis-generator-maven-plugin.version》1.4.1《/mybatis-generator-maven-plugin.version》 《!-- 其他依赖包版本 --》 《lombok.version》1.18.24《/lombok.version》 《/properties》
升级后的测试并不充分，这里列出的发生版本变化的依赖包可能并不全面。
如果在编译或运行时发现有某个依赖包报错，说某个jdk的module因为没有导出而无法访问的错误: cannot access class xxx (in module jdk.xxx) because module jdk.xxx does not export xxx to xxx，那么就基本可以确定这个依赖包版本较老不兼容Java17。
解决方法很简单，在当前这个时间点，基本上所有的第三方依赖包都已经有兼容Java17的较新的版本，直接去maven中央仓库找一个新版本下载，就能解决问题。
比如上面的lombok版本升级到了1.18.24，就是为了解决编译时发生的上述不兼容的错误。
另外，如果父工程中还约定了很多自用的通用工程的版本，那么这里需要确保这些通用工程的版本范围在新老版本中的定义没有冲突。
例如老版本的父工程中定义了一些通用工程的版本:
《lib-xxx.version》[1.0.0-RELEASE,2.0.0-RELEASE)《/lib-xxx.version》
这里的lib-xxx是这套JavaWeb开发框架中的一个通用库，在老版本的父工程中约定它的版本范围是[1.0.0-RELEASE,2.0.0-RELEASE)，即从1.0.0-RELEASE(包含)到2.0.0-RELEASE(不包含)。那么新版本的父工程，对它的版本范围约定就是[2.0.0-RELEASE,3.0.0-RELEASE)。
这样约定的目的是，如果有一些java工程仍然要使用老版本的父工程(假定由于种种原因，只能用Java11与Springboot2.1.x 。。。)，那么它就不会依赖2.0.0-RELEASE及其以上版本的lib-xxx；而一旦依赖了新版本的父工程，就只会依赖2.0.0-RELEASE及其以上版本的lib-xxx。
最后要注意，如果在老版本(这里就是Java11和Springboot2.1.11)上还有新的应用或需求变更要开发，那么需要在代码管理库中切出一个新的分支来做升级的工作，并约定好各自的版本范围，比如采用不同的主版本号。
2.4 单个Java工程的版本升级
在前面的2.1到2.3准备工作完成之后，就可以对java应用工程做版本升级了。
首先打开一个java工程，确认maven的目录与配置文件是否正确，并将maven插件的profile选择到jdk17，这一步已在步骤2.2中示意。
然后修改工程依赖的父工程版本为2.3中修改后的父工程版本。
《parent》 《groupId》xxx《/groupId》 《artifactId》parent-xxx《/artifactId》 《version》2.0.0《/version》 《/parent》
然后先使用maven插件刷新pom依赖，顺利的话，可以在maven插件中看到新的依赖包版本：
pom依赖刷新之后，再来修改工程的idea配置中的java版本，打开Project Structrue，依次修改或确认java版本：
然后我们就可以对工程进行编译，检查有没有编译错误或警告。
考虑到devops的需要，你可能需要一个maven编译脚本，要注意java版本，如下所示:
#!/bin/bash export JAVA_HOME=/usr/java/jdk-17.0.3+7 mvn -version mvn clean install package
注意这里指定了JAVA_HOME，maven编译时会用到这个环境变量，因此指定为JDK17的安装目录。本地环境安装有多个JDK版本时要特别注意这一点。
如果是springboot工程，编译成功之后就可以启动服务:
#!/bin/bash JAVA_HOME=/usr/java/jdk-17.0.3+7 JAR_PATH=$(find target -name "*.jar") ${JAVA_HOME}/bin/java -jar "${JAR_PATH}"
2.5 编译与运行时遇到的问题
在编译工程以及启动springboot服务时，可能会遇到以下问题。
2.5.1 JDK模块内API未导出问题
前面说过，Java16和Java17中有一些增强Java内部封装的新特性，该特性加强了对一些以前暴露出来但其实很不安全的关键API的封装，即你不再能从外部访问这些内部API。而java的生态圈中有很多底层的类库比如lombok在以前的版本中会调用到这些内部API。那么在Java17以后将不再能调用它们，所以会有不兼容的问题。
这种问题的典型错误信息:
这里的关键信息就是cannot access class xxx (in module jdk.xxx) because module jdk.xxx does not export xxx to xxx，一旦看到这句错误信息，就知道这是由于JDK加强了内部API的封装所导致的不兼容问题。
解决起来很简单，找个新版本就行了。以lombok为例，升级到版本1.18.24即可。
其他类库的包也有可能出现类似的问题，解决方法一样，换用更新的兼容Java17的版本即可。
2.5.2 redisTemplate版本不兼容
如果使用了spring的redisTemplate，那么有可能出现版本不兼容，包括:
redisTemplate.delete方法编译错误，方法参数的泛型发生了变化。
// 版本升级前编译OK，升级后编译错误 redisTemplate.delete(CollectionUtils.arrayToList(key)); // 版本升级后修改如下 redisTemplate.delete(Arrays.asList(key));
GenericObjectPoolConfig的setMaxWaitMillis被废弃不再推荐使用，用setMaxWait代替:
GenericObjectPoolConfig《?》 genericObjectPoolConfig = new GenericObjectPoolConfig《》(); ... // genericObjectPoolConfig.setMaxWaitMillis(redisProps.getPool().getMaxWait()); genericObjectPoolConfig.setMaxWait(Duration.ofMillis(redisProps.getPool().getMaxWait()));
2.5.3 jackson版本不兼容
spring默认使用的json工具类库jackson，它的ObjectMapper的enableDefaultTyping被废弃不再推荐使用，使用activateDefaultTyping代替
具体代码如下所示:
ObjectMapper om = new ObjectMapper(); // om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL); om.activateDefaultTyping(om.getPolymorphicTypeValidator(), ObjectMapper.DefaultTyping.NON_FINAL);
2.5.4 循环依赖问题
springboot的新版本默认不再支持bean的循环依赖，因此项目中有循环依赖的bean的话，会报错，例如:
The dependencies of some of the beans in the application context form a cycle: xxxxxxxxx ┌─────┐ | xxxService1 (field private com.gcsoft.brood.sentry.service.XxxService2 com.gcsoft.brood.sentry.service.xxxService1.xxxService2) ↑ ↓ | xxxService2 (field private com.gcsoft.brood.sentry.service.XxxService1 com.gcsoft.brood.sentry.service.XxxService2.xxxService1) └─────┘ Action: Relying upon circular references is discouraged and they are prohibited by default. Update your application to remove the dependency cycle between beans. As a last resort, it may be possible to break the cycle automatically by setting spring.main.allow-circular-references to true.
最好的对应方式是消去bean之间的循环依赖，否则就需要显式声明允许bean的循环依赖，在application.yml中加入属性:
spring: main: allow-circular-references: true
2.5.5 缺少spring.config.import配置
如果在pom工程中依赖了springcloud的相关jar，但并没有使用springcloud相关的config配置，那么在启动springboot服务时可能会失败:
No spring.config.import property has been defined Action: Add a spring.config.import=configserver: property to your configuration. If configuration is not required add spring.config.import=optional:configserver: instead. To disable this check, set spring.cloud.config.enabled=false or spring.cloud.config.import-check.enabled=false.
按照提示，在application.yml中加入属性:
spring: cloud: config: enabled: false
2.5.6 jetty版本冲突
springboot版本升级后，内嵌的jetty版本也升级了。由于某些第三方jar使用了低版本的jetty的某些包，即使springboot没有使用jetty，也依然会在运行时发生jetty的不兼容问题:
java.lang.ClassNotFoundException: org.eclipse.jetty.server.RequestLog$Writer
这里可以选择升级第三方jar。
或者直接去除第三方jar对jetty的依赖:
《dependency》 《groupId》org.apache.hive《/groupId》 《artifactId》hive-jdbc《/artifactId》 《version》${hive.version}-${cdh.version}《/version》 《exclusions》 《exclusion》 《artifactId》jetty-all《/artifactId》 《groupId》org.eclipse.jetty.aggregate《/groupId》 《/exclusion》 《/exclusions》 《/dependency》
2.6 docker镜像
在各个工程完成升级，编译成功，并简单运行OK之后，开始做docker镜像的升级工作。
毕竟现在都在云端跑服务了。。。
这里从Docker Hub上找了与开发使用的openJDK版本一致的docker镜像，也是由eclipse的Adoptium社区提供的。
其实没有必要，其他openJDK17版本的docker镜像也是一样的，单纯的强迫症而已。。。
docker pull eclipse-temurin:17.0.3_7-jdk-alpine
对应docker hub地址:
Docker Hub
在这个openJDK17镜像的基础上，修改了时区与语言等信息，安装了bash与telnet，DockerFile如下:
# 指定基础镜像，在其上进行定制(这里是 eclipse-temurin:17.0.3_7-jdk-alpine 的镜像) FROM eclipse-temurin:17.0.3_7-jdk-alpine # 定制环境变量 ENV TIME_ZONE=Asia/Shanghai \ LANG=en_US.UTF-8 \ LANGUAGE=en_US.UTF-8 \ LC_ALL=en_US.UTF-8 # RUN在build镜像时执行，每RUN一次就会构成一层新的镜像。 # 因此有多个命令要执行时，用"&&"连接写在一起。 RUN sed -i ’s/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g’ /etc/apk/repositories \ && apk add --no-cache tzdata \ && echo "${TIME_ZONE}" 》 /etc/timezone \ && ln -sf /usr/share/zoneinfo/${TIME_ZONE} /etc/localtime \ && apk add --no-cache bash bash-doc bash-completion busybox-extras
原始的eclipse-temurin:17.0.3_7-jdk-alpine有335M，添加了tzdata，bash，busybox-extras(telnet)之后，大小是340.8M。。。完整的JDK镜像就是这么大。。。如果生产环境不需要JDK，那么可以用JRE作成的镜像，会小不少，但是缺失了很多JDK工具。
用这个DockerFile做成一个新的openJDK17镜像，命名为xxx/base-openjdk17:jdk-17.0.3_001，而各个springboot工程的DockerFile如下所示:
# 指定基础镜像 FROM xxx/base-openjdk17:jdk-17.0.3_001 # JDK11开始支持: -XX:+UseContainerSupport 使JVM能够感知容器资源， -XX:InitialRAMPercentage 初期容器内存占比， -XX:MaxRAMPercentage 最大容器内存占比 ENV JAVA_OPTS="-XX:+UseContainerSupport -XX:InitialRAMPercentage=50 -XX:MaxRAMPercentage=80" # 复制上下文目录下的target/*.jar 到容器里 ADD target/*.jar app.jar # 指定容器启动程序及参数 《ENTRYPOINT》 "《CMD》" ENTRYPOINT java ${JAVA_OPTS} -jar /app.jar
该DockerFile位于springboot工程根目录下。
打进了springboot fat jar的镜像会变得更大，一般都会有400M以上。。。
三、小结
总的来说，Java11到Java17的升级比较顺利，只有少数依赖包对应版本需要升级。另外就是springboot的升级可能导致需要添加少量配置，比如显式允许bean的循环依赖

JAVA怎么升级啊

1、浏览器要求，使用非Chrome内核浏览器。Trident(IE内核)，Google Chrome的Blink内核。

2、打开浏览器，在搜索引擎上搜索【Java】。

3、进入Java官网后单击【我有Java吗？】。

4、进入网页后点击【验证 Java 版本】。

5、然后会出现，正在验证安装。检测您计算机的Java。

6、检测完成后可以看到您的 Java 版本： Version 8 Update 65新版本Version 8 Update 66请单击下载按钮，为您的计算机获得推荐的 Java 版本。

7、下载安装Java最新版本后，验证Java版本会提示：祝贺您！您已安装了推荐的 Java 版本。 

Java8的哪些特性很实用

Java8是一个非常重要的版本，它包含了许多新特性，其中一些非常实用。以下是一些Java8的实用特性：
-Lambda表达式：Java8引入了Lambda表达式，这是一种函数式编程的特性，可以让代码更加简洁和灵活。
-函数式接口：指的是一个有且仅有一个抽象方法，但是可以有多个非抽象方法的接口，这样的接口可以隐式转换为Lambda表达式。
-方法引用：方法引用提供了非常有用的语法，可以直接引用已有Java类或对象（实例）的方法或构造器。与Lambda联合使用，方法引用可以使语言的构造更紧凑简洁，减少冗余代码。
-StreamAPI：新添加的StreamAPI（java.util.stream）把真正的函数式编程风格引入到Java中。
-Date/TimeAPI：这个API提供了一些新的日期和时间类，以及方便的日期和时间操作方法。
-Optional类：Optional类是一个容器类，它可以保存一个值，也可以表示一个值不存在。
这些特性都非常实用，可以帮助你更好地编写Java代码。

挥别Java8：Devops工具Jenkins宣布本周正式向Java11迁移

由KohsukeKawaguchi打造的Jenkins(最初被称作Hudson)Devops工具，转眼已经过去了十个年头。在Oracle/Sun收购引发的分叉之前，用Java编写的该平台在持续集成和交付领域相当受欢迎。最新消息是，Jenkins项目组刚刚表示，本周的2.357和即将于9月到来的LTS版本，都将需要在Java11的基础上运行。
虽然JenkinsLTS核心支持Java11已有一段时间，但作为一个“长期支持版本”(LTS)，Java11本身已可追溯到2018年。
此外作为向2014年发布的Java8告别的一部分(供应商将持续支持到2030年)，六月LTS也已经支持Java17(JavaSE的最新LTS)。
Jenkins团队指出，虽然项目会在可预见的一段时间内保留在Java8上，但这么做将是不够严谨的。
毕竟Jenkins使用的多个第三方库，都依赖于更高的Java版本，因而坚持使用Java8会导致上游项目的更新变得更少。
问题在于，从Java8/9向更高版本的转变，同时也会给诸多开发者带来各式各样的挑战——无论是语言/运行时等方面的技术支持、还是法律层面的许可政策问题。
痛定思痛之后，Jenkins最终还是在2018年开启了对Java11的支持工作，并随着本周的发布而正式提出了这一要求。
另外Jenkins也将带来对Java17的全新支持，只是目前尚未抵达可向社区快速推广开来的阶段。
好消息是，未来从Java11向Java17迁移的过程，肯定不会像从Java8向Java11迁移那样痛苦。

无畏契约显示java错误怎么办

更新Java版本，重新安装游戏，检查游戏设置。
1、更新Java版本：检查Java版本是否与游戏兼容，并尝试更新Java到最新版本。
2、重新安装游戏：如游戏文件损坏，重新下载并安装游戏会解决问题。
3、检查游戏设置：在游戏设置中确认是否启用了正确的Java版本或DirectX版本。
4、查看官方支持：如问题仍然存在，可以通过拳头游戏的官方网站或游戏内的帮助中心查找支持文档或联系客服寻求帮助。

JAVA软件编程好学吗

任何编程语言都不是想象中那样简单的，想要做到精通更是难上加难，而且Java的学习比其他编程语言更难，但是，有利必有弊，Java虽然难于掌握，但是在应用上确实其他语言不能比拟的，应用范围也是十分广泛。所以，想要以后更好的发展，建议还是不断的挑战自己，只要不断的坚持，肯定能够掌握的。

就拿国内从业比较广泛的Java开发工程师来讲，高中毕业生都可以做。既然高中生都能从事于Java开发，说明软件开发实际上并没有我们想的那么难，毕竟目前所学的软件技术并不是做科研。

想要让软件开发变得简单，我们需选择一门容易上手的编程语言。从国内软件行业来看，目前Java的开发者数量还是相当庞大的，而且可从事的领域也比较广。当然，我并不是在这里劝你学习java，而是让自己选择适合的编程语言，并知道自己使用的编程语言能做什么，用在哪些地方。

对于零基础想学java的人，千万不要害怕，不要觉得没基础就学得很吃力，学不会等等。

刚开始零基础入门的学习进度是很慢的，不用着急，慢工才能出细活，说白了Java入门阶段也就是个熟练的过程花费的学习时间比较长。不可否认，大家在开始接受新事物的时候都会陷入困境的。

学习是循序渐进的，零基础入门Java到底难不难，只有自己接触到课程才知道。当然，没接触之前学起来可能会觉得有点难，但是当你入门后你就会发现越来越有趣了，不光是学习java语言，其他语言也一样。

记住，软件开发需要有一定的基础，但是并没有特别高的门槛，只要具备有一定的英文和数学基础（初高中水平就好了），就可以学软件开发，尤其是编程语言的使用，因此对于软件开发而言，只要能够长期坚持下去，并且多多从事实际项目的开发，就可以积累经验，达到一个比较高的水平，所以软件开发并不难学，只要坚持，就可以有所成就。

至于零基础学java所用的时间，我以培训时间为标准，大学生一般的学习时间是5-6个月，高中生确在两年左右。