스프링 버전 변경 변천사 3.0에서 6.0까지

 

* 스프링은 경량, POJO, EJB, IOC, AOP, Transaction 관리 등으로 JavaEE 를 대체했다. 

* 스프링 컨테이너는 서블릿컨테이너와 다르게 WAS, 벤데에 종속적이지 않으면서 자유로운 확장이 가능하다

스프링 프레임워크는 간단한 컴포넌트 만으로도 Application 구성이 가능하다. xml 설정 파일 상의 선언적인 구성도 가능하다.

스프링 Integration : Container 구조 덕분에 다픈 프레임워크들과 결합이 쉽다. 특히  Hibernte 등과의 결합은 공식과도 같다.

 

스프링 3.0부터 java 5가 지원된다.

a) 전체 프레임워크를 하나의 spring.jar 파일로 제공하던 부분을 여러개의 jar 파일로 나누어 제공한다. 
b) SPEL(Spring Expression Language)가 도입되었다.
c) Rest API 에 대한 지원이 추가되었다.
d) OXM(Object Xml Mapping) 기능이 추가되어 설정을 Xml 형태로 할 수 있게 지원한다.
e) Java annotation 을 이용해서 DI 의 지원이 가능하다.

 

Spring 4.0

Spring 3.0 이 Java5+ 버전들에 대해 지원을 한다면 Spring 4.0 버전은 Java 8 의 특징들을 적용할 수 있게 지원한다. 

a) Starter Pack 이 생겨서 초보 개발자들에게 큰 진입장벽인 POM 설정을 도와준다.

b) 기존에 사용하지 않지만 호환성을 위해 남겨져있던 Deprecated Package 들이 제거되었으며 Hibernate 3.6 이상, EhCache 2.1 이상, Groovy 1.8 이상, Joda-Time 2.0 이상 등 새로운 Dependency 들에 대해 지원한다.

c) Java6, Java7, Java8 의 고유 기능들에 대해 지원한다. 람다식, Optional, Callback Interface 등의 기능을 Spring framework 레벨에서 사용할 수 있다.

d) Java EE 6, 7 에 대해 고려되어 있다. JPA 2.0 과 Servlet 3.0 에 대한 지원이 포함되어 있다는 뜻이다.

e) Groovy 를 이용한 Bean 설정이 가능하다. 자세한 사용법은 GroovyBeanDefinitionReader 문서를 참조하자.

f) Core 컨테이너들의 기능 지원이 확대되있다. 먼저 Repository 들이 좀 더 쉽게 Inject 될 수 있으며, 각종 Metadata Annotation 들을 이용한 Custom Annotation 작성이 가능하다. @Lazy 를 이용한 Lazy Injection 이나 @Order 을 통한 Ordered Interface, @Profile 을 통한 프로필 버전 관리가 쉬워졌다.

g) Web 을 개발하기 위한 도구들이 생겼다. @RestController 같은 것들이 그것이다.

• REST 클라이언트를 개발할 때 비차단 비동기 지원을 허용 하는 AsyncRestTemplate 클래스가 추가되었다
• WebSocket, SockJS 및 STOMP에 대한 지원이 추가되었다

h) Web Socket 이나 STOMP 등의 프로토콜을 같이 지원한다.

i) 테스트 환경이 개선되었다. Framework 레벨에서 Mock 을 위한 ServletContext 를 별도로 지원한다.

j) Spring의 콜백 인터페이스 로 람다 표현식과 메소드 참조를 사용할 수 있다

k) @Autowire 주석을 생성자에 적용할 수 있다

•  

 

https://docs.spring.io/spring-framework/docs/4.3.12.RELEASE/spring-framework-reference/htmlsingle/

Spring Framework Reference Documentation

Spring 5.0

Spring 5.0 은 JDK 8+, 9 등에 대해서 지원하며 Java8을 표준으로 사용한다. 

a) 코어로직에 있어서 JDK 8의 특징들이 강화되었다.
b) HTTP 메시지 코덱의 XML과 JSON 지원에 대한 구현이 Encoder 와 Decoder 의 사용을 통해 추상화 되었다.
c) 웹에 대한 지원이 향상되었다. 특히 Protobuf 3.0 지원이 적용되었다.

Protocol Buffers는 프로그래밍 언어와 플랫폼에 구애받지 않으면서 구조가 있는 데이터를 직렬화 역직렬화하는 매커니즘이다. Google이 만들어냈다. XML과 JSON과 같은 것들보다 빠르다.

binary-based 메세지 구조의 이점을 활용하여 어떻게 REST API를 만드는지 알아보자.

https://velog.io/@jakeseo_me/Protocol-Buffers-%EB%A1%9C-%ED%86%B5%EC%8B%A0%ED%95%98%EB%8A%94-Spring-REST-API-%EA%B5%AC%ED%98%84%ED%95%B4%EB%B3%B4%EA%B8%B0

Protocol Buffers 로 통신하는 Spring REST API 구현해보기

 

https://recordsoflife.tistory.com/843

프로토콜 버퍼가 있는 Spring REST API

 

d) non-blocking과 함수형 프로그래밍, reactive stream의 구현을 할 수 있는 Spring WebFlux를 지원한다 

e) 공식적으로 Kotlin을 지원과 JUnit 5를 지원한다

f) 기본적으로 Java 8 기반, Java 9와 함께 동작하도록 설계되어 있다

g) Spring Boot 2.x 라인은 Spring Framework 5를 기반으로 한다

 

Spring 6.0 => 2021.12(M1) - 2022.7.21(M4)a) 자바 17로 변경b) 일부 Java EE API 지원 종료c) xml이 점차적으로 스프링에서 사라지게 될것d) RPC지원 종료e) 새로운 AOT 엔진 도입f) @Inject 같은 JSR에서 지원하던 어노테이션들이 jakarta.annotation 패키지의 어노테이션으로 변경g) HttpMethod가 enum에서 class로 변경h) Jakarta EE 9 +로의 마이그레이션으로 인한 변경

• Hibernate ORM 5.6.x 버전부터 hibernate-core-jakarta 사용
• javax.persistence에서 jakarta.persistence로 변경
• Tomcat 10, Jetty 11, Undertow 2.2.14 (undertow-servlet-jakarta도 포함)으로 업그레이드 필요
• javax.servlet에서 jakarta.servlet으로 변경 필요 (import)

 i) Commons FileUpload, Tiles, FreeMarker JSP support 같은 서블릿 기반 기능이 지원 종료됩니다.

• multipart file 업로드 혹은 FreeMarker template view는 StandardServletMultipartResolver 사용을 권장
• 이외에는 Rest 기반 웹 아키텍처 사용

j) Spring MVC와 Spring WebFlux에서 더 이상 type 레벨에서의 @RequestMapping을 자동 탐색하지 않음

• • interface의 경우에는 @RequestMapping을 붙여도 더 이상 탐색되지 않음
  • 따라서 Class에 붙이거나 interface에도 사용하고 싶으면 @Controller도 붙여야 함
  • spring-cloud-openfeign에서도 이것 때문에 interface레벨 @RequestMapping 지원 종료(Git Issue)

k) URL에서 마지막으로 나오는 / 매칭해주는 trailing slash matching configuration 기본적으로 지원하지 않음 (옵션 추가 시 사용 가능)

 

여담으로 스프링 부트 3.0에서 어떤지 봅시다.

Spring Boot 2.x -> 3.0 달라지는 점

• 최소 요구사항 변경 (M4 기준)
  • Gradle 7.5
  • Groovy 4.0
  • Jakarta EE 9
  • Java 17
  • Kotlin 1.6
  • Hibernate 6.1
  • Spring Framework 6
• AOT maven, gradle 플러그인 제공
• native 지원 기능 확대

Spring의 AOT란? (Ahead Of Time)

Spring AOT 엔진은 빌드 시 스프링 애플리케이션을 분석하고 최적화하는 도구입니다. 또한 AOT 엔진은 GraalVM Native Configuration이 필요로 하는 reflection configuration을 생성해줍니다. 이것은 Spring native 실행 파일로 컴파일 하는데 사용되고 이후에 애플리케이션의 시작 시간과 메모리 사용량을 줄일 수 있게 됩니다.

 

위 그림은 스프링 AOT(Ahead-Of-Time) 가 스프링 부트 환경에서, Bytecode를 분석하고 최적화해서 좀 더 실행하기에 빠르고 메모리적으로 효율적인 코드를 만듭니다.

(+ spring의 native-image는 JVM에서 실행되는 파일에 비해 빌드 시간은 길고 시작시간이 짧고 메모리는 적게 사용하게 된다.)

 

AOT(Ahead-Of-Time) 적용효과 : 런타임시 Spring인프라 적게 사용, 런타임시 검증할 조건 수 감소, 리플렉션을 줄이고 프로그래밍적 Bean등록방식 사용

 

 

엄청난 변경은 자바17을 쓰고 AOT, Native부분을 어필하며, Cloud 생태계에 맞는 Spring으로 거듭나려는 모습으로 보인다고 한다. Cloud환경에서는 빌드 시간보다는 실행과정에서의 부담을 줄여주는 것이 좋기 때문이다.

 

아 자바 버전사를 보고 자바17을 써야 겠구나 했는데 스프링 6.0에서 이미 공식화했다.

자바버전을 17로 해서 공부해야겠다.

AOT로 빌드시 스프링을 최적화한다는 것을 보니 스프링6.0은 좋은 것 같다.