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的循环依赖
Spring Boot 3.0.0的第一个里程碑版本M1发布
2022年1月20日，Spring官方发布了Spring Boot 3.0.0的第一个里程碑版本M1。
下面一起来来看看Spring Boot 3.0.0 M1版本都有哪些重大变化：
这个在最早的Spring Boot 3相关预告中就已经知道了，Java 17将成为未来的主流版本。那么问题来了，大家都把Java 17的升级提上日程了吗？如果你对Java 8之后的各种版本的信息不太了解的话，这里有份 4.6 W 字的总结，或许你可以读一读。
Spring Boot 3开始，所有的Java EE Api都需要迁移到Jakarta EE上来。大部分用户需要修改import相关API的时候，要用jakarta替换javax。比如：原来引入 javax.servlet.Filter 的地方，需要替换为 jakarta.servlet.Filter 。但还有一些依赖Java EE API的第三方库，目前还没有得到很好的支持，所以在Spring Boot 3中暂时会先移除这类组件的支持（比如： EhCache 3 、 Infinispan 、 Jolokia 、 Pooled JMS 等）。所以，目前的M1版本相较2.x版本来说，会有一些特性的缺失。当然大多数应该还只是暂时的，Spring Boot官方会等这些第三方库发布Jakarta兼容库之后再重新引入。
下面这些功能的支持被移除了，相较上一个SNAPSHOT版本增加了 Hazelcast 3
相关Spring项目的依赖版本：
第三方库的依赖版本：
后续Spring Boot团队将每两个月发布一个新的里程碑版本，所以M2版本预计将在3月24日发布，而GA版本将在11月下旬与大家见面。
springboot升级为2.6.14后无法使用spring
springboot升级为2.6.14后无法使用spring的原因如下：
1、环境基本配置有问题，检查下环境配置。
2、前端写后台代码，大部分是根据之前项目配置，版本过低，而需要升级。
springboot2.3.4用的是几版本的spring
您好，Spring Boot 2.3.4使用的是Spring 5.2.8.RELEASE版本，它是Spring Framework 5.2.x系列的最新版本，支持Java 8和Java 11，并且支持Spring Boot 2.3.x系列的最新特性。Spring 5.2.x系列提供了新的WebFlux框架，支持Reactive编程，并且支持Spring Boot 2.3.x系列的新特性，包括增强的安全性，更好的性能，更多的可扩展性，更多的新功能和更多的新特性。
springboot是什么框架
springboot是什么框架
1. Spring Boot是什么，解决哪些问题 1) Spring Boot使编码变简单 2) Spring Boot使配置变简单 3) Spring Boot使部署变简单 4) Spring Boot使监控变简单 5) Spring Boot的不足 2. Spring Boot在平台中的定位，相关技术如何融合 1) SpringBoot与S...
springboot框架
你说的应该是web容器吧 springboot有自带的tomcat 和ty
springboot框架怎么搭建
目前java方面，我了解到 用jersey框架来搭建restful服务，据说jersey框架对restful服务来说是比较原汁原味的，你可以去了解一下。 用springMVC这个也是restful的风格 目前springMVC比较流行，看你想用哪个了
如何搭建一个springboot +mybatis+gradle框架
parameter'articleName'notfound.这个引数没有找到，你看是否传进来了，或者是否在配置档案中注入了。
jsp 框架是什么
WebWork是由OpenSymphony组织开发的，致力于元件化和程式码重用的拉出式MVC模式J2EE
Web框架。WebWork目前最新版本是2.1，现在的WebWork2.x前身是Rickard
Oberg开发的WebWork，但现在WebWork已经被拆分成了Xwork1和WebWork2两个专案。
Xwork简洁、灵活功能强大，它是一个标准的Command模式实现，并且完全从web层脱离出来。
Xwork提供了很多核心功能：前端拦截机（interceptor），执行时表单属性验证，型别转换，强大的表示式语言（OGNL – the Object
Graph Notation Language），IoC（Inversion of Control倒置控制）容器等。
WebWork2建立在Xwork之上，处理HTTP的响应和请求。WebWork2使用ServletDispatcher将HTTP请求的变成Action(业务层Action类),
session（会话）application（应用程式）范围的对映，request请求引数对映。WebWork2支援多视图表示，检视部分可以使用JSP,
Velocity, FreeMarker,
JasperReports，XML等。在WebWork2.2中添加了对AJAX的支援，这支援是构建在DWR与Dojo这两个框架的基础之上。
2.Struts是一个基于Sun
J2EE平台的MVC框架，主要是采用Servlet和JSP技术来实现的。由于Struts能充分满足应用开发的需求，简单易用，敏捷迅速，在过去的一年中颇受关注。Struts把Servlet、JSP、自定义标签和资讯资源(message
resources)整合到一个统一的框架中，开发人员利用其进行开发时不用再自己编码实现全套MVC模式，极大的节省了时间，所以说Struts是一个非常不错的应用框架。
3.EasyJWeb是基于java技术，应用于WEB应用程式快速开发的MVC框架，框架设计构思来源于国内众多专案实践，框架充分借签了当前主要流行的开源Web框架（Struts、JSF、Tapestry
、Webwork），吸取了其优点及精华，利用Velocity作为模板页面引擎，是一个实现了页面及程式码完全分离的MVC开发框架。是一个能实现中小型Web应用系统快速开发的简易Web框架。
通过EasyJWeb
Tools提供的配套开发工具，可以实现基于EasyJWeb框架的Web应用快速开发，包括常用应用软体的程式码自生成、资料库添删改查（CRUD）程式码生成、自动页面模版生成、配置档案管理等。
框架特点：
1、零配档案置支援。接触一个开发框架，开始总都要被它的配置档案折腾一番。EasyJWeb实现零配置支援，可以不写一句配置档案就在框架基础上构建运用。（适合小型网站系统）。
2、简易的模板页面设计支援：放弃使用jsp，使用简单Velocity指令码语言作为页面模板。
3、页面程式完全分离：实现显示页面与程式逻辑的完全分离，克服了传统jsp页面难于维护的问题。
4、基于页面元件的框架。灵活的页面元件配置，可以直接通过配置档案设定栏位级的事件元件。
5、快速开发支援：通过EasyJWeb
Tools，可以自动生成应用软体模板程式码，定制并管理自己的J2EE程式码模板，程式码生成模板支援最流行的实用Java开发框架(如hibernate、Spring等)实现快速开发
Extjs框架是什么
ExtJS是一个Ajax框架，是一个用javascript写的，用于在客户端建立丰富多彩的web应用程式介面。ExtJS可以用来开发RIA也即富客户端的AJAX应用。因此，可以把ExtJS用在.Net、Java、Php等各种开发语言开发的应用中。
ExtJs最开始基于YUI技术，由开发人员JackSlocum开发，通过参考JavaSwing等机制来组织视觉化元件，无论从UI介面上CSS样式的应用，到资料解析上的异常处理，都可算是一款不可多得的JavaScript客户端技术的精品。
Ext的UI元件模型和开发理念脱胎、成型于Yahoo元件库YUI和Java平台上Swing两者，并为开发者遮蔽了大量跨浏览器方面的处理。相对来说，EXT要比开发者直接针对DOM、W3C物件模型开发UI元件轻松。
title框架是什么
Tiles框架为建立Web页面提供了一种模板机制，它能将网页的布局和内容分离。它允许先建立模板，然后在执行时动态地将内容插入到模板中。Tiles 框架建立在JSP的include指令的基础上，但它提供了比JSP的 include指令更强大的功能。Tiles框架具有如下特性：
??建立可重用的模板
??动态构建和装载页面
??定义可重用的Tiles元件
??支援国际化
Tiles框架包含以下内容：
??Tiles标签库
??Tiles元件的配置档案
??TilesPlugIn外挂
在开发Web站点时，常常要求同一站点的所有Web页面保持一致的外观，比如有相同的布局、页头、页尾和选单。
采用基本的JSP语句建立复合式网页
建立动态Web页面的最基本的办法是为每个页面建立独立的JSP档案。如果网页的相同部分发生需求变更，必须手工修改所有的JSP档案。可见，采用基本的JSP语句来编写上述网页，会导致JSP程式码的大量冗余，增加开发与维护成本。
采用JSP的include指令建立复合式网页
为了减少程式码的冗余，可以把index.jsp和product.jsp中相同部分放在单独的JSP档案中，然后在index.jsp和 product.jsp档案中通过JSP include指令把其他JSP档案包含进来。这样提高了程式码的可重用性。但是JSP include指令不能完全避免程式码冗余，尽管这种方案减少了重复程式码，但JSP档案的数量增加了，由原来的2个档案增加到7个档案，所以软体的复杂度也增加了。
采用Tiles:Insert标签建立复合式网页
Tiles标签库的tiles:insert标签和JSP include指令具有相同的功能，也能把其他的JSP页面插入到当前页面中。用tiles:insert标签取代JSP include指令来建立复合式页面，程式码仅有稍微的差别，两者的利弊也很相似。单纯使用tiles:insert标签来建立复合式页面，还没有充分发挥 Tiles框架的优势。
以下两条语句的作用是相同的：
jsp:include page="indexContent.jsp"/
tiles:insert page="indexContent.jsp"/
采用Tiles模板建立复合式网页
尽管使用了tiles:insert标签，index.jsp和product.jsp档案还是存在很多的重复程式码。为了提高Web页面的可重用性和可维护性，可以引入Tiles的模板机制。通俗的讲，Tiles模板是一种描述页面布局的JSP页面。Tiles模板仅仅定义Web页面的样式，而不指定内容。在Web应用执行时，才把特定内容插入到模板页面中。同一模板可以被多个Web页面共用。使用模板，可以轻松的实现Web应用的所有页面保持相同的外观和布局，无需为每个页面硬编码。在一个应用中，大多数页面使用同一模板，某些页面可能需要不同的外观，使用其他的模板，因此一个应用可能有一个以上模板。
%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles"%
tiles:insert attribute="sidebar"/
tiles:insert attribute="header"/
tiles:insert attribute="content"/
tiles:insert attribute="footer"/
%@ page contentType="text/; charset=UTF-8" %
%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %
tiles:insert page="layout.jsp" flush="true"
tiles:put name=sidebar value="sidebar.jsp"/
tiles:put name=header value="header.jsp"/
tiles:put name=content value="indexContent.jsp"/
tiles:put name=footer value="footer.jsp"/
/tiles:insert
python框架是什么
你说的是，网路框架吧？
简单说：
Django
Grok
Pylons
TurboGears
web2py
Zope2
复杂说：
自己去看：
【整理】Python中常见的Web框架
（此处不给帖地址，请自己用google搜标题，就可以找到帖子地址了）
Junit框架是什么
JUnit是一个开放原始码的Java测试框架，用于编写和执行可重复的测试。他是用于单元测试框架体系xUnit的一个例项（用于java语言）。它包括以下特性：
1、用于测试期望结果的断言（Assertion）
2、用于共享共同测试资料的测试工具
3、用于方便的组织和执行测试的测试套件
4、图形和文字的测试执行器
（来自百度百科）
dorado是什么框架？
dorado 是上海锐道公司开发的展现层中介软体,能与目前的Spring ,hibernate等开源框架结合,使开发的速度能大大提高,它可以java web开发，前端应用，很容易上手
升级 SpringBoot 2.6.x 版本后，Swagger 没法用了
首先我们来聊聊SpringBoot的版本，目前最新版本是 2.6.4 版本， 2.7.x 即将发布， 2.4.x 及以下版本已经停止维护了，目前的主流版本应该是 2.5.x 和 2.6.x 。具体可以看下下面这张表。
首先在 pom.xml 中修改SpringBoot的版本号，注意从 2.4.x 版本开始，SpringBoot就不再使用 .RELEASE 后缀了。
提到Swagger，我们一般在SpringBoot中集成的都是springfox给我们提供的工具库，看了下官网，该项目已经快两年没有发布新版本了。
再看下Maven仓库中的版本，依旧停留在之前的 3.0.0 版本。如果springfox再不出新版本的话，估计随着SpringBoot版本的更新，兼容性会越来越差的！
今天带大家体验了一把SpringBoot升级 2.6.x 版本的过程，主要解决了循环依赖和Swagger无法使用的问题，希望对大家有所帮助！
官网地址：