JSR-303 & Jakarta Bean Validation

Introduction

When developing an application, one of the most important things to consider is the validation of the data entered into the application.

Validation allows you to filter and ensure that the data received is what you expect. This way, the code does not break, and security in the application is guaranteed.

Why am I writing this article?

When using Spring Boot, the most common and useful thing is to use Hibernate Validator. Many of us do not stop to think about what Hibernate Validator is and how it works. In technical interviews, you might get questions like:

• Why do you use Hibernate in Spring Boot?
• What is JSR-303?
• What is a Java Bean?
• What is a Spring Bean?

Table of Contents

1. JSR-303
2. Differences between JavaBean and Spring Bean
3. Jakarta Bean Validation
4. Hibernate Validator

JSR-303

What does JSR-303 mean?

It all started with JSR-303. JSR stands for Java Specification Request. It is a formal specification proposal within the Java development process and is managed by the Java Community Process (JCP).

The number 303 is the unique identifier of the JSR. It is very similar to the process followed in user story management programs like Jira. For a specific functionality, a user story is created and assigned a unique number.

What does the JCP do?

The JCP is responsible for the evolution of Java technology and the creation of new specifications and standards for the Java platform. Without a mechanism or consensus to develop the technology, everyone would go their own way, making it very difficult to work with Java.

For more information, you can visit the official Java Community Process page.

What is JSR-303 for?

JSR 303 is a Java Bean Validation specification. It defines standard annotations and an API for validating Java objects. JSR 303 was the first attempt to standardize bean validation in Java EE. Its development concluded with the first official version of Bean Validation 1.0.

The most important information to understand what JSR-303 does is to read two pieces of data on its official page:

• Title: “Bean Validation”
• Description: “Defines a metadata model and API for JavaBeansTM validation based on annotations…”

You can find all the details of JSR-303 here.

The JSR-303 description

The description seems somewhat complex. Today, what you need to know is that you will use the API they envisioned back then. You will follow their specification to implement validations. You follow it as they say, and that’s it.

Annotations are the most common way to add metadata to your classes. If you have, for example, an age field, that is your data. The @NotNull annotation is the metadata you add. The @NotNull is the metadata you add to your age field.

Differences between JavaBean and Spring Bean

The first concept that can be confusing is the difference between Java Bean and Spring Bean. Someday I might look for the origin of the names, but today is not that day.

What is a JavaBean?

A JavaBean is a Java object that follows certain conventions. Here is a link for more information about Java Beans.

A JavaBean is an object that has:

• Private fields
• No-argument constructor
• Getter and setter methods to access its properties
• Implements the Serializable interface.

What is a Spring Bean?

A Spring Bean is an object that:

• Is managed by the Spring container
• Is of type BeanDefinition within the Spring container
• Has a lifecycle managed by the Spring container
• Is marked with the annotation @Component, @Service, @Repository, @Controller, @Bean…

You can find more complete information in the official Spring documentation.

Differences in a table

Jakarta Bean Validation

The Jakarta Bean Validation specification is a continuation of the JSR-303 specification, which is the most well-known and is what you will find along with JSR-349 in the official Spring Boot documentation.

As of today, the latest version of Jakarta Bean Validation is 3.0. You can find more information here.

Why was the name changed from Bean Validation to Jakarta Bean Validation?

Oracle, who was the owner of Java EE, decided to transfer the administration and development of the platform to the Eclipse Foundation. Their intention was for Java EE to be more open and community-driven.

For legal reasons and trademark restrictions, Oracle owns the name Java. The Eclipse Foundation played it safe and decided to change the name of the Java EE specifications to Jakarta.

Now, all Java EE specifications are under the name Jakarta (such as Jakarta Servlet, Jakarta Bean Validation, Jakarta Persistence, etc.).

The most notable move to avoid Oracle was the change from Jakarta Bean Validation 2.0 to Jakarta Bean Validation 3.0. The only change was moving the code from the javax.validation package to the jakarta.validation package.

The initial functionality was maintained to ensure backward compatibility with previous implementations. The evolution towards Jakarta EE has also facilitated a more open and flexible approach to the development of these specifications.

Hibernate Validator

Hibernate Validator is one of the implementations of the Bean Validation specification. It is the most well-known and used implementation in the Java world.

Usage with Spring Boot

To perform validations in Spring, a provider is needed that implements a specification for validating beans. Can you guess which specification that is?

Correct, the JSR-303 specification. Spring Boot by default uses Hibernate Validator as the provider for the JSR-303 specification.

To see a practical example of how to extend these capabilities, check out how to create custom validators with Hibernate and Spring Boot.

To date, the latest stable version of Hibernate Validator is 8.0.0, which implements Jakarta Bean Validation 3.0. Jakarta Bean Validation 3.0 is based on JSR-303 and therefore you can use all the annotations you already know.

You can find more information on the official Hibernate Validator page.