Make the metamodel usable in non JPA applications

[AleksNo]

Hello,

i have encountered one problem that it is not(?) possible to use the metamodel in an application which does not initialize the whole JPA stack. A call like:

String myFieldName = MyEntity_.myField.getName(); 

will end up in a NullPointerException because myField is null. But if you want to make some own APIs then the type informations which the metamodel provides could be very useful.

How to initialize the metamodel without the magic stuff which happens in the background when the JPA stack starts?

I think about something like that:

public static volatile SingularAttribute<MyEntity, String> myField = new SingularAttributeImpl("myField");

This would prevent the NPE in non JPA applications.

Greetings

[beikov]

Whatever your requirement is, I don't think the JPA metamodel will be enough for you. You can write your own annotation processor to create whatever static metamodel that you want, but I don't see how eagerly initializing the model could work nor do I see a real use case or why this should be useful. Hibernate already generates String constants for the field names, so you at least have the names statically available.

[gavinking]

@AleksNo

I think about something like that:

public static volatile SingularAttribute<MyEntity, String> myField = new SingularAttributeImpl("myField");

This would be nice, but it's not so simple. There's more information than just the field names in the metamodel objects. Indeed, at least in our implementation, there's really quite a lot of cross-references between metamodel objects, with information derived from the annotations and XML mappings of the entities.

Now, I'm not saying it would be impossible to write a "static static" metamodel generator that uses compile-time code generation instead of runtime code to initialize those fields of the static metamodel. Probably it's possible. (I don't know because I have not tried.) But it doesn't look trivial.

So let me turn this around: if you want this—and I admit it would be nice—why not go ahead and implement an annotation processor that does it, and share it with the community. You don't need permission from the JPA spec to do this! (JPA doesn't have any language which prohibits such an implementation.)

Indeed, if you came up with a reasonably robust implementation of this, perhaps we could even ship it with Hibernate and/or EclipseLink.

And since you don't need permission from the spec to implement this thing, well, then by the same token I don't see why there's any reason to change the spec to constrain implementations to work in the way you propose. I think the spec should continue to allow the runtime-based implementations that are used by persistence providers today.

So actually I'm going to close this, not because I think your implementation idea is a bad one, but only because I don't think that providers should be required to use that approach.