Annotated Type bugs in OpenJDK 8

[Joel Borggrén-Franck]

Hi,

Discussing the spec change here on compiler dev is fine, but for code reviews please use core-libs-dev at openjdk.java.net .

As Alex writes, adding owner method would require a spec change and should go into 9. I would also target the equal/hashcode changes to 9. When I looked at this in September/October I came to the conclusion that a default method throwing UnsupportedOperationException is the best option, if someone has an external implementation UOE is nicer than the linkage error I assume would happen if someone calls the missing method. If there are no external implementations this would never be called.

I made a pass at fixing some of the errors in September, but when it became clear this would be a 9 only fix the patch got stuck in my patch queue. Feel free to reuse or compare notes with

http://cr.openjdk.java.net/~jfranck/8057804/annotated-owner.patch

(I noticed it doesn’t add a default, but that should be easy to fix).

I’m not sure why https://bugs.openjdk.java.net/browse/JDK-8066967 was closed. I reopened it, I’m not sure what the error is here, but if you have a fix, go for it.

Also, make sure you sign the OCA, http://www.oracle.com/technetwork/community/oca-486395.html

For the spec change we have an internal process to approve those. When you have fix with approved review and have all the paperwork signed someone on this list or core-libs-dev can help you go through that. That someone would normally be me, but I’m going on parental leave.

Once the fix for https://bugs.openjdk.java.net/browse/JDK-8057898 and possibly https://bugs.openjdk.java.net/browse/JDK-8066967 are in 9 you can consider back porting them to 8u.

cheers
/Joel

> On 26 feb 2015, at 00:18, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> // compiler-dev is the correct list. type-annotations-dev is defunct.
> 
> Regarding JDK-8057804, I agree that AnnotatedParameterizedType deserves a getAnnotatedOwnerType() method. Since adding this method involves changing the Java SE API, it will need to target JDK 9 and appear in the compatibility notes.
> 
> As a practical matter, it is extremely unlikely that there now exist non-JDK implementations of AnnotatedParameterizedType, so I would go ahead with option 1 (no default method). However, Joe may have a different view (though the experience of adding default methods to Core Reflection in Java SE 8 did not turn out quite as expected, IIRC).


>> On 02/25/2015 10:02 AM, Joshua Humphries wrote:
>>> Hey, all,
>>> I'm want to contribute some fixes to JDK 8 Updates related to annotated
>>> types in core reflection.
>>> 
>>> After much pain, I finally got it to build on my Macbook. So now I'm
>>> ready
>>> to tackle a patch. The issues I plan to address in this patch follow:
>>> 
>>>    - JDK-8057804 <https://bugs.openjdk.java.net/browse/JDK-8057804>
>>>    - JDK-8057898 <https://bugs.openjdk.java.net/browse/JDK-	>
>>>    - JDK-8058202 <https://bugs.openjdk.java.net/browse/JDK-8058202>
>>>    - JDK-8066967 <https://bugs.openjdk.java.net/browse/JDK-8066967>
>>> (marked
>>>    resolved as a dup of the one above, JDK-8058202, but really is
>>> *not* a
>>>    dup)
>>> 
>>> I actually filed all of these back in September. Unfortunately, since I'm
>>> not an OpenJDK author, I can't login and add more comments to any of thee
>>> bugs or interact with the assignee through the bug dashboard :(
>>> 
>>> They are all assigned to Joel Borggrén-Franck -- so I hope you're on this
>>> list and see this, Joel :)
>>> 
>>> The biggest change is JDK-8057804
>>> <https://bugs.openjdk.java.net/browse/JDK-8057804>, so I wanted to
>>> discuss
>>> options of how to address it.
>>> 
>>> To summarize: there is a glaring omission in the
>>> java.lang.reflect.AnnotatedType interfaces: there is *no way* to get
>>> to the
>>> annotations on a (non-static, inner) parameterized type's owner.
>>> 
>>> The AnnotatedParameterizedType interface really *should *have a method
>>> such
>>> as:
>>>    AnnotatedType getAnnotatedOwnerType();
>>> 
>>> Without it, there is *no way* to use core reflection to examine
>>> annotations
>>> on the owner type. Such annotations are allowed, included in the class
>>> file
>>> by the compiler, and available via the model and annotation mirror APIs
>>> used by annotation processors. But they aren't available via core
>>> reflection.
>>> 
>>> I've experimented with adding this method, and I have things working in a
>>> local development environment. But there are some nasty implications to
>>> adding a method to an interface. I think there are three approaches that
>>> can be taken:
>>> 
>>>    1. Add the method to the interface. Do not supply a default
>>>    implementation (e.g. break compatibility). This would be very
>>> similar to
>>>    the action taken in Java 8 to add the #getAnnotatedBounds() method
>>> to the
>>>    TypeVariable interface. (Related: JDK-8062794
>>>    <https://bugs.openjdk.java.net/browse/JDK-8062794>)
>>>       - If such an incompatible change were deemed acceptable, it is
>>>       unlikely that it would be done in a point release. So, if this
>>> is the right
>>>       solution, it would probably need to be implemented in the JDK 9
>>> project
>>>       instead of the JDK 8 Updates project
>>>    2. Add the method to the interface. Supply a default
>>> implementation for
>>>    backwards compatibility.
>>>       - A "best effort" implementation could grab the corresponding
>>>       ParameterizedType's owner and wrap it an AnnotatedType that has no
>>>       annotations. But then we're quietly suppressing the fact that
>>> we've lost
>>>       any annotations actually present.
>>>       - Instead of supplying an incorrect implementation, perhaps a
>>> better
>>>       default would be to simply throw UnsupportedOperationException,
>>> kind of
>>>       like the default implementation added for Iterator#remove().
>>>    3. Add a new interface that extends AnnotatedParameterizedType and
>>> adds
>>>    the method. This has the downside of polluting the namespace with
>>> redundant
>>>    interfaces, solely for trying to maintain compatibility. (No
>>> future code
>>>    should ever really use AnnotatedParameterizedType, so this feels
>>> icky.)
>>> 
>>> At the moment, I'm tempted to think that option #2 is the best, with the
>>> default implementation being to throw.
>>> 
>>> I was hoping for some feedback from folks on this list with goal of
>>> arriving at a solution that would be accepted into the JDK 8 Update
>>> project.
>>> 
>>> ----
>>> *Joshua Humphries*
>>> joshua at bluegosling.com
>>