FetchParent extends From. Its not a conflict. Well except to this
Java 6 compiler bug, which maybe is your point.
On Thu 21 Jun 2012 03:52:03 PM CDT, Linda DeMichiel wrote:
>
>
> On 6/21/2012 11:54 AM, Steve Ebersole wrote:
>> Sorry, but I am not understanding you. How would getParent()
>> conflict? They both return From. There is no covariant
>> returns there.
>>
>
> Fetch.getParent() returns FetchParent, not From.
>
>
>> On Thu 21 Jun 2012 11:58:57 AM CDT, Linda DeMichiel wrote:
>>>
>>>
>>> On 6/21/2012 5:44 AM, Steve Ebersole wrote:
>>>> Hard to say exactly without access to the bug we cannot see ;)
>>>>
>>>> But my understanding is that the bug is with compiling convariant
>>>> returns for methods on interfaces. getParent() return
>>>> is non-dynamic.
>>>>
>>>
>>> My point was that independent of the earlier bug, having Fetch extend
>>> Join resulted in conflicting getParent() methods.
>>> Did I misunderstand what you were proposing?
>>>
>>>> On Wed 20 Jun 2012 05:00:57 PM CDT, Linda DeMichiel wrote:
>>>>>
>>>>>
>>>>> On 6/19/2012 10:50 AM, Steve Ebersole wrote:
>>>>>> We'll have to agree to disagree I guess (unfortunately for me). I
>>>>>> guess we are too far down the current path.
>>>>>>
>>>>>> Anyway, a related concern I would like to raise is the on(...)
>>>>>> method
>>>>>> definitions on Join and Fetch. Join and Fetch are
>>>>>> unrelated interface hierarchies. In Hibernate at least I decided to
>>>>>> combine those interface hierarchies so I have an
>>>>>> interface JoinImplementor that extends both Joing and Fetch (a Fetch
>>>>>> really is just a specialization of a Join). Now in
>>>>>> JPA 2.1 with the addition of these on(...) methods, we now hit a bug
>>>>>> in javac in every Java 6 JDK (Oracle on all
>>>>>> platforms, OpenJDK, Mac JDK). The original bug report (6294779) is
>>>>>> unfortunately no longer accessible on the Oracle Java
>>>>>> bug tracker, although google searches find tons of references to
>>>>>> it..
>>>>>> The bug was fixed in Java 7's JDK.
>>>>>>
>>>>>> Any possible way to get Fetch to extend Join?
>>>>>>
>>>>>
>>>>> Um, what about the conflicting getParent() methods?
>>>>>
>>>>>> On Mon 18 Jun 2012 05:15:18 PM CDT, Linda DeMichiel wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 6/8/2012 11:23 AM, Steve Ebersole wrote:
>>>>>>>> Also, in using ON to both (1) define the join conditions in an
>>>>>>>> ad-hoc
>>>>>>>> join (not supported in JPA) and (2) supply extra
>>>>>>>> join conditions to an association join, we have a situation where
>>>>>>>> keywords are used for 2 different purposes. I'd really
>>>>>>>> like this to be changed. I think it will be completely
>>>>>>>> confusing to
>>>>>>>> users if and when JPA decides to allow ad-hoc joins.
>>>>>>>>
>>>>>>>
>>>>>>> I'm afraid I don't agree. If someone understands the semantics
>>>>>>> of SQL
>>>>>>> ON conditions, I don't see
>>>>>>> that they wouldn't also be able to understand the difference
>>>>>>> between
>>>>>>> its effect on our relationship
>>>>>>> joins vs on ad hoc joins, were we to add them.
>>>>>>>
>>>>>>>
>>>>>>>> On Thu 24 May 2012 02:51:21 PM CDT, Steve Ebersole wrote:
>>>>>>>>> Cool, thanks for the pointer.
>>>>>>>>>
>>>>>>>>> So the answer to the question asked there about why a different
>>>>>>>>> keyword is "needed", is that its not "needed". But it makes
>>>>>>>>> things
>>>>>>>>> much cleaner to specify in EBNF and much more efficient to parse.
>>>>>>>>> Again the issue is not really evident today because JPQL only
>>>>>>>>> allows
>>>>>>>>> association joins. If and when it allows ad-hoc (non-association)
>>>>>>>>> joins thats when this becomes an issue.
>>>>>>>>>
>>>>>>>>> Like I mentioned in my initial email its a difference between
>>>>>>>>> syntactic analysis versus semantic analysis of the query.
>>>>>>>>> Syntactic
>>>>>>>>> differences are much easier to describe in an EBNF and much more
>>>>>>>>> efficient to parse.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu 24 May 2012 02:31:14 PM CDT, Linda DeMichiel wrote:
>>>>>>>>>> Hi Steve,
>>>>>>>>>>
>>>>>>>>>> Please see the thread that started March 11, 2011. This
>>>>>>>>>> should be
>>>>>>>>>> available in the archives.
>>>>>>>>>>
>>>>>>>>>> -Linda
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/24/2012 12:09 PM, Steve Ebersole wrote:
>>>>>>>>>>> I was not a member on the list when this was originally
>>>>>>>>>>> discussed, so
>>>>>>>>>>> I apologize for dragging up a potentially old
>>>>>>>>>>> discussion. But I wanted to caution against the use of 'ON'
>>>>>>>>>>> as a
>>>>>>>>>>> keyword in the way it is currently proposed in the
>>>>>>>>>>> specification.
>>>>>>>>>>>
>>>>>>>>>>> The problem is ambiguity in cases where the provider supports
>>>>>>>>>>> 'ON' as
>>>>>>>>>>> a more SQL-like ad-hoc joining capability between
>>>>>>>>>>> unassociated entities. In such cases the keyword 'ON' is often
>>>>>>>>>>> the
>>>>>>>>>>> only SYNTACTIC disambiguation between the 2 cases.
>>>>>>>>>>>
>>>>>>>>>>> Consider:
>>>>>>>>>>>
>>>>>>>>>>> select s.name, count(p.id)
>>>>>>>>>>> from javax.persistence.ex.Supplier s
>>>>>>>>>>> inner join javax.persistence.ex.Product p
>>>>>>>>>>> on s.id = p.supplierId
>>>>>>>>>>>
>>>>>>>>>>> So here we have Supplier and Product as unrelated classes (no
>>>>>>>>>>> mapped
>>>>>>>>>>> association). The problem is that structurally
>>>>>>>>>>> (syntactically) the query is completely ambiguous with the
>>>>>>>>>>> proposed
>>>>>>>>>>> form:
>>>>>>>>>>>
>>>>>>>>>>> select s.name, count(p.id)
>>>>>>>>>>> from javax.persistence.ex.Supplier s
>>>>>>>>>>> inner join s.product
>>>>>>>>>>> on p.status = 'inStock'
>>>>>>>>>>>
>>>>>>>>>>> where the join is an association join.
>>>>>>>>>>>
>>>>>>>>>>> When parsing queries its always better to disambiguate based on
>>>>>>>>>>> syntax whenever possible. Here we instead have to fall
>>>>>>>>>>> back to semantic disambiguation, which essentially means
>>>>>>>>>>> that we
>>>>>>>>>>> now
>>>>>>>>>>> have to hold parsing and interpret the meaning of
>>>>>>>>>>> the 2 sides of the join in oder to know what type of join it
>>>>>>>>>>> is.
>>>>>>>>>>>
>>>>>>>>>>> Not to mention that it is odd in my opinion for developers
>>>>>>>>>>> versed in
>>>>>>>>>>> SQL to see ON used here. The first thought is
>>>>>>>>>>> whether that adds to the SQL ON clause defined by the
>>>>>>>>>>> association
>>>>>>>>>>> mapping or whether that replaces it. So we lose a
>>>>>>>>>>> little intuitiveness.
>>>>>>>>>>>
>>>>>>>>>>> I'd really rather see a different keyword here. In Hibernate we
>>>>>>>>>>> chose
>>>>>>>>>>> WITH as the keyword for this for just these reasons:
>>>>>>>>>>>
>>>>>>>>>>> select s.name, count(p.id)
>>>>>>>>>>> from javax.persistence.ex.Supplier s
>>>>>>>>>>> inner join s.product
>>>>>>>>>>> with p.status = 'inStock'
>>>>>>>>>>>
>>>>>>>>>>> there I think it is very obvious that the condition is added
>>>>>>>>>>> to the
>>>>>>>>>>> SQL ON clause.
>>>>>>>>>>>