# \[Feature Contribution Request\] @Compare constraint
**URL:** https://discourse.hibernate.org/t/feature-contribution-request-compare-constraint/12236
**Category:** Hibernate Validator
**Created:** [May 10, 2026, 5:33pm UTC](https://discourse.hibernate.org/t/feature-contribution-request-compare-constraint/12236 "2026-05-10T17:33:27Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@danielpederzini](https://discourse.hibernate.org/u/danielpederzini)
#### Post date: [May 10, 2026, 5:33pm UTC](https://discourse.hibernate.org/t/feature-contribution-request-compare-constraint/12236/1 "2026-05-10T17:33:27Z")
Hi everyone,
I’d like to contribute a small new constraint to Hibernate Validator and wanted to get feedback before starting implementation.
The idea is a minimal `@Compare` class-level constraint for common cross-field validation cases such as:
- startDate \< endDate
- min \<= max
- password == confirmPassword
Example:
```auto
@Compare(
left = "startDate",
right = "endDate",
operator = Compare.Operator.LT
)
```
The MVP scope would intentionally stay very small:
- class-level only,
- two property paths,
- comparison operators,
- only naturally comparable values,
- validation skipped if either side is null,
- no expression language, parsing, coercion, or custom comparators.
Would maintainers be open to something like this?
If the direction makes sense, I’d be happy to work on an implementation and tests.
---
### Author:  [@beikov](https://discourse.hibernate.org/u/beikov)
#### Post date: [May 11, 2026, 12:18pm UTC](https://discourse.hibernate.org/t/feature-contribution-request-compare-constraint/12236/2 "2026-05-11T12:18:58Z")
IMO, if we add property names as strings, we could just as well use an EL constraint e.g. `@ExpressionValid("startDate < endDate")`, but that’s just my 2 cents.
---
### Author:  [@yrodiere](https://discourse.hibernate.org/u/yrodiere)
#### Post date: [May 12, 2026, 3:55pm UTC](https://discourse.hibernate.org/t/feature-contribution-request-compare-constraint/12236/3 "2026-05-12T15:55:06Z")
@mbekhta may want to chime in 🙂
---
### Author:  [@mbekhta](https://discourse.hibernate.org/u/mbekhta)
#### Post date: [May 13, 2026, 8:23am UTC](https://discourse.hibernate.org/t/feature-contribution-request-compare-constraint/12236/4 "2026-05-13T08:23:32Z")
hey 👋
thanks for reaching out! In general, yes, we are happy to include reusable constraints in Hibernate Validator.
About this specific constraint:
- if we want to give a constraint access to more than one attribute, it has to be a class-level constraint. Just wanted to clarify this, as your suggestion for the MVP can be interpreted that in the next iterations, we could make it work on a field or getter 🙂
- we stay away from using reflection inside the constraints’ `isValid` calls. If we provide just two string paths, it means we will need to look up the fields through reflection on each `isValid` call (we cannot be sure what exact type we are getting as an arg to the `isValid`). Have you considered having an extractor as part of the constraint? Something like:
```auto
interface @Compare {
Operator operator();
Class operands();
// other usual atttributes: message/groups/payload ...
}
interface OperandsExtractor {
T left();
T right();
default boolean extractAndCheck(T instance, Operator operator) {
...
}
}
and then having something like:
@Compare(
left = "startDate",
right = "endDate",
operands = MySpecificTypeWithStartEndDateOperandsExtractor.class,
operator = Compare.Operator.LT
)
```
- To Christian’s point, there’s already a `@ScriptAssert` constraint that allows writing simple scripts and put such constraints on the class level ( [Hibernate Validator 9.1.0.Final - Jakarta Validation Reference Implementation: Reference Guide](https://docs.hibernate.org/stable/validator/reference/en-US/html_single/#validator-defineconstraints-hv-constraints) ):
>