HHH-18693 Hibernate Processor does not handle inner types

[cigaly]

See Jira Issue HHH-18693

This is still work in progress, not to be merged with main branch, at least not immediately.

For each (static) inner non-private class one meta-model class will be generated.

Naming is as follows. If we have:

class A {
    ...
    @Entity
    static class B {
        ...
    }
    ...
}

Generated class will be named A_B_

---

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]

Some existing test classes were changed to make inner classes non-private. Otherwise such class could not be referenced from meta model class.

[gavinking]

Thanks for working on this @cigaly !

[gavinking]

Some existing test classes were changed to make inner classes non-private. Otherwise such class could not be referenced from meta model class.

I think the Processor is still going to have to be able to elegantly handle private inner classes; we don't want to simply disallow that.

So I'm not quit sure what "elegantly" means here ... perhaps it just means "skip them".

[cigaly]

So I'm not quit sure what "elegantly" means here ... perhaps it just means "skip them".

Other than disallowing private classes (either inner or top-level) , excluding them from metamodel generation is only solution that will not cause Java compilation errors. And, of course, there is always possibility that private static class could be referenced by either top level class containing private class or other inner class contained by same top level class.

Now only one test class has to be changed to avoid compilation errors is org.hibernate.orm.test.schematools.PrimaryKeyColumnOrderTest.EntityId. Here metemodel generated from

	public static class EntityId implements Serializable {
		private int A;
		private int B;
	}

will result in

public abstract class PrimaryKeyColumnOrderTest_EntityId_ {
	public static final String A = "A";
	public static final String B = "B";
	public static volatile SingularAttribute<EntityId, Integer> A;
	public static volatile SingularAttribute<EntityId, Integer> B;
	public static volatile EmbeddableType<EntityId> class_;
}

which is definitely something Java is happy with. Perhaps some mechanism can be added to prevent such duplications, but until then this class should be slightly changed to let tests to run.

[gavinking]

Now only one test class has to be changed to avoid compilation errors is

Hurm.... so that's actually a hole in the algorithm defined by the spec, isn't it? We should fix that, in both Processor, and in the spec. For example, we could say that A -> _A.

[cigaly]

This is more like one of those "tricky" questions for entertainment pages of some Java magazine. Something like "how are named getters and setters in a class with int property named abc and String property named Abc".

It seems that in current code only problematic are properties with name consisting of single uppercase letter. To fix that (at least, until some other solution) I will change method org.hibernate.processor.util.StringUtil#getUpperUnderscoreCaseFromLowerCamelCase by inserting right after method declaration lines

		if (lowerCamelCaseString.length()== 1 && lowerCamelCaseString.toUpperCase().equals( lowerCamelCaseString )) {
			return "_" + lowerCamelCaseString;
		}

(or, maybe, to use underscore as a suffix?)

If nothing else, this will allow implement metamodel class generation for inner classes, without touching any core (main or test) code.

[gavinking]

Yeah but you can just use Character.isUpperCase() 😜

[cigaly]

Yes, you are right. It seems that I am still sleepy :-)