Can't you a priori apply your optimization and have a if ( perInstance != perFactory ) backdoor? Meaning I don't really get why you cannot apply your optimization by default and fall back to a slow codepath when the value is overridden.
Emmanuel On Mon 18-03-19 17:47, Guillaume Smet wrote: >Hi, > >So I know we like to have API compatibility discussions these days, so >let's start a new one. > >FWIW, this discussions doesn't come out of the blue, it's based on >discussions we had for one of Marko's PRs. > >In HV, you can set the parameter name provider at the VF level and you can >also override it on a per Validator basis using >HibernateValidatorContext#parameterNameProvider(). > >To be honest, I'm a bit skeptical about the usefulness of overriding this >setting at the Validator level: it really seems to be a global setting, >especially because it has an influence on what could be considered a >metadata and metadata are considered static in HV. > >At the moment, the parameter name is resolved at runtime each time it's >required due to this feature. > >I would like to deprecate the feature for now and possibly remove it in a >future version (I thought about maybe keeping the method for a while but >logging a warning stating it's not doing anything anymore?). > >We expect some runtime performance enhancement (this is not the reason of >this post) but it seems we could also get rid of storing the Executable in >the metadata and reduce our memory footprint for executables, which would >be nice. > >Thoughts? > >-- >Guillaume >_______________________________________________ >hibernate-dev mailing list >hibernate-dev@lists.jboss.org >https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev