2

This question came out of my attempts to unify the JPA EntityManager contract with the Hibernate Session contract. An example method where this comes into play is an overloaded method named createQuery. Session inherits many forms of this method from its super contracts. Session then tries to extend EntityManager as well, so it then inherits the createQuery forms defined by EntityManager.

When I try to use Session to create a query given an HQL/JPQL String the compiler complains saying that the call is ambiguous, that 2 methods in particular match:

  1. Query createQuery(String queryString)
  2. <T> Query<T> createQuery(CriteriaQuery<T> criteria)

The only solution I have found is to explicitly "override" each of these forms on Session itself. We surmise that somehow "unifies" the type parameter (<T>) resolution. But I'd really like to understand the why behind this. Any thoughts? Any better way to resolve this besides explicitly overriding each form on Session?

Longer version... :)

Hibernate defines both a Session contract and a StatelessSession contract to users. Each define a common set of methods plus there own individual methods. Part of this common set of methods is the ability to create Query objects:

interface QueryProducer {
    Query createQuery(String queryString);
    ...
}

What I am trying to accomplish overall is to have Hibernate's Session (but not its StatelessSession!) contract extend the JPA EntityManager. So in that regard Session inherits the QueryProducer methods, but the EntityManager methods as well, e.g.:

interface EntityManager {
    Query createQuery(String queryString);
    TypedQuery<T> createQuery(CriteriaQuery<T> criteriaQuery);
    ...
}

It's whenever I try to use one of these commonly inherited methods that I see the problem warning about the method call being ambiguous between #createQuery(String) and #createQuery(CriteriaQuery<T>).

dimo414
  • 47,227
  • 18
  • 148
  • 244
Steve Ebersole
  • 9,339
  • 2
  • 48
  • 46
  • 3
    The code and the exact and complete error message would make the question clearer. I don't understand how a call could be ambiguous, given that the argument types are completely different. – JB Nizet Apr 18 '16 at 16:22
  • You might also distill the problem down by creating test classes that exhibit the same problem, since this probably has nothing to do with jpa itself. – Hank D Apr 18 '16 at 18:16
  • I tried reproducing the problem based on your description, but everything compiles fine: https://gist.github.com/jnizet/f584397d271d6df49ec1910963840fef. Could you provide such a self-contained example reproducing the problem? – JB Nizet Apr 18 '16 at 18:53
  • TBH, I only saw it in the IntelliJ editor. I am currently fighting through hundreds of compile errors, so I have not seen that actually from the compiler. Just trusting that IntelliJ's editor checks there would be accurate. – Steve Ebersole Apr 18 '16 at 19:22
  • Can you show an example ambiguous call, i.e. the call-site logic? I don't see how this situation creates ambiguity. – Lukas Eder Apr 19 '16 at 06:58
  • https://github.com/sebersole/hibernate-core/tree/HHH-10664 @ 1acd1e551573291fa55d3346f842dccc932a1ffd is where I see it. But it may just be an IntelliJ thing – Steve Ebersole Apr 22 '16 at 11:26
  • In `createQuery(CriteriaQuery)` it's returning a `Query` yet everywhere else `Query` doesn't have a generic type. Is the `createQuery()` method signature you list here correct? Or are you using `Query` as a [raw type](http://stackoverflow.com/q/2770321/113632) everywhere else? If the latter that is likely the source of your issue - avoid raw types. – dimo414 Jun 02 '16 at 04:42

0 Answers0