JEP proposed to target JDK 9 (2015/1/8)

[David M. Lloyd]

Makes sense, though it's unfortunate.  But really it's not terrible to 
mitigate using some utility classes, so I guess we'll survive, somehow. :-)

On 01/12/2015 05:44 PM, Joseph D. Darcy wrote:
> Hello,
>
> We may have missed some cases, but during the design of the
> javax.lang.model.* APIs we consciously tried to avoid overuse of
> covariant overrides. (Such overuse was a lesson learned from the earlier
> apt API.)
>
> A design requirement of this API was that multiple independent
> implementation would be possible, notably javac and the Java compiler
> portion of Eclipse. The implementation model of the compiler need not
> closely resemble the interface hierarchy of javax.lang.model.*; in
> particular, we needed it to be possible to have one implementation class
> implement multiple modeling interfaces.
>
> This requirement precludes some otherwise helpful covariant returns.
>
> HTH,
>
> -Joe
>
> PS As noted in the documentation of these types, instancesof checks
> aren't always a reliable way to test what an object really is -- using
> getKind or calling a visitor are recommended.
>
> On 1/9/2015 3:44 PM, Jonathan Gibbons wrote:
>> David,
>>
>> That's not a goal of this JEP, but it does sound an interesting issue.
>> I would suggest filing an Enhancement Request against the API, so that
>> this can be tracked in its own right.
>>
>> -- Jon
>>
>>
>> On 01/08/2015 06:05 PM, David M. Lloyd wrote:
>>> Having used this API more than a bit, I think it would be super-nice
>>> if this enhancement could be extended slightly to add covariant
>>> overrides where appropriate in the javax.lang.model API, if it is at
>>> all possible to do so in a binary-compatible way.
>>>
>>> Specifically, where types and elements are converted to one another
>>> is a really painful part of this API; for example I'm pretty sure
>>> that DeclaredType.asElement() could return a TypeElement rather than
>>> an Element and save everyone lots of annoying casting.  Not sure if
>>> it's possible to keep the compatibility bridge method though in this
>>> particular case.  But it would be nice to at least briefly explore
>>> this path.
>>>
>>> On 01/08/2015 03:53 PM, mark.reinhold at oracle.com wrote:
>>>> The following JEP has been placed into the "Proposed to Target"
>>>> state by its owner after discussion and review:
>>>>
>>>>    217: Annotations Pipeline 2.0 http://openjdk.java.net/jeps/217
>>>>
>>>> Feedback on this proposal is more than welcome, as are reasoned
>>>> objections.  If no such objections are raised by 22:00 UTC next
>>>> Thursday, 15 January, or if they're raised and then satisfactorily
>>>> answered, then per the JEP 2.0 process proposal [1] I'll target
>>>> this JEP to JDK 9.
>>>>
>>>> (This information is also available on the JDK 9 Project Page [2]).
>>>>
>>>> - Mark
>>>>
>>>>
>>>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>>>> [2] http://openjdk.java.net/projects/jdk9/
>>>>
>>>
>>
>

-- 
- DML