Duration.MAX_VALUE

[Naoto Sato]

Filed an RFE: https://bugs.openjdk.org/browse/JDK-8366829

Naoto

On 9/3/25 10:06 AM, Stephen Colebourne wrote:
> Hmm, yes. Not sure why that didn't get added in Java 8!
> The constants would be MAX/MIN as per classes like Instant.
> Stephen
> 
> 
> On Wed, 3 Sept 2025 at 12:50, Pavel Rappo <pavel.rappo at gmail.com> wrote:
>>
>> Couldn't recall or quickly find if this was asked before.
>>
>> I come across this quite often: there doesn’t seem to be a readily
>> available maximum value for java.time.Duration -- a value that
>> represents the longest possible duration.
>>
>> I assume there are plenty of homegrown constants out in the wild
>> addressing this. Don’t get me wrong: it’s not hard to create one. The
>> issue, in my experience, is that it takes time and sometimes
>> experimentation.
>>
>> Unless one reads the Javadoc carefully, it’s not obvious that the
>> maximum duration can be constructed as follows:
>>
>>      Duration.of(Long.MAX_VALUE, 999_999_999);
>>
>> Naturally, one might first try using IDE autocomplete. For example,
>> creating a Duration from Long.MAX_VALUE of a large unit -- millennia,
>> centuries, decades, etc. -- only to run into ArithmeticException. Only
>> when reaching seconds does it finally work:
>>
>>      Duration.ofSeconds(Long.MAX_VALUE);
>>
>> or
>>
>>      Duration.of(Long.MAX_VALUE, ChronoUnit.SECONDS);
>>
>> Of course, there’s no practical difference between
>> Duration.of(Long.MAX_VALUE, 999_999_999) and
>> Duration.ofSeconds(Long.MAX_VALUE). We’re talking about durations on
>> the order of 292 billion years, after all. The exact value isn’t the
>> problem. The problem is that the values are inconsistent, and arriving
>> to them is error-prone. Adding a constant to java.time.Duration would
>> simplify things.
>>
>> -Pavel