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
--
http://www.google.com/profiles/wdietl
