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.
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.
>>>>>>>