On 23 July 2017 at 21:23, Guillaume Smet <guillaume.s...@gmail.com> wrote: > 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.
Just nitpicking, as I guess skipping a single class isn't going to revolutionize the world, but can't you take advantage of the basic assumption that all objects extend `java.lang.Object` ? In short, that paragraph doesn't seem to apply. Thanks, Sanne > > -- > Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
