"run time" -> runtime, "life cycle" -> lifecycle

Author: gavinking

api/src/main/java/jakarta/data/repository/By.java

@@ -58,7 +58,7 @@
  * <p>The {@code By} annotation is unnecessary when the method parameter name
  * matches the entity attribute name and the application is compiled with the
  * {@code -parameters} compiler option that makes parameter names available
- * at run time.</p>
+ * at runtime.</p>
  *
  * <p>Thus, when this compiler option is enabled, the previous example may be
  * written without the use of {@code By}:</p>

api/src/main/java/jakarta/data/repository/Param.java

@@ -43,7 +43,7 @@
  * <p>The {@code Param} annotation is unnecessary when the method parameter name
  * matches the query language named parameter name and the application is compiled with the
  * {@code -parameters} compiler option that makes parameter names available
- * at run time.</p>
+ * at runtime.</p>
  *
  * @see Query
  */

api/src/main/java/jakarta/data/repository/Query.java

@@ -42,7 +42,7 @@
  * The {@code Param} annotation is unnecessary for named parameters when the method parameter name
  * matches the query language named parameter name and the application is compiled with the
  * {@code -parameters} compiler option that makes parameter names available
- * at run time. When the {@code Param} annotation is not used, the Jakarta Data provider must
+ * at runtime. When the {@code Param} annotation is not used, the Jakarta Data provider must
  * interpret the query by scanning for the delimiter that is used for positional parameters.
  * If the delimiter appears for another purpose in a query that requires named parameters,
  * it might be necessary for the application to explicitly define the {@code Param} in order to

api/src/main/java/jakarta/data/repository/package-info.java

@@ -30,7 +30,7 @@
  *     and {@link jakarta.data.repository.CrudRepository#update(java.lang.Object)} operations.</li>
  * </ul>
  *
- * <p>Repository interfaces can also define their own life cycle methods using the
+ * <p>Repository interfaces can also define their own lifecycle methods using the
  * {@link jakarta.data.repository.Insert}, {@link jakarta.data.repository.Update}, {@link jakarta.data.repository.Save}, and {@link jakarta.data.repository.Delete} annotations,
  * as well as a variety of other methods following the Query by Method Name pattern,
  * the Parameter-based Conditions pattern, and the {@link jakarta.data.repository.Query} annotation.</p>

api/src/main/java/module-info.java

@@ -236,7 +236,7 @@
  * <p>Repository methods following the <b>Query by Method Name</b> pattern
  * must include the {@code By} keyword in the method name and must not include
  * the {@code @Find} annotation, {@code @Query} annotation, or
- * any life cycle annotations on the method or any data access related annotations
+ * any lifecycle annotations on the method or any data access related annotations
  * on the method parameters. Query conditions
  * are determined by the portion of the method name following the {@code By} keyword.</p>
  *
@@ -572,7 +572,7 @@
  * If the {@link By} annotation is missing, the method parameter name must
  * match the name of an entity attribute and the repository must be compiled
  * with the {@code -parameters} compiler option so that parameter names are
- * available at run time. The {@code _} character may be used in a method
+ * available at runtime. The {@code _} character may be used in a method
  * parameter name to reference embedded attributes. All conditions are
  * considered to be the equality condition. All conditions must match in
  * order to retrieve an entity.</p>

spec/src/main/asciidoc/repository.asciidoc

@@ -1677,5 +1677,5 @@ The following order, with the lower number having higher precedence, is used whe
 4. If the method is annotated with an <<Parameter-based automatic query methods,automatic query annotation>>, such as `@Find`, or with a <<Lifecycle methods,lifecycle annotation>> declaring the type of operation, for example, with `@Insert`, `@Update`, `@Save`, or `@Delete`, and the provider recognizes the annotation, then the annotation determines how the method is implemented, possibly with the help of other annotations present on the method parameters, for example, any `@By` annotations of the parameters.
 5. If the method is named according to the conventions of _Query by Method Name_, then the implementation follows the <<Query by Method Name,_Query by Method Name_>> pattern.
 
-A repository method that does not fit any of the above patterns and is not handled as a vendor-specific extension to the specification must either result in an error at build time or raise `UnsupportedOperationException` at run time.
+A repository method that does not fit any of the above patterns and is not handled as a vendor-specific extension to the specification must either result in an error at build time or raise `UnsupportedOperationException` at runtime.
 

tck/src/main/java/ee/jakarta/tck/data/framework/read/only/CustomRepository.java

@@ -25,7 +25,7 @@
 /**
  * Do not add methods or inheritance to this interface.
  * Its purpose is to test that without inheriting from a built-in repository,
- * the life cycle methods with the same entity class are what identifies the
+ * the lifecycle methods with the same entity class are what identifies the
  * primary entity class to use for the count and exist methods.
  */
 @Repository

tck/src/main/java/ee/jakarta/tck/data/standalone/entity/EntityTests.java

@@ -1348,7 +1348,7 @@ public void testPageOfNothing() {
         assertEquals(0L, page.totalPages());
     }
 
-    @Assertion(id = "133", strategy = "Use count and exists methods where the primary entity class is inferred from the life cycle methods.")
+    @Assertion(id = "133", strategy = "Use count and exists methods where the primary entity class is inferred from the lifecycle methods.")
     public void testPrimaryEntityClassDeterminedByLifeCycleMethods() {
         assertEquals(4, customRepo.countByIdIn(Set.of(2L, 15L, 37L, -5L, 60L)));