On Wed, Jul 19, 2017 at 3:19 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
## AnnotationMetaDataProvider#configuredBeans
So, in AnnotationMetaDataProvider, we keep a cache of the annotation
metadata found while building the aggregated BeanMetaData.
It might be useful if you have a class hierarchy for instance as you would
only build the annotation of the parent class once.
But... as we initialize the bean metadata lazily, we need to keep this
cache during the whole lifecycle of the application.
So, here, we have to find a compromise:
1/ either favor the memory footprint but the annotation of a given class
could be analyzed several times in the case of a class hierarchy
2/ or favor the startup cost (it's not a runtime cost, it's paid only once
when validating the first bean of a given class) and have a higher memory
footprint
Usually, in HV, we take the 1/ route so I was a bit surprised 2/ was
chosen here.
Thoughts?
One additional point here is that the data structure cached here are really
not designed to be kept in memory (as opposed to the aggregated ones).
Typically, ConstrainedExecutable has a reference to a
java.lang.reflect.Method and it's quite heavy (~ 1 kB).
Concrete example with (again) the RealmEntity of Keycloak:
- ConstrainedExecutable of setSmtpConfig(Map): ~ 1.5 kB
- Total size of the BeanConfiguration: ~ 173 kB
(this with the new additional cascading metadata for container elements
which are quite heavy in this building phase)
So my vote would go for 1/ and I would accept the additional startup cost.
--
Guillaume