var path = violation.getPropertyPath().toString();
No, it's not much but it saves boilerplate. In addition, if the actual implementation ever does change, this method's implementation could also be changed to work the way it has for literally all the years I've been using Jakarta Bean Validation (and Java Bean Validation before it moved to Jakarta). In other words, code that uses this new method instead of Path#toString directly would not need to change in the (unlikely) event that the implementation changes, because we can simply update the implementation in KiwiConstraintViolations, and all code using our implementation keeps working once the kiwi dependency version is updated.
We will add all the potential problems with using this to the javadoc as an implementation note, specifically this:
Clients should not rely on any specific structure of the returned value.
While that's nice in theory, Hibernate Validator (the Jakarta Beans Validation reference implementation) has pretty much used the same implementation for as long as I've been using it probably going back to 2007-ish. The javadocs for jakarta.validation.Path#toString then say:
Instead they should iterate through the path nodes and obtain any required information by calling the methods on Path. Node and its sub-types.
Again, while nice in theory this is tedious at best, and quite annoying at worst. It seems like the spec should define a standardized way to represent a property path, but it doesn't. And I am tired of always writing violation.getPropertyPath().toString() so I'm going to add this method, with the possible issues in the implementation note. I know for a fact that if Hibernate Validator ever changes the Path#toString method in any significant way, a lot of code will probably break or start working in unexpected ways. I have seen many projects calling Path#toString to get a decent representation, usually for reporting errors. YOLO.
This is purely a convenience method that does:
No, it's not much but it saves boilerplate. In addition, if the actual implementation ever does change, this method's implementation could also be changed to work the way it has for literally all the years I've been using Jakarta Bean Validation (and Java Bean Validation before it moved to Jakarta). In other words, code that uses this new method instead of
Path#toStringdirectly would not need to change in the (unlikely) event that the implementation changes, because we can simply update the implementation inKiwiConstraintViolations, and all code using our implementation keeps working once the kiwi dependency version is updated.We will add all the potential problems with using this to the javadoc as an implementation note, specifically this:
While that's nice in theory, Hibernate Validator (the Jakarta Beans Validation reference implementation) has pretty much used the same implementation for as long as I've been using it probably going back to 2007-ish. The javadocs for
jakarta.validation.Path#toStringthen say:Again, while nice in theory this is tedious at best, and quite annoying at worst. It seems like the spec should define a standardized way to represent a property path, but it doesn't. And I am tired of always writing
violation.getPropertyPath().toString()so I'm going to add this method, with the possible issues in the implementation note. I know for a fact that if Hibernate Validator ever changes thePath#toStringmethod in any significant way, a lot of code will probably break or start working in unexpected ways. I have seen many projects callingPath#toStringto get a decent representation, usually for reporting errors. YOLO.