Well what you mention is something I am worried about. In fact in working on HHH-16 what you mention is exactly what I see happen. The issue, as you point out, is that we render the implicit join as a "theta join".

Fundamentally the issue is figuring out where to put the join in relation to the rest of the from-clause pieces. Really this needs a change in how we model the FromClause in our AST model; specifically to model what SQL 92 calls a "table reference" (which is poorly named).

As means of example, consider the query:

select ...
from table_a a join table_b b on a.id = b.a_id,
    table_c
where ...

This query has 2 "table references":

1. table_a a join table_b b on a.id = b.a_id
2. table_c

So now fast-forward to my work on HHH-16. Consider the HQL:

select f.id, f.customer.name, u.username
from FinancialRecord f join User u on f.lastUpdatedBy = u.username

The implicit join f.customer and how Hibernate handle s that currently is the problem. So at the moment this gets rendered to SQL as:

select ...
from financial_record f,
    customer c join `user` u on f.last_updated_by = u.username

which of course fails and will fail on most dbs.

A trivial solution is to make implicit joins render as ANSI joins And that, IMO, is still a worthwhile thing to look at, but the better option is to implement this grouping of a "table reference". In fact this is exactly a change we have made in the new query parser work we are doing. So now I can attach the entity-join (join User u) to the end of the current "table reference" (I prefer to call them "spaces") rather than to the end of the current from-clause.