Documentation Preview

Compared to main:
This changeset changes 0 violations,
introduces 772 new violations, 0 new errors and 0 new configuration errors,
removes 0 violations, 25 errors and 8 configuration errors.

Regression Tester Report

(comment created at 2025-07-12 20:17:41+00:00 for 591af28)

@adangel Is there anything I still need to do, if I want to have this merged?

I'm not attached to the names, so if you have better suggestions...

About the multiple warnings in one file: Each of them is valid on their own. Is there a downside to having a rule trigger multiple times in a file?

About the multiple warnings in one file: Each of them is valid on their own. Is there a downside to having a rule trigger multiple times in a file?

There is no problem with multiple violations. We only should take care, that we report each problem only once (like you said: each should be a valid violation on its own), to avoid unnecessary violations.

Since this rule is about discouraging the use of Calendar - the fix would be to use e.g. ZonedDateTime, which makes all the violations go away in the code block at once. So, calling the constructor of GregorianCalendar and then operating on the instance with Calendar constants can be considered as only one violation - "here you are still using java.util.Calendar". We maybe could avoid this by flagging only constructor calls and variable/field declarations of this type. Which may lead to some false negatives, but the rule would not report 20 violations, when there are only 5 places where the calendar is actually used (all the other violations could be considered consequential violations).

Something like this?

I personally would prefer multiple violations over false negatives. But I think this won't miss much, so I'm fine with this version.