HHH-19209 Verify and fix ID class generation for inner classes

[cigaly]

Jira issue HHH-19209

• sorting record components when generating ID class
• added tests to check ID class generation from inner classes; fixed minor bug in generated class name
• test classes in core that are using entity (instead of ID) as parameter to find method are annotated with @Exclude to avoid failing tests

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

[cigaly]

My assumption that record component must be alphabetically sorted by name was not correct, so All code and test based on the assumption are now removed.
Due to that change, three existing test cases are now failing:
org.hibernate.orm.test.annotations.formula.JoinFormulaManyToOneLazyFetchingTest,
org.hibernate.orm.test.annotations.formula.JoinFormulaManyToOneNotIgnoreLazyFetchingTest, and
org.hibernate.orm.test.annotations.formula.JoinFormulaOneToOneNotIgnoreLazyFetchingTest.
But this is not caused by changes in this PR.

[cigaly]

All tests are failing due to problem described in Jira issue HHH-19214 [ see PR #9824 ]. This is not caused by changes made in this PR:

[gavinking]

@cigaly Right now it is generating the id class with the name Entity_.Id, and I think I prefer that to the ugly $.

[cigaly]

I am afraid that (like as with money) you can not avoid $ with subclass. In include statement, you use ., but class name will always have $ in the place of .. Like in ...

jshell> class X { class Y {}}
|  created class X

jshell> var c = X.Y.class
c ==> class X$Y

Something like split personality :-)

[gavinking]

Oh, my apologies, I did not read carefully enough and I thought we were in the annotation processor where the APIs shield us from the $. I guess I don't really understand what that code is doing.

[gavinking]

I guess I don't really understand what that code is doing.

Oh, alright, I get it now.

[cigaly]

There is also problem with Envers. It can not handle record as IdClass so I have to annotate one test class with @Exclude.

It seems not so difficult to fix that, but I am not sure if this can be done without changing some existing interfaces, so I would rather prefer not to do that on my own.

[gavinking]

There is also problem with Envers. It can not handle record as IdClass

Does this mean that id class generation breaks existing code that uses Envers?

[cigaly]

Yes, under two conditions - if generated ID class is record and if Envers remains in pre-records age. Quickest (and, hopefully, temporary) fix can be to generate ID class as POJO, but the long term fix should to introduce Envers to record.