HV-1989 Update documentation examples to use the min required Java version where applicable

README.md

@@ -5,8 +5,8 @@
 
 ## What is it?
 
-This is the reference implementation of [Jakarta Bean Validation 3.0](http://beanvalidation.org/).
-Jakarta Bean Validation defines a metadata model and API for JavaBean as well as method validation.
+This is the reference implementation of [Jakarta Validation 3.1](https://jakarta.ee/specifications/bean-validation/3.1/).
+Jakarta Validation defines a metadata model and API for JavaBean as well as method validation.
 The default metadata source are annotations, with the ability to override and extend
 the metadata through the use of XML validation descriptors.
 
@@ -20,7 +20,7 @@ The full list of changes for this release can be found in changelog.txt.
 
 ## System Requirements
 
-JDK 8 or above.
+JDK 17 or above.
 
 ## Using Hibernate Validator
 
@@ -47,7 +47,7 @@ Logging will delegate any log requests to that provider.
            <version>5.0.0</version>
         </dependency>
 
-* Jakarta Bean Validation defines integration points with [CDI](http://jcp.org/en/jsr/detail?id=346). If your application runs
+* Jakarta Validation defines integration points with [CDI](http://jcp.org/en/jsr/detail?id=346). If your application runs
 in an environment which does not provide this integration out of the box, you may use the Hibernate Validator CDI portable
 extension by adding the following dependency:
 
@@ -63,13 +63,13 @@ documentation](https://docs.jboss.org/hibernate/stable/validator/reference/en-US
 
 ## Licensing
 
-Hibernate Validator itself as well as the Jakarta Bean Validation API and TCK are all provided and distributed under
+Hibernate Validator itself as well as the Jakarta Validation API and TCK are all provided and distributed under
 the Apache Software License 2.0. Refer to license.txt for more information.
 
 ## Build from Source
 
 You can build Hibernate Validator from source by cloning the git repository `git://github.com/hibernate/hibernate-validator.git`.
-You will also need a JDK 17+ and Maven 3 (>= 3.3.1). With these prerequisites in place you can compile the source via:
+You will also need a JDK 17+ and Maven 3 (>= 3.9.6). With these prerequisites in place you can compile the source via:
 
     mvn clean install
 
@@ -84,7 +84,8 @@ We provide a `.travis.yml` file so that you can enable CI for your GitHub fork b
 ## Hibernate Validator URLs
 
 * [Home Page](http://hibernate.org/validator/)
-* [Jakarta Bean Validation Home](http://beanvalidation.org/)
+* [Jakarta Validation Home](http://beanvalidation.org/)
+* [Jakarta Validation Specs](https://jakarta.ee/specifications/bean-validation/)
 * [Downloads](http://hibernate.org/validator/downloads/)
 * [Mailing Lists](http://hibernate.org/community/)
 * [Issue Tracking](https://hibernate.atlassian.net/browse/HV)

annotation-processor/src/main/resources/org/hibernate/validator/ap/ValidationProcessorMessages.properties

@@ -48,6 +48,6 @@ INVALID_GROUP_SEQUENCE_VALUE_NOT_INTERFACES=Invalid @GroupSequence configuration
 INVALID_GROUP_SEQUENCE_VALUE_CYCLIC_DEFINITION=Invalid @GroupSequence configuration. The defined group sequence should be expandable (no cyclic definition).
 INVALID_GROUP_SEQUENCE_VALUE_MISSING_HOSTING_BEAN_DECLARATION=Invalid default group sequence redefinition. The value should contain the hosting bean class.
 INVALID_GROUP_SEQUENCE_VALUE_MULTIPLE_DECLARATIONS_OF_THE_SAME_INTERFACE=Invalid @GroupSequence configuration. {0} was already declared in this group sequence.
-INVALID_GROUP_SEQUENCE_EXTEND_INTERFACES=Having group sequences extending other interfaces is discouraged by the Jakarta Bean Validation specification.
+INVALID_GROUP_SEQUENCE_EXTEND_INTERFACES=Having group sequences extending other interfaces is discouraged by the Jakarta Validation specification.
 MIXED_LIST_AND_DIRECT_ANNOTATION_DECLARATION=Constraint @{0} is declared both directly and as a list. Which is not allowed.
 INVALID_PAYLOAD_UNWRAPPING_VALUE_ANNOTATION_PARAMETERS=Having both Unwrapping.Unwrap and Unwrapping.Skip in the payload is not allowed.

build-config/src/main/resources/setupModules.groovy

@@ -21,10 +21,10 @@ def removeDependency(File file, String dependencyToRemove) {
     file.write( file.text.replaceAll( /<module name="${dependencyToRemove}"[^\/]*\/>/, '' ) )
 }
 
-// Jakarta Bean Validation API
+// Jakarta Validation API
 bvModuleXml = new File( wildflyPatchedTargetDir, 'modules/system/layers/base/jakarta/validation/api/main/module.xml' )
 def bvArtifactName = 'jakarta.validation-api-' + project.properties['version.jakarta.validation-api'] + '.jar';
-println "[INFO] Using Jakarta Bean Validation version " + bvArtifactName;
+println "[INFO] Using Jakarta Validation version " + bvArtifactName;
 processFileInplace( bvModuleXml ) { text ->
     text.replaceAll( /<resource-root path=".*validation-api.*jar/, '<resource-root path="' + bvArtifactName )
 }

cdi/pom.xml

@@ -173,8 +173,8 @@
                             <archive>
                                 <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
                                 <manifestEntries>
-                                    <Specification-Title>Jakarta Bean Validation</Specification-Title>
-                                    <Specification-Version>2.0</Specification-Version>
+                                    <Specification-Title>Jakarta Validation</Specification-Title>
+                                    <Specification-Version>${parsed-version.jakarta.validation-api.majorVersion}.${parsed-version.jakarta.validation-api.minorVersion}</Specification-Version>
                                     <Automatic-Module-Name>${hibernate-validator-cdi.module-name}</Automatic-Module-Name>
                                 </manifestEntries>
                             </archive>

documentation/pom.xml

@@ -286,9 +286,12 @@
                         <bvVersion>${version.jakarta.validation-api}</bvVersion>
                         <jbossLoggingVersion>${version.org.jboss.logging.jboss-logging}</jbossLoggingVersion>
                         <classmateVersion>${version.com.fasterxml.classmate}</classmateVersion>
-                        <jakartaElVersion>${version.org.glassfish.jakarta.el}</jakartaElVersion>
                         <expresslyVersion>${version.org.glassfish.expressly}</expresslyVersion>
 
+                        <jdkVersion>${java-version.main.release}</jdkVersion>
+                        <compilerPluginVersion>${version.compiler.plugin}</compilerPluginVersion>
+                        <versionJakartaPersistence>${version.jakarta.persistence}</versionJakartaPersistence>
+
                         <!-- URLs -->
                         <javaApiDocsUrl>${java.api-docs.base-url}/</javaApiDocsUrl>
                         <bvApiDocsUrl>${bv.api-docs.base-url}/</bvApiDocsUrl>

documentation/src/main/asciidoc/ch01.asciidoc

@@ -1,9 +1,9 @@
 [[validator-gettingstarted]]
 == Getting started
 
-This chapter will show you how to get started with Hibernate Validator, the reference implementation (RI) of Jakarta Bean Validation. For the following quick-start you need:
+This chapter will show you how to get started with Hibernate Validator, the reference implementation (RI) of Jakarta Validation. For the following quick-start you need:
 
-* A JDK 8
+* A JDK {jdkVersion}
 * http://maven.apache.org/[Apache Maven]
 * An Internet connection (Maven has to download all required libraries)
 
@@ -26,7 +26,7 @@ your __pom.xml__:
 ----
 ====
 
-This transitively pulls in the dependency to the Jakarta Bean Validation API
+This transitively pulls in the dependency to the Jakarta Validation API
 (`jakarta.validation:jakarta.validation-api:{bvVersion}`).
 
 [[validator-gettingstarted-uel]]
@@ -57,13 +57,13 @@ implementation]:
 ====
 For environments where one cannot provide a EL implementation Hibernate Validator is offering a
 <<non-el-message-interpolator>>. However, the use of this interpolator
-is not Jakarta Bean Validation specification compliant.
+is not Jakarta Validation specification compliant.
 ====
 
 [[section-getting-started-cdi]]
 ==== CDI
 
-Jakarta Bean Validation defines integration points with CDI
+Jakarta Validation defines integration points with CDI
 (https://projects.eclipse.org/projects/ee4j.cdi[Contexts and Dependency Injection for Jakarta EE]).
 If your application runs in an
 environment which does not provide this integration out of the box, you may use the Hibernate
@@ -83,7 +83,7 @@ Validator CDI portable extension by adding the following Maven dependency to you
 ====
 
 Note that adding this dependency is usually not required for applications running on a Jakarta EE
-application server. You can learn more about the integration of Jakarta Bean Validation and CDI in
+application server. You can learn more about the integration of Jakarta Validation and CDI in
 <<section-integration-with-cdi>>.
 
 ==== Updating Hibernate Validator in WildFly
@@ -93,15 +93,15 @@ Starting with Hibernate Validator 9.0, the patch to update WildFly Jakarta Valid
 
 You can learn more about the WildFly patching infrastructure in general link:https://github.com/wildfly/wildfly-feature-pack-template[here].
 
-[[validator-gettingstarted-java9]]
-==== Running on Java 11+
+[[validator-gettingstarted-modulepath]]
+==== [[validator-gettingstarted-java9]] Running in the modulepath
 
-Support for Java 11 and the Java Platform Module System (JPMS) is present in a preliminary form.
+Support for the Java Platform Module System (JPMS) is present in a preliminary form.
 There are no JPMS module descriptors provided, but Hibernate Validator is usable as automatic modules.
 
 These are the module names as declared using the `Automatic-Module-Name` header:
 
-* Jakarta Bean Validation API: `jakarta.validation`
+* Jakarta Validation API: `jakarta.validation`
 * Hibernate Validator core: `org.hibernate.validator`
 * Hibernate Validator CDI extension: `org.hibernate.validator.cdi`
 * Hibernate Validator test utilities: `org.hibernate.validator.testutils`
@@ -174,11 +174,11 @@ code.
 [[validator-gettingstarted-whatsnext]]
 === Where to go next?
 
-That concludes the 5 minutes tour through the world of Hibernate Validator and Jakarta Bean Validation.
+That concludes the 5 minutes tour through the world of Hibernate Validator and Jakarta Validation.
 Continue exploring the code examples or look at further examples referenced in
 <<validator-further-reading>>.
 
 To learn more about the validation of beans and properties, just continue reading
-<<chapter-bean-constraints>>. If you are interested in using Jakarta Bean Validation for the validation of
+<<chapter-bean-constraints>>. If you are interested in using Jakarta Validation for the validation of
 method pre- and postcondition refer to <<chapter-method-constraints>>. In case your application has
 specific validation requirements have a look at <<validator-customconstraints>>.

documentation/src/main/asciidoc/ch02.asciidoc

@@ -12,7 +12,7 @@ If you are interested in applying constraints to method parameters and return va
 [[section-declaring-bean-constraints]]
 === Declaring bean constraints
 
-Constraints in Jakarta Bean Validation are expressed via Java annotations. In this section you will learn
+Constraints in Jakarta Validation are expressed via Java annotations. In this section you will learn
 how to enhance an object model with these annotations. There are four types of bean constraints:
 
 * field constraints
@@ -23,7 +23,7 @@ how to enhance an object model with these annotations. There are four types of b
 [NOTE]
 ====
 Not all constraints can be placed on all of these levels. In fact, none of the default constraints
-defined by Jakarta Bean Validation can be placed at class level. The `java.lang.annotation.Target` annotation
+defined by Jakarta Validation can be placed at class level. The `java.lang.annotation.Target` annotation
 in the constraint annotation itself determines on which elements a constraint can be placed. See
 <<validator-customconstraints>> for more information.
 ====
@@ -95,7 +95,7 @@ It is possible to specify constraints directly on the type argument of a
 parameterized type: these constraints are called container element constraints.
 
 This requires that `ElementType.TYPE_USE` is specified via `@Target`
-in the constraint definition. As of Jakarta Bean Validation 2.0, built-in Jakarta Bean Validation as well as
+in the constraint definition. As of Jakarta Bean Validation 2.0, built-in Jakarta Validation as well as
 Hibernate Validator specific constraints specify `ElementType.TYPE_USE` and can be used
 directly in this context.
 
@@ -332,7 +332,7 @@ evaluated in addition to the `@NotNull` constraint from the superclass.
 [[section-object-graph-validation]]
 ==== Object graphs
 
-The Jakarta Bean Validation API does not only allow to validate single class instances but also complete
+The Jakarta Validation API does not only allow to validate single class instances but also complete
 object graphs (cascaded validation). To do so, just annotate a field or property representing a
 reference to another object with `@Valid` as demonstrated in <<example-cascaded-validation>>.
 
@@ -410,7 +410,7 @@ as it is more expressive.
 [[section-validating-bean-constraints]]
 === Validating bean constraints
 
-The `Validator` interface is the most important object in Jakarta Bean Validation. The next section shows how
+The `Validator` interface is the most important object in Jakarta Validation. The next section shows how
 to obtain a `Validator` instance. Afterwards you'll learn how to use the different methods of the
 `Validator` interface.
 
@@ -496,7 +496,7 @@ include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/validation
 ====
 
 
-`Validator#validateProperty()` is for example used in the integration of Jakarta Bean Validation into JSF 2
+`Validator#validateProperty()` is for example used in the integration of Jakarta Validation into JSF 2
 (see <<section-presentation-layer>>) to perform a validation of the values entered into a form
 before they are propagated to the model.
 
@@ -539,28 +539,28 @@ The returned `Path` is composed of ``Node``s describing the path to the element.
 
 More information about the structure of the `Path` and the various types of ``Node``s can be found in
 {bvSpecUrl}#validationapi-constraintviolation[the `ConstraintViolation` section] of the
-Jakarta Bean Validation specification.
+Jakarta Validation specification.
 
 [[section-builtin-constraints]]
 === Built-in constraints
 
 Hibernate Validator comprises a basic set of commonly used constraints. These are foremost the
-constraints defined by the Jakarta Bean Validation specification (see <<validator-defineconstraints-spec>>).
+constraints defined by the Jakarta Validation specification (see <<validator-defineconstraints-spec>>).
 Additionally, Hibernate Validator provides useful custom constraints (see
 <<validator-defineconstraints-hv-constraints>>).
 
 [[validator-defineconstraints-spec]]
-==== Jakarta Bean Validation constraints
+==== Jakarta Validation constraints
 
-Below you can find a list of all constraints specified in the Jakarta Bean Validation API.
-All these constraints apply to the field/property level, there are no class-level constraints defined in the Jakarta Bean Validation specification.
+Below you can find a list of all constraints specified in the Jakarta Validation API.
+All these constraints apply to the field/property level, there are no class-level constraints defined in the Jakarta Validation specification.
 If you are using the Hibernate object-relational mapper, some of the constraints are taken into account when creating the DDL for your model (see "Hibernate metadata impact").
 
 [NOTE]
 ====
 Hibernate Validator allows some constraints to be applied to more data types than required by the
-Jakarta Bean Validation specification (e.g. `@Max` can be applied to strings). Relying on this feature can
-impact portability of your application between Jakarta Bean Validation providers.
+Jakarta Validation specification (e.g. `@Max` can be applied to strings). Relying on this feature can
+impact portability of your application between Jakarta Validation providers.
 ====
 
 `@AssertFalse`:: Checks that the annotated element is false
@@ -654,13 +654,13 @@ impact portability of your application between Jakarta Bean Validation providers
 [NOTE]
 ====
 On top of the parameters listed above each constraint has the parameters
-message, groups and payload. This is a requirement of the Jakarta Bean Validation specification.
+message, groups and payload. This is a requirement of the Jakarta Validation specification.
 ====
 
 [[validator-defineconstraints-hv-constraints]]
 ==== Additional constraints
 
-In addition to the constraints defined by the Jakarta Bean Validation API, Hibernate Validator provides several useful custom constraints which are listed below.
+In addition to the constraints defined by the Jakarta Validation API, Hibernate Validator provides several useful custom constraints which are listed below.
 With one exception also these constraints apply to the field/property level, only `@ScriptAssert` is a class-level constraint.
 
 `@CreditCardNumber(ignoreNonDigitCharacters=)`:: Checks that the annotated character sequence passes the Luhn checksum test. Note, this validation aims to check for user mistakes, not credit card validity! See also http://www.dirigodev.com/blog/ecommerce/anatomy-of-a-credit-card-number/[Anatomy of a credit card number]. `ignoreNonDigitCharacters` allows to ignore non digit characters. The default is `false`.
@@ -779,7 +779,7 @@ Hibernate Validator!
 
 [TIP]
 ====
-In some cases neither the Jakarta Bean Validation constraints nor the custom constraints provided by
+In some cases neither the Jakarta Validation constraints nor the custom constraints provided by
 Hibernate Validator will fulfill your requirements. In this case you can easily write your own
 constraint. You can find more information in <<validator-customconstraints>>.
 ====

documentation/src/main/asciidoc/ch03.asciidoc

@@ -3,7 +3,7 @@
 
 As of Bean Validation 1.1, constraints can not only be applied to JavaBeans and their properties,
 but also to the parameters and return values of the methods and constructors of any Java type. That
-way Jakarta Bean Validation constraints can be used to specify
+way Jakarta Validation constraints can be used to specify
 
 * the preconditions that must be satisfied by the caller before a method or constructor may be
 invoked (by applying constraints to the parameters of an executable)
@@ -232,7 +232,7 @@ fail to satisfy these preconditions as is not aware of them. The rules of behavi
 also known as the http://en.wikipedia.org/wiki/Liskov_substitution_principle[Liskov
 substitution principle].
 
-The Jakarta Bean Validation specification implements the first rule by disallowing parameter constraints on
+The Jakarta Validation specification implements the first rule by disallowing parameter constraints on
 methods which override or implement a method declared in a supertype (superclass or interface).
 <<example-illegal-parameter-constraints>> shows a violation of this rule.