After some more thinking we decided to reject this. It would only help when creating multiple violations via the ConstraintValidatorContext. In all other cases no guarantee of order can be given.

Even if we would use a linked set we would not like to document this, because this would lock in our implementation. And just changing it w/o making it an actual feature seems pointless.

We will consider it

You're right on both counts, which is why I filed it as a possible improvement. It would be nice for this case to do what seems like the obvious thing ("add" appending messages to an ordered list), but I won't lose any sleep if it doesn't

Ok, got you.As said, the problem is that the spec does not guarantee an order, also not in the context of ConstraintValidatorContext. I guess we could just use a LinkedHashSet, but then you would be relying on something which is not portable. Also this order makes only sense in conjunction with ConstraintValidatorContext. The order in which constraints are evaluated is still undefined.

Right, I'm saying it would be nice to have the option of a guaranteed order. As an example, in my current application, I add five constraint violations at once if specific conditions are not met, so you would get something like:

I am adding these constraints using validatorContext.buildConstraintViolationWithTemplate(message).addConstraintViolation(), which puts the items in an ArrayList. Later, they are moved to a HashSet, and then to a String[] array for display.

So the question is: why keep order intact when adding constraints (ArrayList) and displaying constraints (String[]), but not in between?

Obviously, the HashSet randomly jumbles the order of messages, which then make no sense. Using a LinkedHashSet in the implementation instead would keep the order intact.

As it is, I am currently implementing my own <custom:errors> JSP tag which sorts the messages by a number prefix it then removes, which is of course suboptimal.