Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Jakarta Bean Validation
This project is created as part of the process of transitioning Java EE 8 technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter. Unlike most of the Java EE specifications, Bean Validation was led by a non-Oracle organization, namely Red Hat.
The project aims to continue the standardization work of the Bean Validation specification, which is part of the Java EE platform, but which also is designed for use in Java SE environments. Previous revisions ofthat specification were created under the Java Community Process (JCP):
- Bean Validation 1.0 (JSR 303), part of Java EE 6
- Bean Validation 1.1 (JSR 349), part of Java EE 7
- Bean Validation 2.0 (JSR 380), part of Java EE 8
Quoting the Bean Validation 2.0 specification, its goals are these:
Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving to be time consuming and error-prone. To avoid duplication of these validations in each layer, developers often bundle validation logic directly into the domain model, cluttering domain classes with validation code that is, in fact, metadata about the class itself.
This JSR defines a metadata model and API for JavaBean validation. The default metadata source is annotations, with the ability to override and extend the metadata through the use of XML validation descriptors.
The validation API developed by this JSR is not intended for use in any one tier or programming model. It is specifically not tied to either the web tier or the persistence tier, and is available for both server-side application programming, as well as rich client Swing application developers. This API is seen as a general extension to the JavaBeans object model, and as such is expected to be used as a core component in other specifications. Ease of use and flexibility have influenced the design of this specification.
Project Scope: The Jakarta Bean Validation project defines and maintains the Jakarta Bean Validation specification and related artifacts.
Specification Scope: Jakarta Bean Validation describes a means for declaring constraints on Java object models, APIs to validate constraints and query for constraint meta-data.
Bean Validation is a specification which
-
lets you express constraints on object models via annotations
-
lets you write custom constraints in an extensible way
-
provides the APIs to validate objects and object graphs
-
provides the APIs to validate parameters and return values of methods and constructors
-
reports the set of violations (localized)
-
runs on Java SE but is integrated in Java EE 6 and later; Bean Validation 2.0 is part of Java EE 8
E.g. like so:
public class User {
private String email;
@NotNull @Email
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
}
public class UserService {
public void createUser(@Email String email, @NotNull String name) {
// ...
}
}
While you can run validation manually, it is more natural to let other specifications and frameworks validate data at the right time (user input in presentation frameworks, business service execution by CDI, entity insert or update by JPA).
In other words, run once, constrain anywhere.
None known.
Bean Validation 2.0 (as defined by JSR 380) is part of the Java EE 8 platform; as the latter is in the process of being migrated to the Eclipse foundation and will be continued under the Jakarta EE brand, it makes sense to host Bean Validation there too, ensuring a coherent evolution of all the Jakarta EE specifications under one umbrella.
Future work on Bean Validation will happen based on feedback and demand by the community. Explorations for future features are conducted by the community in the Bean Validation reference implementation Hibernate Validator. Examples for potential future evolution in the specification include the following:
- Define a Java API as a source for constraints (as an alternative to the currently supported annotation and XML-based means of configuring constraints)
- Open up the specification for non POJO models (e.g. JSON strings, maps etc.)
- Integration with record types if added in a future Java version
- Closer integration with lambda expressions and method handles for specifying validation logic
As all JSR-driven specifications, Bean Validation is made up of a spec document, an API and a TCK. Their current source code (i.e. the initial contribution) can be found under the beanvalidation GitHub organization:
- beanvalidation-spec: the normative specification of Bean Validation
- beanvalidation-api: the Java API
- beanvalidation-tck: the TCK ("Technology Compatibility Kit"), a comprehensive set of tests asserting complience of Bean Validation implementations
Red Hat has the IP rights necessary for contributing these immediately. The spec text, API code and TCK code have been developed by the members of the Bean Validation expert groups.
In the actual API, there are no dependencies to third-party libraries. The TCK has the following dependencies:
- AssertJ Core 3.7.0 (Apache 2.0)
- Arquillian TestRunner TestNG Container 1.1.11.Final (Apache 2.0)
- ShrinkWrap Descriptors Generated Java EE Impl (Apache 2.0)
- TestNG 6.11 (Apache 2.0)
- JBoss Test Audit Utils API (Apache 2.0)
It also depends on the following specifications from the Jakarta EE platform:
- EE Interceptors 1.2
- CDI 1.2
- Expression Language 3.0
- EJB 3.1
- Log in to post comments
- Log in to post comments