anchor.diff:      // traditional style; continues to be supported
       @Valid
       private Map<AddressType, Address> addressesByType;
  +
  +    // discouraged; either the map or the map value type argument should be
  +    // annotated with @Valid, but not both
  +    @Valid
  +    private Map<AddressType, @Valid Address> addressesByType;
   }
   ----
   ====
  
positive.code:     // traditional style; continues to be supported
      @Valid
      private List<PhoneNumber> phoneNumbers;
  }
  ----
  ====
  
negative.code: In addition, there is a built-in extractor for the key objects of maps.
  See <<valueextractordefinition-builtinvalueextractors>> for the complete list of built-in value extractors.
  
  For a given container, the `@Valid` annotation should either be put to the container itself _or_ to the type argument(s) of container,
  but not both (in order to prevent the container elements from being validated twice).
  
  [tck-testable]#The [classname]`@Valid` annotation is applied recursively.# A conforming implementation avoids infinite loops according to the rules described in <<constraintdeclarationvalidationprocess-validationroutine-graphvalidation>>.
  
  [[constraintdeclarationvalidationprocess-requirements-graphvalidation-examples]]
  