Sorry, but I am not understanding you. How would getParent() conflict?
They both return From. There is no covariant returns there.
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.
>>>>>>>>>