你好，我是YourBatman：一個俗人，貪財好色。

前言

在云原生發(fā)展勢頭下，Spring被冠以太重的標簽，被新興框架Quarkus、Micronaut等嘲笑“廉頗老矣”。可親是否可知，最初Spring就是以輕量級出圈（interface 21就是佐證），橫掃Java EE。

筆者在年初的文章早有“預告”，Spring團隊2022年會有大動作。從年初到年底，可謂千呼萬喚始出來：Sprng Framework 6終于GA（同時期的還有Spring Boot和Spring Cloud在前后腳都會發(fā)布RELEASE版本）。

Sprng Framework 5于2017年9月份發(fā)布，距今已有5年多了。作為Spring技術棧的底座：本次Spring Framework大版本號升級是阻斷式的，不向下兼容。

值得注意的是，本文并不嘗試解釋Spring Framework為何一躍將JDK的baseline從JDK 8提到JDK 17，以及廢棄javax啟用全新的jakarta命名空間，那是另一個系列的話題了。本文僅嘗試介紹新特性。

what’s new（新特性）

老規(guī)矩，將我們關心的功能爽一遍。

最低要求JDK 17

Spring Framework 6基于JDK 17構建。換句話講，若想使用Spring Framework 6那么你的JDK環(huán)境最低要求JDK 17。市占率方面目前JDK 8其實已跌落至第二，曾經的“你發(fā)任你發(fā)，我用Java 8”終將成為歷史，這不Spring這次就來引領潮流。

問：同為LTS版本的JDK，Spring團隊為何沒選擇受眾更多的JDK 11而一躍選擇了更高版本的JDK 17呢？不怕栽跟頭嗎？

現(xiàn)在我創(chuàng)建一個Spring Framework 6的項目（基于maven構建）：

點確定后，加入依賴：

啟動Spring容器的代碼：

/**
 * 在此處添加備注信息
 *
 * @author YourBatman
 * @since 0.0.1
 */
@ComponentScan
public class Application {

    public static void main(String[] args){
        ApplicationContext context = new AnnotationConfigApplicationContext(Application.class);
        System.out.println(context.getBean(DemoConfiguration.class));
    }

}

成功運行程序！

當然若你不信邪，執(zhí)意用JDK 8運行這段程序，那么你得到的將是這個：

從Java EE邁向Jakarta EE

javax命名空間其實早已成為過去式，畢竟現(xiàn)在已快2023年了。這次Spring團隊也是跟著JDK一起，順勢的完全摒棄掉了javax命名空間，擁抱Jakarta EE。

Jakarta EE估摸不少讀者可能沒聽過，沒關系！關于Java EE和Jakarta EE的“恩怨情仇（歷史淵源）”，感興趣的一定要看看筆者的這個系列：[YourBatman]-Java EE，給你說得門清。

從Jakarta EE 9開始，便使用了全新的jakarta.*命名空間。本次建議使用從Jakarta EE 10起步。對應的技術主要有：

• Jakarta Servlet 6.0
• Jakarta Servlet JSP JSTL 3.0
• Jakarta Validation 3.0
• Jakarta WebSocket 2.1
• Jakarta Persistence 3.1
• Jakarta JMS 3.1
• Jakarta JSON 2.1
• Jakarta JSON Bind 3.0
• Jakarta Activation 2.1
• Jakarta Mail 2.1
• Jakarta Transaction 2.0
• Jakarta WS RS 3.1
• Jakarta XML SOAP 3.0
• Jakarta XML WS 4.0

另外，之前有些內置進JDK里面的Java EE注解，現(xiàn)在也換“包名”啦，如具有代表性的：JSR-330的@Inject、JSR 250的@PostConstruct、@Predestroy以及及其常用的@Resource注解。

LocalVariableTableParameterNameDiscoverer標記為過時

LocalVariableTableParameterNameDiscoverer是ParameterNameDiscoverer的一個實現(xiàn)類，用于找出參數(shù)名。它是Spring的一個經典實現(xiàn)，早在Spring Framework 2.0就已出現(xiàn)。我們知道java代碼編譯后，默認情況下參數(shù)名是不會保留的，而它利用了LocalVariableTable + ASM字節(jié)碼技術實現(xiàn)了參數(shù)名的查找。

直到Spring Framework 4.0（此版本開始支持JDK 8），才出現(xiàn)了它的替代者：StandardReflectionParameterNameDiscoverer，基于JDK 8標準的參數(shù)化實現(xiàn)的。

JDK支持編譯時加上"-parameters參數(shù)，便可保留方法參數(shù)的名字

一直以來，Spring Framework為了考慮兼容性只能降低LocalVariableTableParameterNameDiscoverer的優(yōu)先級但并“不敢”打干掉它的注意。這次顯然不一樣勒，已經標記為過時了：

按照Spring OSS標準，標記為過時的類，在下個中型版本將會被移除。為此，Spring為了防止“亂用”，如若在運行過程中發(fā)現(xiàn)你使用到了此類，會收到如下warn警告：

Using deprecated '-debug' fallback for parameter name resolution. Compile the 
affected code with '-parameters' instead or avoid its introspection:

這是一個優(yōu)秀框架該有的樣子：完成了太多的非功能性需求，可謂想犯錯都難。

ListenableFuture被標記為過時

JDK最初有Futrue，而后Spring搞了一個增強版的ListenableFuture。直到Java 8的出現(xiàn)：有了CompletableFuture再也不用使用ListenableFuture了。這不，這次順勢就把它拿下了。

除了ListenableFuture本身，與其相關的類都已被標記為過時，如：ListenableFutureCallback、SuccessCallback、FailureCallback等。

移除調CommonsMultipart等類

一直以來spring-web支持兩種上傳文件方式：

基于Apache Commons Fileuplod庫的CommonsMultipartResolver的解決方案

基于標準Servlet規(guī)范的StandardServletMultipartResolver解決方案

對應的就是MultipartResolver接口的兩個實現(xiàn)類，如下圖所示（6之前的版本有兩個實現(xiàn)）：

從本版本（Spring Framework 6）起，基于Apache Commons實現(xiàn)方案正式退出歷史舞臺，相關類也已從源代碼里刪除。自此MultipartResolver有且僅有唯一實現(xiàn)：

值得一提的是：起初Spring框架上傳文件推薦選擇的是基于Apache Commons庫的方案（也就是CommonsMultipartResolver），因為那會基于Servlet的方案性能有較大問題；但隨著Servlet的更新（從Servlet 3.0開始，javax.servlet.http.Part技術出現(xiàn)就不再有性能問題了），問題得到解決。

HttpMethod不再是枚舉，改為了類

HttpMethod是web開發(fā)中比較常見的一個類，本次從enum -> class類型的變更絕大部分情況下都能兼容，只在某些特殊case下注意一下即可（比如不能再使用switch而需改為if else來做分支邏輯了）。

PS：HttpMethod改為類后重寫了hashcode和equals方法，因此等值==比較也是不會有問題的，請放心食用

Spring Framework 5.x版本：

Spring Framework 6版本：

RestTemplate最低要求HttpClient 5.x

RestTemplate是spring-web對http請求的抽象，它底層的實現(xiàn)技術可以是Apache HttpClient、OkHttp、JDK實現(xiàn)等等，具體采用什么技術是由ClientHttpRequestFactory的實現(xiàn)類決定的。

本次Spring Framework 6針對Apache的實現(xiàn)，徹底摒棄Apache HttpClient 4.x，擁抱Apache HttpClient 5。

雖然底層實現(xiàn)有所變更，但若你代碼里是面向Spring的RestTemplate進行編程的，那就可做到無感知。

僅標注@RequestMapping注解不再被掃描為Controller了

喜大普奔！喜大普奔！喜大普奔！重說三，懂的都懂。

在之前的Spring Framework版本中，spring-web會將標注有@Controller注解或者標注有@RequestMapping注解的掃描為一個控制器（controller）：

這個動作看似合理方便了使用，但這在Spring Cloud場景下非常“煩人”：@FeignClient + API Jar包是現(xiàn)行微服務通信的典型使用方式。

在Spring Boot大一統(tǒng)的包掃描背景下，多數(shù)團隊@EnableFeignClients也采用大一統(tǒng)的掃描策略，然而這就是“災難”的開始：非常容易得就將一個@FeignClient接口掃描為一個controller從而對外暴露了其所有接口，除了大大拖慢啟動速度、造成URL沖突之外，進而產生了重大安全隱患。

PS：雖然一般的公司在腳手架層面會默默的解決掉這個問題，但據我了解絕大多數(shù)團隊其實并未關注過此問題，比如筆者寫過的：

這下好了，Spring Framework 6幫我們解決了這個煩惱，這是它的判斷邏輯：控制器只認@Controller注解了。

這讓我想起來有些同學使用@Bean去聲明一個控制器，現(xiàn)在是不行了（之前可以大概率是因為類上有@RequestMapping注解而誤打誤撞了），需要引起重視。

GenericApplicationContext支持AOT

支持AOT是Spring擁抱Native、擁抱云原生的基礎，當然這也是為何必須基于至少JDK 17構建的原因之一。

對GraalVM native images提供一流的支持

GraalVM嘛，等下篇文章聊Spring Boot 3.0.0時再談。

PathMatchingResourcePatternResolver使用NIO和module方式掃描加速

Spring的scan一直是導致容器啟動慢的重要愿意之一，甚至沒有之一。Spring Framework 6版本對此做了很大的優(yōu)化。

其實，早在Spring Framework 5就采用了index方式進行scan優(yōu)化，效果還是比較顯著的。但是此方式并不夠100%通用且使用起來不太方便，因此沒擊起什么浪花（默認情況下并不會啟用）。這次不一樣了：將可選項變?yōu)榱吮剡x項，更是唯一選項。

在此之前PathMatchingResourcePatternResolver只能通過掃xxx路徑下的所有文件（同步阻塞IO）來發(fā)現(xiàn)Bean。多module是JDK瘦身的一種方式，這次就利用多模塊 + GraalVM雙重優(yōu)勢，來大大加快掃描的速度，核心代碼在這里：

強依賴micrometer的可觀測性

在Spring Framework 6的幾個（不是全部）子項目中使用micrometer進行了直接的觀測性。比如：spring-web模塊現(xiàn)在就強依賴包io.micrometer:micrometer-observation來完成（編譯）工作：

micrometer之前只被用在Spring Boot中，現(xiàn)在Spring Framework部分子項目也接入了，這樣觀察將會更直接、更全面，這就是生態(tài)整合能力了吧。

總結

Spring Framework作為Java領域最為流行的框架（沒有之一），有非常龐大的用戶群體、項目歷史。這些歷史現(xiàn)在看來即是它的優(yōu)勢，有時也會成為較重的包袱。

Spring團隊自然能感知到“危機”，故有了Spring Native項目回應“尚能飯否”。這次Spring Framework 6直接以JDK 17起底，并且對GraalVM native images提供一流支持，目的非常明確：（適當?shù)模┧Φ舭ぃC明我還行。

最后分享一句話：上山的人永遠不要嘲笑下山的神。況且Spring依舊如日中天~