PreferJavaTimeOverload:OFF

[iamdanfox]

Before this PR

A bunch of our repos internally use custom assertj libraries (e.g. the c-j-r-api test-utils, audit logging test utils, safe-logging test-utils), which triggers this wonky error-prone behaviour: google/error-prone#1435

I even saw this pretty non-sensical message internally in sls-logging:

/Volumes/git/sls-logging/sls-logging-log4j/src/test/java/com/palantir/sls/logging/log4j/Log4jSlsLoggingSubscribersMetricsTest.java:143: warning: [PreferJavaTimeOverload] If the numeric primitive (eventLengthHistogram.getCount()) represents a Instant, please call assertThat(Instant) instead.
                    .untilAsserted(() -> assertThat(eventLengthHistogram.getCount()).isOne());

After this PR

==COMMIT_MSG==
The PreferJavaTimeOverload error-prone check is turned off to avoid false positives
==COMMIT_MSG==

Possible downsides?

[changelog-app]

Generate changelog in changelog/@unreleased

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

The PreferJavaTimeOverload error-prone check is turned off as it produces noisy false positives relating to custom AssertJ utilities.

Check the box to generate changelog(s)

• Generate changelog entry

[iamdanfox]

So I think the checkExplicitlyDisabled function will actually prevent these auto-fixes being applied until we get rid of the explicit CheckSeverity.OFF setting... I'm kinda OK with just leaving this here so that when we re-enable the check it will start patching.

[carterkozak]

👍

[svc-autorelease]

Released 2.40.1