While debugging some more sophisticated case-when-then expression compilations, I stumpled upon a potential flaw in org.hibernate.jpa.criteria.expression.SearchedCaseExpression#javaType, which possible was introduced to lazily assign the expression's type based on either -case-when result's type or a case-otherwise type.

Actually org.hibernate.jpa.criteria.expression.SearchedCaseExpression#javaType does get written, but never gets read, so it's more or less dead code. If one requests SearchedCaseExpression's type, null will be returned, as the method is implemented in org.hibernate.jpa.criteria.expression.AbstractTupleElement (which still references javaType as null) and not overriden in SearchedCaseExpression.

I am sure, this was not intended and may lead to bugs. A possible fix would look like either SearchedCaseExpression needs to override getJavaType() or SearchedCaseExpression#adjustJavaType(Expression) needs to delegates the expression's type via AbstractTupleElement#resetJavaType(Class) to it's orignal field.

wdyt?