On Sat, Jul 22, 2017 at 2:44 PM, Sanne Grinovero <sanne(a)hibernate.org>
I'm not familiar enough with the whole picture but I strongly
should explore ways to get out of this lazy initialization strategy.
We have a Jandex POC but it's far from being ready for prime time.
Not something we will be able to tackle soon.
Maybe keep building it lazily during bootstrap(s) but then add a
cached metadata" hook which containers could invoke explicitly at the end
of bootstrap of an app?
Worst case you'll have to rebuild the metadata on demand.
Currently, at the end of the bootstrap of an app, you might have not
validated a bean at all, so you don't have any metadata. But I suppose you
were suggesting that we would have tackled the "load metadata lazily"
subject before that. If so, of course, we wouldn't have to keep this
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
I guess my proposal above is 3/, trying to have both benefits.
Yeah, not something we can fix soon.
Usually, Yoann and I are on the "Let's do it" side and
the others on the
"I'm not sure it's worth it" when it comes to CollectionHelper, but
considering how well the first round has paid, I think we should at least
give it a try.
I'm also quite sure it's worth applying such optimisations.
I'm only skeptical about the value of sharing such code via shared
I'd even go a step further : try avoiding wrapping into immutable when
those collections are exposed exclusively to code we directly control. The
JIT can do much magic but it won't avoid allocating the wrappers so that's
not cheap at all, but that's of course a maintenance / clean code /
Would be great to validate automatically that we treat them as effectively
immutable, maybe that's possible via annotations and some code validation
Yeah, I think the wrapping is here to stay for now.
I once thought about completely removing the method metadata if the method
wasn't annotated at all but then I thought that the overriding rules would
prevent us to do that.
Gunnar, am I right on this?
So basically, I think we can't really do anything about this.
Drop it as soon as we figure it's not useful?
Unfortunately, as we load the metadata lazily, they can be useful at any
time. That's the issue.
I also thought that it was useless to look for annotations on
java.lang.Object but then again I think the overriding rules force us to do
I'm not following here. Why is it not safe to skip annotations on Object?
There are some overriding rules you have to follow in BV.
*If a sub type overrides/implements a method originally defined in several
parallel types of the hierarchy (e.g. two interfaces not extending each
other, or a class and an interface not implemented by said class), no
parameter constraints may be declared for that method at all nor parameters
be marked for cascaded validation.*
So, you can't simply withdraw the metadata because there are no HV
information on the methods. Just the fact that a method is here has