Why Hibernate inlines Integer parameter list passed to JPA Criteria Query?

Why are strings bound and numeric literals not bound?

One should always do parameter binding for strings (as opposed to putting the literal in the query) to avoid SQL injection.

However, the real question, is why to insert the literal directly into the query instead of using binding. The original reason was:

So iirc the issue that lead me to use literals here had to do with scale and operations. Meaning (again, iirc) some databases needed to know type information to be able to properly handle something like ... ? + ? ..., etc. So the choice was to either wrap all such params in CAST function calls and hope/pray the db implemented a proper CAST function or use literals. In the end I opted for the literal route because, well, thats what the user asked for up front. Wrapping in function calls will limit the databases ability to leverage indexes in quite a few databases.

Which is better for the db?

It depends on the database and the query and likely won't make a huge difference. For example, Oracle can only do certain partitions when the value is a literal, other databases can only do certain optimizations when the value is a bound parameter. If it becomes an issue (e.g. you profile it and you know that is what is slowing you down) then just switch to the other method.

Is this in the JPA spec?

No.

Is this related to the # of values allowed in an in statement?

No.

Can I have a numeric literal bound instead of inserted directly into the query

Yes, but it is somewhat verbose.

CriteriaBuilder cb = getEntityManager().getCriteriaBuilder();
CriteriaQuery<Foo> query = cb.createQuery(Foo.class);
Root<Foo> root = query.from(Foo.class);
ParameterExpression<Long> paramOne = cb.parameter(Long.class);
Predicate versionPredicate = root.get("bar").in(paramOne);
query.select(root).where(versionPredicate);
TypedQuery<Foo> typedQuery = getEntityManager().createQuery(query);
typedQuery.setParameter(paramOne, 1L);

That will use parameter binding for the long. It is only one parameter but one could easily extrapolate from here for multiple parameters and helper methods could clean things up.

References:

Most of the reasoning is explained and discussed in HHH-6280. The particular method in question that does this rendering is LiteralExpression.render.

In issue HHH-9576 a new parameter was added to fix this issue, applicable since version 5.2.12 (?)

<property name="hibernate.criteria.literal_handling_mode" value="bind"/>

If you use this parameter you don't need the verbose solution proposed by Pace anymore.

From hibernate documentation of literal_handling_mode:

This enum defines how literals are handled by JPA Criteria. By default (AUTO), Criteria queries uses bind parameters for any literal that is not a numeric value. However, to increase the likelihood of JDBC statement caching, you might want to use bind parameters for numeric values too. The BIND mode will use bind variables for any literal value. The INLINE mode will inline literal values as-is. To prevent SQL injection, never use INLINE with String variables. Always use constants with the INLINE mode.

1. Because Strings can contain SQL and Integers cannot, there is no need to from a security aspect (SQL injection).
2. The JPA spec doesn't specify it as explicit as you would like it to be. It seems to be an implementation details.
3. Prepared statement parameters for String parameters. For int parameters it doesn't matter since they cannot be misused by hackers.
4. YES
5. You should look that up in the documentation of the specific database you're using. JPA does not care about such things.
6. Why? What are the benefits? Don't try to improve things when you don't know what you're improving.