* Split BasicType "resolution" into 2 - one used for reading (mapping model) versus one used from writing (legacy persister model)
* @SqlTypeCode, @SqlType, @SqlTypeRegistration
* @JavaType, @JavaTypeRegistration
* @Mutability
* jdbc_mappings.adoc section for DomainModel chapter
[*] At the moment, neither @SqlTypeRegistration nor @JavaTypeRegistration support has been implemented
[*] Still need to make sure @Mutability is propogated properly in all the cases
[*] jdbc_mappings.adoc still needs a lot of attention
- Fix the spelling error in the name of this hierarchy
- Use delegation to an anonymous function instead of overriding in
TemplateViolatedConstraintNameExtractor
For reference, this is the script being applied:
find . -type f -name '*\..java' -o -name '*.\.adoc' -o -name '*.\.gradle' | xargs sed -i 's/javax\.validation/jakarta\.validation/g'
We apply the update int two steps:
- some hand-rolled changes, such as switching the dependency to the new Hibernate Validator preview build
- running a replace-all scripts
This individual commit represents the first set of changes.
When porting this change to a different branch, this one should be cherry picked while the second change
is better ported by running the same script once again.
Applying the following script, and setting the current value as a
documentation parameter:
find . -type f -name '*.java' -o -name '*.adoc' -o -name '.xml' | xargs sed -i 's/https:\/\/javaee\.github\.io\/javaee-spec\/javadocs\/javax\/persistence\//\{jpaJavadocUrlPrefix\}/g'
Having the script might help re-migrating existing documentation patches,
or forward porting subsequent improvements from previous branches.
The javadocs for JPA 3.0 have not been published yet at this point;
having a parameter will make it easier to leave this single task for
a later point in time.
This test accesses a field of an entity directly and expects it to be
automatically initialized; this cannot work without extended bytecode
enhancement.
This used to work with Java 8 bytecode, but only by chance. It seems
that Java 8 bytecode relies on "synthetic", static access methods
inserted by the compiler to access the fields of entities in this test:
any access to the field is done through this access method instead of
through a direct field access. Since we apply bytecode enhancement to
all methods of entities, this means that access to fields triggers
initialization, without any bytecode enhancement in the caller class.
I believe this is specific to nested classes, but couldn't find a
source. For reference, the bytecode of access methods looks like this:
static int access$002(org.hibernate.test.bytecode.enhancement.lazy.NaturalIdInUninitializedAssociationTest$AnEntity, int);
Code:
0: aload_0
1: iload_1
2: dup_x1
3: putfield #3 // Field id:I
6: ireturn
static org.hibernate.test.bytecode.enhancement.lazy.NaturalIdInUninitializedAssociationTest$EntityImmutableNaturalId access$102(org.hibernate.test.bytecode.enhancement.lazy.NaturalIdInUninitializedAssociationTest$AnEntity, org.hibernate.test.bytecode.enhancement.lazy.NaturalIdInUninitializedAssociationTest$EntityImmutableNaturalId);
Code:
0: aload_0
1: aload_1
2: dup_x1
3: putfield #2 // Field entityImmutableNaturalId:Lorg/hibernate/test/bytecode/enhancement/lazy/NaturalIdInUninitializedAssociationTest$EntityImmutableNaturalId;
6: areturn
With Java 11, however, access to fields of entities is done directly,
even for nested classes. So the access methods no longer exist, and we
don't get automatic initialization upon field access. We need extended
bytecode enhancement, like we would in any other case of field access
(in particular accessing fields of non-nested classes).
It's no longer necessary since we upgraded to byte-buddy 1.10.2,
and it causes bytecode to be converted from Java 14 to Java 12 in some
cases (I don't know why).
Andrea Boriero
Gail Badner
Nathan Xu
Steve Ebersole
Panagiotis Sotiropoulos
gavinking
Sanne Grinovero
Jonathan Bregler
Scott Marlow
Yoann Rodière