JdkObsolete: Date.from(Instant)

[ben-manes]

Description of the problem / feature request:

warning: [JdkObsolete] Date has a bad API that leads to bugs; prefer java.time.Instant or LocalDate.
    .startAt(Date.from(startTime.toInstant()))
                      ^
    (see https://errorprone.info/bugpattern/JdkObsolete)

Feature requests: what underlying problem are you trying to solve with this feature?

When bridging with legacy, external libraries that use Date then a conversion is needed. While a benefit if those libraries were upgraded, some may be no longer actively maintained while still being useful.

It would be nice if Date.from did not trigger the warning, ideally suppressing it for the entire method block.

[ben-manes]

Similarly, Date.toInstant() is a warning and should be allowed.

[kluever]

Hey Ben,

As I'm sure you're aware, the Date API is really bug prone. Given that this is just a warning, I'm inclined to leave it (since Date isn't actually deprecated, this was our next best solution).

Just curious: what legacy API is forcing you to pass a Date?

[ben-manes]

Yep, I suppressed without much fuss :)

1. Quickbooks SDK has it in their generated jaxb code. There are 3rd party java.time adapters, but many older vendors don't provide that (though thankfully many offer their xsd / wsdl instead of a client).
2. Quartz is an old database-driven job scheduler that hasn't been actively developed since Java 6 or so. It was written prior to java.time and uses Dates for setting the start and end time, and to obtain the previous/next fire times when inspecting during a running job. While old and crusty, the library is still quite useful at low scale due to being easy to debug thanks to sql inspection of its core tables. It is a reasonable tool to grow out of when the product needs additional scalability, making it a good fit for an early stage startup where there is limited engineering time.

[boris-petrov]

This issue is somewhat related/duplicate of #1646.

[kluever]

I have a fix for this internally.