[hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

[Emmanuel Bernard]

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 at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/hibernate-dev