PS Re-refined implementation at
http://cr.openjdk.java.net/~darcy/8212081.1/
The implementation now elides "extends java.lang.Object" in "? extends
java.lang.Object" if Object is not annotated and there are no other bounds.
The tests were updated to cover this situation too.
Thanks,
-Joe
On 10/16/2018 7:26 PM, Werner Dietl wrote:
Hi Joe,
thanks for fixing this! I like the improved testing approach.
Changes look good to me, but I'm not a reviewer.
Best,
cu, WMD.
On Mon, Oct 15, 2018 at 2:11 AM joe darcy <joe.da...@oracle.com> wrote:
Follow-up fix developed; details below.
On 10/11/2018 12:12 PM, joe darcy wrote:
Hi Werner,
On 10/10/2018 1:23 PM, Werner Dietl wrote:
Hi Joe, all,
the logic looks good to me.
In the tests I'm wondering whether to include an annotated wildcard
bound. There is:
307 public @AnnotType(11) Set<@AnnotType(13) ? extends Number>
fooNumberSet2() {return null;}
but nothing like
Set<? extends @AnnotType(13) Number> fooNumberSet2() {return null;}
I wouldn't expect problems for this, but a test would exercise some of
the code that gets added.
You were correct to probe at the bounds on the wildcard components;
the code that was reviewed and pushed does not print annotations on
the bounds.
I'll work on an update to handle this and similar cases where there
are embedded types that could have annotations.
Please review the fix for
JDK-8212081 : AnnotatedType.toString implementation don't print
annotations on embedded types
http://cr.openjdk.java.net/~darcy/8212081.1/
A few notes on the test, the main structural change is that information
about the expected properties of the toString form of the AnnotatedType
of a method's return type is stored in a *declaration annotation* on the
method. The presence of the expected number of type annotations on the
full string of the AnnotatedType can thus be directly tested.
Thanks,
-Joe
