java17.0.3的简单介绍

admin 2023-01-22 14:18:06 373

今天给各位分享java17.0.3的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

1、jdk升级17docker如何部署
2、vosviewer中出现fileisinvalid
3、java选的jdk11为什么变成了17

jdk升级17docker如何部署

关注

在将java应用部署到docker环境的过程中，一个支持运行java程序的镜像是必不可少的。由于oracle授权方面的问题，docker hub 上一般只有基于openjdk的镜像，而且open jdk的镜像不支持字体管理，在使用一些验证码功能时会报错,比如生成验证码功能等。

而且openjdk 的镜像过于庞大，openjdk:17-slim的镜像大小就有407M。基于这些原因，我们可以选择定制一个java运行环境镜像。

jre制作

由于jdk的体积比较大，我们选择jre来作为运行环境，jdk1.8及以前的版本，都是有jre的，但是jdk9以后的版本不在提供jre需要自己制作。

jlink是通过按模块打包的，但是由于目前很多库还不是按模块打包的，所以我们无法知道项目里面都用了那些模块。只好将所有的模块进行打包。这样避免以后出现缺失模块导致应用报错的问题。

下面是windows平台的打包命令

bin\jlink.exe --module-path jmods --add-modules ALL-MODULE-PATH --compress=2 --strip-debug --output jre

linux下，需要将要打包的java配置到系统环境变量中，不然生成不了，会报jlink not find错误

bin/jlink --module-path jmods --add-modules ALL-MODULE-PATH --compress=2 --strip-debug --output jre17

–strip-debug 不打包调式信息 --compress=2 开启2级别压缩，这两项减小生成的文件体积

–add-modules ALL-MODULE-PATH表示所有模块

镜像制作

基于alpine镜像

拉取alpine镜像

docker pull alpine

alpine镜像非常小，只有5.59MB,可以通过docker run -it {iamgeId} sh 运行容器，运行一些简单的命令试试

D:\repo\docker\javadocker run -it c059bfaa849c sh

/ # ls

bin dev etc home lib media mnt opt proc root run sbin srv sys tmp usr var

编写dockerfile

FROM alpine:latest

MAINTAINER lin

#更换aline源

RUN echo "" /etc/apk/repositories

#update apk

RUN apk update apk upgrade

RUN apk --no-cache add ca-certificates

# bash vim wget curl net-tools

RUN apk add bash bash-doc bash-completion

RUN apk add vim wget curl net-tools

RUN rm -rf /var/cache/apk/*

RUN /bin/bash

#setup glibc

RUN wget

RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub

RUN apk add glibc-2.32-r0.apk

RUN apk add glibc-bin-2.32-r0.apk

RUN apk add glibc-dev-2.32-r0.apk

RUN apk add glibc-i18n-2.32-r0.apk

RUN rm -rf *.apk

#setup date

RUN apk add tzdata

cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

#setup language 解决中文乱码

RUN /usr/glibc-compat/bin/localedef -i en_US -f UTF-8 en_US.UTF-8

ENV LANG=en_US.UTF-8

#copy jdk-8u251-linux-x64.tar.gz

ADD jdk-8u251-linux-x64.tar.gz /usr/local

#setup java env

ENV JAVA_HOME=/usr/local/jdk1.8.0_251

ENV PATH=$PATH:.:$JAVA_HOME/bin

ENV CALSSPATH=$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

构建镜像

docker build -t jdk17-orcle-alpine .

总结：由于alpine缺少很多东西，比如glibc，需要安装后才能运行jvm,所以暂时放弃这条路

自己安装glibc比较麻烦，可以使用已经安装好glibc的镜像

#FROM alpine:latest

FROM frolvlad/alpine-glibc

MAINTAINER lin

COPY ./jre17 /usr/local/jre17

#setup java env

ENV JAVA_HOME=/usr/local/jre17

ENV PATH=$PATH:$JAVA_HOME/bin

ENV CALSSPATH=$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

该方法构建的镜像体积是比较小，但是启动java应用（基于spring boot)的时候jvm会崩溃，原因不明

基于ubuntu

ubuntu镜像相对来说也不是很大，才70多M

FROM ubuntu:latest

MAINTAINER lin

#更新软件源

RUN apt-get update

#安装字体支持

RUN apt-get install fontconfig -y

#清理缓存

RUN apt-get clean

#在windows环境下构建，将/usr/share/zoneinfo/Asia/Shanghai拷贝到本地目录

COPY ./Shanghai /etc/localtime

#setup language 解决中文乱码

#设置中文支持

ENV LANG C.UTF-8

#解压jdk并删除lib目录下的源码

COPY ./jre17 /usr/local/jre17

#授执行权限

RUN chmod -R 750 /usr/local/jre17/bin

#setup java env

ENV JAVA_HOME=/usr/local/jre17

ENV PATH=$PATH:$JAVA_HOME/bin

ENV CALSSPATH=$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

构建

docker build -t mydockerhub:5000/jdk17-orcle-ubuntu:jre-17 .

总结：除了需要处理语言问题外，其他都比较顺利，而且结果镜像211MB，比官方提供的小了很多，暂时就这样吧，以后有时间再折腾

打开CSDN，阅读体验更佳

最新发布 Docker部署SpringBoot项目（超详细）

Docker部署SpringBoot项目（超详细）

继续访问

JDK17抽取JRE并制作docker镜像

jre docker

继续访问

docker 搭建 Oracle JDK(版本可更换) 镜像

首先在本机创建jdk目录 mkdir -p /root/jdk 下载jdk到/root/jdk目录下 (版本随意)也可以直接使用 rpm 下载,各凭本事(!.!) 这里我下载的版本是jdk-8u211-linux-x64.tar.gz 在/root/jdk目录下创建Dockerfile文件 vim Dockerfile 内容为 # 基础镜像为 ce...

继续访问

Linux 安装 jdk8-17、运行 jar

前提是先把网络ip配置好官网下载地址： jdk各个版本下载 jdk各个版本档案A:网上随便兽兽道首；file–connect—hostName（linux的ip）—user name（系统用户）—prot（端口：默认）–authentication（选择password）—点击connect后----输入密码选中点击鼠标右键—Upload----- 删除 3.Ubuntu卸载jdk 4、在Linux解压文件三、

继续访问

免密登录容器dockerfile ,docker部署openjdk-17 免密登录容器dockerfile

免密登录容器dockerfile

继续访问

笔记：Docker创建最小JDK运行环境

JDK1.8 Docker最小镜像

继续访问

jre-7u17-windows-x64.exe

JDK是一个开发环境，用于构建应用程序，applet程序，和使用Java编程语言的组成部分。 Java Development Kit(JDK)是Sun Microsystems针对Java开发员的产品。自从Java推出以来，JDK已经成为使用最广泛的Java SDK。JDK 是整个Java的核心，包括了Java运行环境，Java工具和Java基础的类库。JDK是学好Java的第一步。而专门运行在x86平台的Jrocket在服务端运行效率也要比Sun JDK好很多。从SUN的JDK5.0开始,提供了泛型等非常实用的功能，其版本也不断更新，运行效率得到了非常大的提高。定于2月19日发布的Java SE原来的重要补丁更新 - 2013年2月，但甲骨文决定加快释放该重要补丁更新，因为积极开发“野生”的Java漏洞影响在桌面浏览器，运行时环境（JRE）与该重要补丁更新解决。更新日志：JDK 7u17 发布，该版本修复了浏览器插件的严重的安全漏洞：CVE-2013-1493，Oracle 强烈建议使用 Java 浏览器插件用户升级。重要补丁更新是针对多个安全漏洞的补丁集合。为Java SE重要补丁更新还包括非安全修复程序。重要补丁更新是累积性的，每个公告只描述自上一个重要补丁更新和安全警报添加的安全修复。因此，以前的重要补丁更新和安全警报建议应检讨有关以前累积的安全修复程序。请参考：重要补丁更新和安全警报的信息，有关Oracle安全性公告。由于一个成功的攻击所带来的威胁，Oracle强烈建议用户尽快应用CPU修复程序。该重要补丁更新包含50个新安全修复程序的Java SE的产品。支持受影响的产品该重要补丁更新解决的安全漏洞影响以下按类别列出的产品。请点击可用补丁列或可用补丁表中的链接来访问这些补丁的文档。

Java17 安装教程与环境配置（完整版）

Java17 安装教程与环境配置（完整版）掉坑经历安装步骤环境配置掉坑经历今天做项目的时候，发现新项目用的的spring-boot-starter-parent是最新的，一开始我使用2.5.7一直爆红，当时想着降低版本就能使用了，然后被告知，jdk需要最新版本的，才能运行项目。于是乎，开始找教程，但是我看了好几篇教程，都没正确找到最新jdk下载，这里拿个别人博文给的链接，结果你发现，你打开

继续访问

jre17 面向对象+集合的练习

简单的初学者综合练习

继续访问

使用docker容器运行java程序

使用docker容器运行java程序 java 18 一、文件准备 mkdir 11 cd 11 创建并进入目录 docker pull ubuntu:22.04 wget #sudo vim dockerfile内容如下 From ubuntu:22.04 Maintainer webrx "webrx@126.com" #把java添加到容器中 Add jdk-1

继续访问

docker安装JDK

docker安装jdk有很多种方式，这里使用自己构建镜像的方式。 1.下载jdk安装包安装包下载可以自己去官网下载，如果闲速度慢可以找一些网络资源；安装包下载好后，上传到/usr/local/docker/jdk下，这个文件目录需要自己创建 2.创建Dockerfile 在/usr/local/docker/jdk文件夹下创建Dockerfile，Dockerfile内容如下： FROM centos:centos7 MAINTAINER tao # 新建目录 RUN mkdir /usr

继续访问

jre.17_32位

jre.17_32位，适用于JAVA空间，安装在windows操作系统中！

jdk8、jdk11、jdk17版本下载

jdk8、jdk11、jdk17版本是长时间支持的版本

Java17(291)之后 , 禁用了TLS1.1 , 使JDBC无法用SSL连接SqlServer怎么办,以下是解决办法

修改java.security文件 1.找到jre的java.security文件 2.打开java.security并搜索 “jdk.tls.disabledAlgorithms=” 3.删掉TLSv1, TLSv1.1, 4.保存,可以了修改后的样例,jre17可直接复制修改java.security文件 1.找到jre的java.security文件如果是jre , 在 {JAVA_HOME} / jre / lib / security中, 比如👇 C:\Java\jdk-17.0.3.1\c

继续访问

docker构建jdk基础镜像，部署程序

docker构建jdk基础镜像

继续访问

Docker工具的使用

初识 Docker jdk的版本问题，环境造成的问题很常见，称为代码的水土不服把环境和代码一起传过去软件跨环境迁移的问题就解决了 Docker 是一个开源的应用容器引擎诞生于 2013 年初，基于 Go 语言实现， dotCloud 公司出品（后改名为Docker Inc） Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上。容器是完全使用沙箱机制，相互隔离容器性能开销极低。 Docker 从 1.

继续访问

vosviewer中出现fileisinvalid

这算是macOS的一个历史遗留问题

安装最新版的JDK后有一些软件仍然提示需要JRE，是由于Java 6以后的更新有些配置的修改导致macOS无法自动识别。

对于VOSviewer这个问题，有三个解决方案。

方案一，治标不治本，暂时让软件能用。

右键VOSviewer的app包，显示包内容

进入Contents/Java，这时你就会看见一个jar包：

不出意外的话，双击它就可以打开VOSviewer了。

方案二，简单，根治，安装一个独立的JRE 8就可以了。

下载地址：

Download Java for Mac OS X

安装好之后，直接在启动台点击VOSviewer的图标就可以

方案三，折腾，折腾，还是特喵的折腾...

参考资料：

Java SE 8 on Mac OS X – Oliver Dowling

首先打开终端，运行

java -version

会显示你的java版本信息：

java version "17.0.2" 2022-01-18 LTS Java(TM) SE Runtime Environment (build 17.0.2+8-LTS-86) Java HotSpot(TM) 64-Bit Server VM (build 17.0.2+8-LTS-86, mixed mode, sharing)

打开访达，Command+Shift+G，在输入框中粘贴路径

/Library/Java/JavaVirtualMachines/

回车，就进入了这个目录，定位到这个文件

在下方的路径栏中右键复制它的路径（如果访达界面没有路径栏，可以在标题栏右键，选择“自定工具栏”，把“路径”拖进去）。

/Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Info.plist

下面就要选一个你喜欢的文本编辑器，用超级用户权限打开它。这里我直接用vi

sudo vi /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Info.plist

按i进入插入模式，光标定位到这个位置，将这一段

keyJVMCapabilities/key array stringCommandLine/string /array

改为：

keyJVMCapabilities/key array stringCommandLine/string stringJNI/string stringBundledApp/string /array

按ESC，退出插入模式，输入

:wq

回车，然后运行下面两行命令（把jdk-17.0.2.jdk改成你对应的版本）：

sudo mkdir -p /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home/bundle/Libraries sudo ln -s /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home/jre/lib/server/libjvm.dylib /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home/bundle/Libraries/libserver.dylib

重启电脑，收工。

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，打开并在其中添加:

profiles ... profile idopenJDK17/id activation jdk17/jdk /activation properties JAVA_HOME/usr/java/jdk-17.0.3+7//JAVA_HOME JAVA_VERSION17/JAVA_VERSION maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target maven.compiler.compilerVersion17/maven.compiler.compilerVersion /properties repositories repository idXXX-Repository/id nameXXX Maven Repository/name url;/url snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idXXX-Repository/id nameXXX Maven Repository/name url;/url snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories /profile /profiles

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工程才会升级相关版本。

artifactIdparent-xxx/artifactId version2.0.0/version

这里假定老版本是1.x.x，新版本是2.0.0。

实际上父工程的pom是在升级过程中不断修改的，为了不影响使用该父工程的项目开发，你需要与相关开发人员约定好在升级完成后再尝试使用新版本的父工程。

然后修改基本属性与spring相关依赖包的版本，篇幅原因这里只给出版本发生变化的依赖包的修改后版本号，dependency配置略过:

properties !-- 基本属性 -- project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding java.version17/java.version !-- spring相关版本 -- spring-boot.version2.7.4/spring-boot.version spring-boot-admin.version2.7.4/spring-boot-admin.version spring-cloud.version2021.0.4/spring-cloud.version spring-cloud-alibaba.version2021.0.1.0/spring-cloud-alibaba.version mybatis-spring-boot-starter.version2.2.2/mybatis-spring-boot-starter.version pagehelper-spring-boot-starter.version1.4.5/pagehelper-spring-boot-starter.version !-- 插件版本 -- spring-boot-maven-plugin.version2.7.4/spring-boot-maven-plugin.version mybatis-generator-maven-plugin.version1.4.1/mybatis-generator-maven-plugin.version !-- 其他依赖包版本 -- lombok.version1.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 groupIdxxx/groupId artifactIdparent-xxx/artifactId version2.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以后将不再能调用它们，所以会有不兼容的问题。

这种问题的典型错误信息:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project api-brood-base: Fatal error compiling: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0x5740ff5e) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @0x5740ff5e - [Help 1]

这里的关键信息就是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 groupIdorg.apache.hive/groupId artifactIdhive-jdbc/artifactId version${hive.version}-${cdh.version}/version exclusions exclusion artifactIdjetty-all/artifactId groupIdorg.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的循环依赖

关于java17.0.3和的介绍到此就结束了，不知道你从中找到你需要的信息了吗？如果你还想了解更多这方面的信息，记得收藏关注本站。

标签：java17.0.3