[JAVA] N things to keep in mind when reading "Introduction to Spring" and "Introduction to Spring" in the Reiwa era
About this article
As I write and say every time, even now, as we approach 2020, there are only two reliable Spring-related books:
-Introduction to Spring -Introduction to Spring Revised New Edition
Both books (hereinafter referred to as "books") are super good books, but both were released in 2016, and the supported Spring version is as old as 4.2.
The latest version as of the end of 2019 is Spring 5.2. In this article, I will introduce some points that you should pay particular attention to when reading the above books now.
Check the GitHub Wiki (https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions) for all the differences in 4.x-> 5.x. ..
JDK should use 8 or above
Starting with Spring 5.0, the JDK baseline is 8 (Spring 4 is based on JDK 6). I don't think people who want to use Spring from now on will try to use JDK 6 or 7.
Spring 5.2 supports up to JDK 14. See GitHub Wiki for details on JDK and Spring version support. ..
Constructor injection instead of field injection + @Autowired should be abbreviated
Since Spring 4.2 and earlier, there have been three DI methods.
Example of field injection
@Component
public class Hoge {
@Autowired
Fuga fuga;
}
Example of setter injection
@Component
public class Hoge {
private Fuga fuga;
@Autowired
public void setFuga(Fuga fuga) {
this.fuga = fuga;
}
}
Constructor injection example
@Component
public class Hoge {
private final Fuga fuga;
@Autowired
public Hoge(Fuga fuga) {
this.fuga = fuga;
}
}
Field injection is often used in books. Probably because the amount of description is the smallest (maybe due to space limitations).
Starting with Spring 4.3, @Autowired can be omitted if there is only one constructor in the class.
Constructor injection example (4).3 or later)
@Component
public class Hoge {
private final Fuga fuga;
//Because there is only one constructor@Autowired is optional!
public Hoge(Fuga fuga) {
this.fuga = fuga;
}
}
You can make your class immutable, so use constructor injection whenever possible.
Use something like @GetMapping instead of @RequestMapping
Use @RequestMapping to write controller class methods in Spring MVC.
4.2 or earlier
@Controller
@RequestMapping("/hoge")
public class HogeController {
@RequestMapping(value = "/index", method = RequestMethod.GET)
public String index() {
return "index";
}
}
From Spring 4.3, annotations for each HTTP request method such as @GetMapping and @PostMapping have been introduced. You can write it very short!
4.3 or later
@Controller
@RequestMapping("/hoge") //here@Request Mapping is OK
public class HogeController {
@GetMapping("/index") // @Use XxxMapping!
public String index() {
return "index";
}
}
Write in HTML format using Thymeleaf 3 (not XHTML)
The book uses Thymeleaf 2. To write a screen in Thymeleaf 2, you need to write it in XHTML format.
If you add a library, you can write even 2 in HTML format.
2 or earlier
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<meta charset="UTF-8" />
<title>screen</title>
</head>
<body>
<form action="index.html" th:action="@{findByFirstName}">
First name keyword:<input type="text" name="firstName" />
<input type="submit" value="Search" />
</form>
...
Thymeleaf 3 allows you to write in HTML format by default.
3 or later
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<meta charset="UTF-8">
<title>screen</title>
</head>
<body>
<form action="index.html" th:action="@{findByFirstName}">
First name keyword:<input type="text" name="firstName">
<input type="submit" value="Search">
</form>
...
I'm glad I forgot / and no run-time exceptions!
Use the WebMvcConfigurer interface instead of the WebMvcConfigurerAdapter class
In Spring 4.3 and earlier, when creating Spring MVC related Java Config, it often inherits the WebMvcConfigurerAdapter class.
4.3 or earlier
@Configuration
@EnableWebMvc
public class MvcConfig extends WebMvcConfigurerAdapter {
@Override
public void addViewControllers(ViewControllerRegistry registry) {
...
}
...
}
Starting with Spring 5.0, this class has been deprecated and it is recommended to use the WebMvcConfigurer interface implemented by this class.
5.After 0
@Configuration
@EnableWebMvc
public class MvcConfig implements WebMvcConfigurer {
@Override
public void addViewControllers(ViewControllerRegistry registry) {
...
}
...
}
The WebMvcConfigurerAdapter class is a class that implements the WebMvcConfigurer interface and overrides all methods with an empty implementation. Being Java 8 based, all methods of the WebMvcConfigurer interface are now default methods with an empty implementation. This is the end of the job, and the WebMvcConfigurerAdapter class has been deprecated.
[Source code of WebMvcConfigurer](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/config/annotation" /WebMvcConfigurer.java)
Use Bean Validation @NotBlank instead of Hibernate Validator @NotBlank
With Java EE 8 support from Spring 5, the Bean Validation version has been increased from 1.x to 2.0 (Hibernate Validator 6.0 or later).
It is possible to use Bean Validation 1.x with Spring 5, but basically it is better to use the latest version.
Bean Validation 2.0 adds new constraint annotations. Some of them were Hibernate Validator's own annotations and have been incorporated into the Bean Validation standard. Specifically, the annotations are as follows (all in the javax.validation.constraints package).
@NotEmpty@NotBlank@Email
As a result, Hibernate Validator's own @NotBlank, @NotEmpty, and @Email (all in the ʻorg.hibernate.validator.constraints` package) have been deprecated.
Note that Spring Data's CrudRepository is incompatible
From Spring Data 2.x, the name and return value of the method defined in CrudRepository have been changed.
The changes include java.util.Optional support and method name changes.
Crud Repository before 1
public interface CrudRepository<T, ID extends Serializable> extends Repository<T, ID> {
<S extends T> S save(S entity);
<S extends T> Iterable<S> save(Iterable<S> entities);
T findOne(ID id);
boolean exists(ID id);
Iterable<T> findAll();
Iterable<T> findAll(Iterable<ID> ids);
long count();
void delete(ID id);
void delete(T entity);
void delete(Iterable<? extends T> entities);
void deleteAll();
}
2 or later Crud Repository
public interface CrudRepository<T, ID> extends Repository<T, ID> {
<S extends T> S save(S entity);
<S extends T> Iterable<S> saveAll(Iterable<S> entities);
Optional<T> findById(ID id);
boolean existsById(ID id);
Iterable<T> findAll();
Iterable<T> findAllById(Iterable<ID> ids);
long count();
void deleteById(ID id);
void delete(T entity);
void deleteAll(Iterable<? extends T> entities);
void deleteAll();
}
Spring Security PasswordEncoder should always be set explicitly
Prior to Spring Security 4, password hashing was not done unless you explicitly specified PasswordEncoder.
Starting with Spring Security 5, DelegatingPasswordEncoder is used if you do not explicitly specify PasswordEncoder. This reads the password prefix stored in the DB etc. and delegates the process to the appropriate PasswordEncoder.
I don't think anyone has specified PasswordEncoder in production (I want to believe that). However, in the study code, I think that it was not specified for the sake of simplicity. Be sure to specify it in Spring Security 5.x or later. It is OK if you define PasswordEncoder as a bean. Of course, the password stored in the DB etc. should be hashed with PasswordEncoder of the same algorithm.
Specify Password Encoder
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
...
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
}
Please note that the contents of Spring Boot have changed a lot.
For Spring Boot 1.x-> 2.x, there are too many changes to write w
Even if you just think of it
--Various library updates - Spring 4.x -> 5.x - Spring Data 1.x -> 2.x - Spring Security 4.x -> 5.x - Thymeleaf 2 -> 3 - Hibernate -> 5.4 - Jackson -> 2.10 - Hibernate Validator 5.x -> 6.1 - Flyway 4 -> 6 --Support for JDK 8 --thymeleaf-extras-java8time added --jackson-datatype-jdk8 etc. have been added --Simplification of security --Most security related properties have been removed --Improvement of Actuator --Drastic changes in internal architecture --Certification / authorization change --Addition of Micrometer --Change properties --Property rename --Various property names have changed significantly
···etc. There may be many others.
2020-02-12 postscript
I will add the materials presented at the JSUG study session. Both are valuable materials, so please read them!
Study session slide
-Story of raising the version of Spring Boot of payment service to 2 series (@ b1a9idps) -[Spring Boot 1.5 → 2.1 Addictive points (@kawakawaryuryu) that I learned from the version upgrade](https://speakerdeck.com/kawakawaryuryu/spring-boot-1-dot-5-nil-2-dot-1baziyonatupuwojing -yan-sitefen-katutahamaridokoro)
@ b1a9idps's blog list
-Upgraded the payment service Spring Boot version to 2 series -Flyway 3.x-> 5.x -Spring Boot 1.5.x to 2.0.x ~ Spring Web Edition ~ -Spring Boot 1.5.x to 2.0.x ~ Spring Data ~ -Spring Boot 1.5.x to 2.0.x ~ Spring Test ~
Summary
If you remember, I will add it one by one.
Recommended Posts