Comment From: philwebb
This shouldn't be necessary, at least if the javadoc is to be believed:
The string representation of the expected value for the properties. If not specified, the property must not be equal to {@code false}.
@quaff Have you found this isn't the case?
Comment From: quaff
This shouldn't be necessary, at least if the javadoc is to be believed:
The string representation of the expected value for the properties. If not specified, the property must not be equal to {@code false}.
@quaff Have you found this isn't the case?
~~I guess many people would not read this javadoc, they would change true to false instead of removing it by intuition.~~
~~What if people really want some property to match explicit false?~~
However, I think it should keep consistency since other *.enabled conditions are restricted to havingValue="true".
Comment From: wilkinsona
This has the potential to be a breaking change. As such, I'm not sure it's worth making. If it is, it would have to go in 3.5 at the earliest. If we do decide to make a change like this we may want to consider some options for avoiding the re-introduction of the problem.
Comment From: philwebb
Thanks for the PR @quaff. Given the number of these that we have, I'm tempted to introduce some dedicated annotations to help with the consistency. I've opened #43704 and got an initial prototype. I'd like the team to review the changes before we merge.
Thanks for triggering the review.