java.time.Duration not present before SDK 26

Unable to use Mockito 3.1.7+ with Android on lower SDK devices.

Reason:

• https://github.com/mockito/mockito/issues/1815
• https://github.com/mockito/mockito/pull/1818

https://developer.android.com/reference/java/time/Duration <-- This was not added to Android until SDK 26.

https://developer.android.com/about/dashboards <-- here are some distribution stats. Most noticeably, this would impact testing for 70% of the market and is not ideal.

java.lang.NoClassDefFoundError: java.time.Duration
at org.mockito.Mockito.timeout(Mockito.java:2856)

[TimvdLippe]

I’d rather revert #1845, and instead introduces compatibility verification modes for pre Java 8 users.

Yeah I would like to recommit java.time.Duration, but would like to solve the problem of compatibility first. Since it is unlikely anyone used this method in the short period (<1 week) it was unavailable, I think the overall impact has been minimal. Given that the value is minimal, but would break the majority of Android users, I think reverting is the correct choice.

We might be able to add the API in a separate class and exclude it in mockito-android? The more prominent problem is that Android has not supported Java 8 features for a long time, which is now a problem.

[TimvdLippe]

I dont have time to provide a full comment (1AM here), but will provide one tomorrow.

For now: please accept my apology for those who used the new Duration API and were impacted by the revert. This has been an unfortunate change that broke a lot of existing Android users. Given the widespread usage of Mockito in the Android community and thus the large impact of the breaking change by relying on java.time.Duration, reverting felt like the least intrusive option. Yes, this would again break users who used the new api, but my assumption was that the amount of users that eagerly upgraded to the new api would be minimal, compared to existing users.

However, we do need to resolve this issue at large, as we should not hold back improvements on Mockito itself, because a different ecosystem is/was lacking behind. For this, I wanted to provide myself and the other core maintainers some more time to make a decision. That’s why I reverted the PR in question, to allow us to make a sensible and thoughtful decision.

I will do a full write-up tomorrow and also notify the Android folks at Google of this issue. Hopefully they can figure out a solution that would not hold libraries like Mockito (but I imagine a lot of other libraries as well) back.

I apologize for any inconvenience caused. Thank you for your understanding. I will comment further tomorrow.