remove requirement that JD providers init user-written metamodel #567
Conversation
(at least for now) this makes JD slightly easier to implement
There was a problem hiding this comment.
I don't see why some language for volatile and initialization by Jakarta Data providers was left around. Otherwise, the approach of the user-defined classes making use of the built-in attribute classes works well. The impl classes could potentially even be collapsed with the interface into a single class for simplicity.
| * <p>Alternatively, an annotation processor might generate static metamodel classes | ||
| * for entities at compile time. The generated classes must be annotated with the | ||
| * {@link jakarta.annotation.Generated @Generated} annotation. The fields may be | ||
| * statically initialized, or they may be initialized by the provider during system | ||
| * initialization. In the first case, the fields are declared {@code final}. In the | ||
| * second case, the fields are declared non-{@code final} and {@code volatile}.</p> |
There was a problem hiding this comment.
I thought the point of this pull was to remove having providers initialize the static metamodel, but the middle of this paragraph creates the expectation that they will still do that.
| * <p>Alternatively, an annotation processor might generate static metamodel classes | |
| * for entities at compile time. The generated classes must be annotated with the | |
| * {@link jakarta.annotation.Generated @Generated} annotation. The fields may be | |
| * statically initialized, or they may be initialized by the provider during system | |
| * initialization. In the first case, the fields are declared {@code final}. In the | |
| * second case, the fields are declared non-{@code final} and {@code volatile}.</p> | |
| * <p>Alternatively, an annotation processor might generate static metamodel classes | |
| * for entities at compile time. The generated classes must be annotated with the | |
| * {@link jakarta.annotation.Generated @Generated} annotation. The fields must be | |
| * statically initialized and must be declared {@code final}.</p> |
There was a problem hiding this comment.
This paragraph is dealing with provider-generated models, not user-written models. The idea of the pull is to relax the requirement that the provider initialize user-written models.
There was a problem hiding this comment.
I didn't realize we were offering the deferred initialization pattern to provider-generated models prior to this pull. I suppose we never explicitly said they could not do it that way.
There was a problem hiding this comment.
I assumed we allowed it as an option I guess partly because that's how it works in JPA.
There was a problem hiding this comment.
(I don't see a reason to disallow it.)
| * | ||
| * <p>In cases where multiple Jakarta Data providers provide repositories for the same |
There was a problem hiding this comment.
No longer applies
| * | |
| * <p>In cases where multiple Jakarta Data providers provide repositories for the same |
| * entity type, no guarantees are made of the order in which the Jakarta Data providers | ||
| * attempt to initialize the fields of the static metamodel class for that entity.</p> | ||
| * |
There was a problem hiding this comment.
No longer applies because Jakarta Data providers don't initialize the static metamodel anymore
| * entity type, no guarantees are made of the order in which the Jakarta Data providers | |
| * attempt to initialize the fields of the static metamodel class for that entity.</p> | |
| * |
|
|
||
| For each entity class for which the application wishes to request the metamodel, | ||
| - The metamodel class must be annotated with `@StaticMetamodel`, specifying the entity class as its `value`. | ||
| - The metamodel class contains one or more `public static` fields corresponding to persistent fields of the entity class. |
There was a problem hiding this comment.
| - The metamodel class contains one or more `public static` fields corresponding to persistent fields of the entity class. | |
| - The metamodel class contains one or more `public static final` fields corresponding to persistent fields of the entity class. |
| - each field corresponding to a persistent field of an entity must have modifiers `public`, `static`, and either `final` or `volatile`, | ||
| - the name of each field, ignoring case, must match the name of an entity attribute, according to the conventions specified below in <<Conventions for Metamodel Fields>>, and with the `_` character in the field name delimiting the attribute names of hierarchical structures or relationships, such as embedded classes. |
There was a problem hiding this comment.
| - each field corresponding to a persistent field of an entity must have modifiers `public`, `static`, and either `final` or `volatile`, | |
| - the name of each field, ignoring case, must match the name of an entity attribute, according to the conventions specified below in <<Conventions for Metamodel Fields>>, and with the `_` character in the field name delimiting the attribute names of hierarchical structures or relationships, such as embedded classes. | |
| - each field corresponding to a persistent field of an entity must have modifiers `public`, `static`, and `final`, | |
| - the name of each field, ignoring case, must match the name of an entity attribute, according to the conventions specified below in <<Conventions for Metamodel Fields>>, and with the `_` character in the field name delimiting the attribute names of hierarchical structures or relationships, such as embedded classes. |
|
|
||
| The Jakarta Data provider observes classes that are annotated with the `@StaticMetamodel` annotation where the `jakarta.annotation.Generated` is not also present. If the `value` of the `@StaticMetamodel` annotation is an entity class for which the Jakarta Data provides a repository implementation, then the Jakarta Data provider must initialize the value of each uninitialized (`null` valued) field that meets the criteria that is defined in the "Application Requirements for a Metamodel Class" above. | ||
| The fields may be statically initialized, or they may be initialized by the provider during system initialization. |
There was a problem hiding this comment.
| The fields may be statically initialized, or they may be initialized by the provider during system initialization. | |
| The fields must be statically initialized. |
tck/src/main/java/ee/jakarta/tck/data/framework/read/only/_AsciiChar.java
Outdated
Show resolved
Hide resolved
I was trying to leave open the possibility that a Jakarta Data provider be permitted to initialize an annotation processor-generated model at runtime, without requiring that a provider be able to do that. It's not for user-written models. |
Co-authored-by: Nathan Rauh <[email protected]>
As you know, I am not a relational database person, but I have never seen a user doing it manually. Thus, it is fine to not allow users to write it by bare hand. BTW: Can Jakarta Persistence do it manually? |
Nor have I.
That is also perfectly fine by me, FTR, though it wasn't the goal of this PR.
Yes, JPA in principle lets the user write it. |
As discussed on today's call, in the interest of quickly delivering compatible implementations, this PR removes a requirement on providers that we don't think is really that needed.