I'm implementing some "Type argument constraints" validators, and I noticed that the doc (and my prototype) has a Property Path value ending with ".<collection element".

What information does that provide that isn't implicitly obvious from the "listname[index]" that comes immediately before it?

This node name is chosen to indicate that the violation relates to a constraint declared on the type argument of a generic container, which lets you tell it apart e.g. from a constraint on a property of that container element. One probably could achieve the same with the name being null for the container element constraint case, but we favored the more explicit approach.

Note that in Bean Validation 2.0 / Hibernate Validator 6 there'll be a new node type (CONTAINER_ELEMENT), the node names will be standardized and there'll also be two new members on the relevant Node subtypes, getContainerClass() and getTypeArgumentIndex(), providing all the information to identify the location of the violated constraint.

If you look into using constraints on container element constraints, I'd recommend to try and use HV 6.0 as semantics have been clarified and partly changed in the course of adding this functionality to the specification. E.g. you can now have constraints on nested containers, too: Map<String, List<@Size(min=1) String>>.

It seems completely unambiguous to just end the property path with "collectionproperty[index]". In my code that uses the property path to render an error message, I'm specifically removing that string.



Noted. I'll clearly have some porting work when/if we upgrade.

You'd end up with the same string representation if a class-level constraint in the contained element was violated (e.g. a @ScriptAssert on Address, when validating @Valid List<Address>). In BV 2.0 it'll be possible to put constraints to the values and keys of maps (or any type argument really), then the name further helps to identify the location.