Removing MetaProperty.getAnnotatedElement from the MetaProperty interface

[fractal3000]

Currently, the MetaProperty.getAnnotatedElement method is specific only for usual JPA properties and returns the instance of java.lang.reflect.AnnotatedElement. The semantic (high level) methods are implemented in the io.jmix.core.MetadataTools. For example, there is the io.jmix.core.MetadataTools#isLob method(also, hasCompositePrimaryKey, io.jmix.core.MetadataTools#isMethodBased).

In consequence of it there are implementations io.jmix.core.impl.keyvalue.KeyValueMetaProperty.FakeAnnotatedElement and io.jmix.dynattr.impl.DynAttrMetaProperty.FakeAnnotatedElement in corresponding classes. It looks like an architecture problem.

The proposal is to:

1. Remove MetaProperty.getAnnotatedElement
2. Make extended interfaces of the MetaProperty interface. Such as StaticMetaProperty, DynamicMetaProperty, KeyValueMetaProperty.
3. Move the high level methods of the the io.jmix.core.MetadataTools that utilized the MetaProperty.getAnnotatedElement method to the StaticMetaProperty method
4. Mark the methods of the the io.jmix.core.MetadataTools that utilized the MetaProperty.getAnnotatedElement method as deprecated

[dtaimanov]

Proposed changes looks worse than FakeAnnotatedElement, because:

• It makes code more complicated and clumsy:

property.getAnnotatedElement().isAnnotationPresent(Secret.class)

becomes something like this:

StaticMetaProperty.class.isAssignableFrom(property)
               &&((StaticMetaProperty)property).getAnnotatedElement().isAnnotationPresent(Secret.class)

in 46 places in Jmix + in client projects.

• It is a breaking change => necessity to make additional migration in client projects.
• Requires significant efforts to refactor and brings risk to break something because changes are spread across the whole Jmix.

Especially, point (3)

Move the high level methods of the the io.jmix.core.MetadataTools that utilized the MetaProperty.getAnnotatedElement method to the StaticMetaProperty method

raises doubts, since it may violate single responsibility principle because it merges too much logic into MetaProperty and MetaClass mutating them from lightweight descriptor to something like descriptor-helper.

MetaClass is used more than 1,700 times in the project, and MetaProperty over 1,000 times. They are sometimes used as keys in maps. From a performance perspective, some helper methods could be moved to descriptors without any negative impact, but all other methods, which use beans, still cannot be moved to these lightweight descriptors.

So, point (3) is only a partial solution, and it would lead to unnecessary scattering of logic between classes. It would also blur the boundary between MetadataTools and MetaClass/MetaProperty, making their responsibilities and usage less clear.

Moreover (3) will break extensibility of logic. Currently, we can, and sometimes we are extend MetadataTools logic in projects. After moving it to DTOs it will not be possible anymore. Thus, I vote strongly against (3) and (4).