I have identified what I consider a valid bug against Hibernate v.3.5.0 and posted the details of that bug on JIRA. To help with the re-production of the bug, I've provided a test case which clearly illustrates the bug and uploaded it along with the bug description.

Today, I got a notification from JIRA that the bug has been resolved as "Rejected". The only comment posted along with that rejection is "Please use the user forum (https://forum.hibernate.org/) for help."

The bug is related to the fact that if one uses the new JPA 2.0 criteria API to create a query where one of the predicates in the where clause compares a numeric field (int or long) with a certain value, the generated query does not use a bind variable for that value, but rather hard-codes the value in the query, which can significantly impact the performance on Oracle databases. This can also have an impact on security in relation to SQL injection, although I can not verify that since I have not tested it or looked into the source code.

For me, this bug is a show-stopper and I would not switch to JPA 2.0 criteria until it's fixed. I would appreciate if someone from the Hibernate development team could highlight why such a bug has been rejected.

The issue is http://opensource.atlassian.com/project ... e/HHH-5161 .

You need to use a ParameterExpression. See the spec for details.

I've read section 6.5.9 of the specificiation and I quite disagree with your interpretation.

ParameterExpression is a way to allow the user to create a predicate where the value of the parameter can be specified before executing the query. So, in this case, the user explicitly specifies that he would like to bind the value to the parameter later.

This is quite different from the case I provided where the user does not require this facility but for performance reasons, the engine needs to implement it this way.

Further, the behavior of Hibernate is not consistent in this regard, since if I do NOT use a ParameterExpression while creating a predicate which compares a String field, the generated query actually uses bind variables (is parameterized). For example, if in the test case I provided, instead of testing against the regionId, the predicate compares a String value with the "regionName", the generated query becomes:

select
region0_.REGION_ID as REGION1_0_,
region0_.REGION_NAME as REGION2_0_
from
REGIONS region0_
where
region0_.REGION_NAME=?

Another issue is that per the spec, parameter expressions should accept parameters which are both named and unnamed. In the Hibernate implementation, if one uses an unnamed parameter and attempts to set its value using its position, an exception is thrown:

java.lang.IllegalArgumentException: Criteria queries do not support positioned parameters

This behavior is not per the spec either.