spring5.0 released its GA (General Purpose) version in September 2017. This version is written based on jdk8, so versions below jdk8 will not be available. At the same time, it can be compatible with the jdk9 version.
The tomcat version requires 8.5 and above.
Note:
We use jdk8 to build the project, which can be downgraded and compiled. But you cannot use jdk8 or lower version to build the project.
Due to the update of jdk and tomcat versions, our IDE also needs to be updated at the same time. (Currently using eclipse 4.7.2)
36.7.2 Update to the core container
Spring Framework 5.0 now supports candidate component indexing as an alternative to classpath scanning. This feature has been added to the classpath scanner to simplify the steps of adding candidate component identification.
The application building task can define the current project's own META-INF/spring.components file. At compile time, the source model is self-contained, and JPA entities and Spring components are marked.
Reading entities from the index instead of scanning the classpath makes no significant difference for small projects with less than 200 classes. But it has a greater impact on large-scale projects. The cost of loading the component index is lower. Therefore, as the number of classes increases, the start time of index reading will remain unchanged.
The cost of loading the component index is cheap. Therefore, when the number of classes continues to grow, plus the start-up time of indexing can still maintain a constant, but for component scanning, the start-up time will increase significantly.
What this means to our developers in large-scale Spring projects is that the startup time of the application will be greatly reduced. Although 20 or 30 seconds may not seem like a big deal, if you have to board this way hundreds of times a day, the sum will be enough for you. If you use the component index, it can help you live more efficiently every day.
You can learn more about component indexing on Spring's Jira.
36.7.3 JetBrains Kotlin language support
Kolin overview : is an object-oriented language that supports functional programming programming style. Kotlin runs on JVM, but the operating environment is not limited to JVM.
An exciting feature of this Spring release is the new responsive stack WEB framework. This stack is completely responsive and non-blocking, suitable for event loop style processing, and can be extended with a small number of threads.
Reactive Streams is an API specially developed by engineers from Netflix, Pivotal, Typesafe, Red Hat, Oracle, Twitter and Spray.io. It provides a public API for the realization of reactive programming to implement Hibernate's JPA. Here JPA is the API, and Hibernate is the implementation.
The Reactive Streams API is part of the official version of Java 9. In Java 8, you will need to specifically introduce dependencies to use the Reactive Streams API.
Spring Framework 5.0's support for stream processing relies on Project Reactor to build, which specifically implements the Reactive Streams API.
Spring Framework 5.0 has a new spring-webflux module that supports reactive HTTP and WebSocket clients. Spring Framework 5.0 also provides support for responsive web applications running on the server, including REST, HTML, and WebSocket style interactions.
Two independent server-side programming models are included in spring-webflux:
Based on annotations: @Controller and some other annotations of Spring MVC are used;
Functional style routing and processing using Java 8 lambda expressions.
With Spring Webflux, you can now create a WebClient, which is responsive and non-blocking, and can be used as an alternative to RestTemplate.
Here is a WebClient implementation using Spring 5.0's REST endpoint:
WebClient webClient = WebClient.create();
Mono person = webClient.get().uri("http://localhost:8080/movie/42").accept(MediaType.APPLICATION_JSON).exchange().then(response -> response.bodyToMono(Movie.class));
36.7.5 Junit5 support
JUnit 5 Jupiter is fully supported, so you can use JUnit 5 to write tests and extensions. In addition, a programming and extension model is provided. The Jupiter sub-project provides a test engine to run Jupiter-based tests on Spring.
In addition, Spring Framework 5 also provides extensions for parallel testing in Spring TestContext Framework.
For the reactive programming model, spring-test now also introduces support for integration testing of WebTestClient that supports Spring WebFlux, similar to MockMvc, and does not require a running server. Using a simulated request or response, WebTestClient can be directly bound to WebFlux server-side facilities.
You can find a complete list of enhancements brought by this exciting TestContext framework here.
Of course, Spring Framework 5.0 still supports our old friend JUnit! At the time of writing this article, JUnit 5 has only developed to the GA version. For JUnit4, Spring Framework will be supported for some time in the future.