You seem to be looking at it from a perspective of “how can we minimize the amount of undefined behavior hibernate produces”.

Precisely. That’s one of the very clear and explicit goals of H6.

I’m looking at it from a perspective of “If I pass correct values (and types) to Hibernate I’d like to get correct results”.

If Hibernate doesn’t know the types of things, it can’t possibly know what behavior is “correct”, or guarantee that you’ll get it.

So from this point if view, the best solution is to be explicit about the types of things.

But I guess a way to do math in HQL is desirable?

You don’t need implicit type conversions to do math. You can always fall back to doing type conversions explicitly.

there needs to be a way to communicate the unknown types to Hibernate so that it can know it’s in a valid case and does not error.

Which you can actually already do here by writing test.intField * cast(?1 as BigDecimal) as I noted below.

On first glance it seems to be me that the information is already present in a stronger the form of the parameter type.

Unfortunately, the information about bound arguments is not available at the time the query is compiled. We compile the query when you call in createQuery(), not when you call getResultList().

This is actually more important than it perhaps sounds: we have named queries which are compiled at startup via @NamedQuery, and even for queries passed as strings we have a QueryInterpretationCache. So we prefer to avoid having the semantics of the query depend on the arguments you bind to parameters.

Look, I’m not implacably opposed to trying to solve this in some subset of cases. I’m just trying to point out to you that the problem is quite a lot more subtle than you imagine. So any “solution” would involve coming up with a sensible and clearly-defined bright-line rule and not a bunch of band-aids that accumulate over time.

In the meantime, I think the workaround with cast() is really quite reasonable.