On Sat, Jul 22, 2017 at 2:44 PM, Sanne Grinovero <sa...@hibernate.org> wrote:
> I'm not familiar enough with the whole picture but I strongly suspect you > 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 "drop > 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 metadata anymore. > 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 > > > 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 > libraries. > > 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 / > performance tradeoff. > Would be great to validate automatically that we treat them as effectively > immutable, maybe that's possible via annotations and some code validation > tools? > 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 > so. > > > 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. For instance: *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 consequences. -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
