<div dir="ltr">Two typical use cases:<div><br></div><div>// 1. Sentinel</div><div>Duration min = Duration.MAX;</div><div>for (var foo : something()) {</div><div>  if (foo.duration().compareTo(min) < 0) {</div><div>    min = foo.duration();</div><div>  }</div><div>}</div><div><br></div><div>// 2. "Forever"</div><div>void frob(Optional<Duration> optionalTimeout) {</div><div>  Duration timeout = optionalTimeout.orElse(Duration.MAX);</div><div>  Instant start = Instant.now();</div><div>  boolean done = false;</div><div>  while (!done && startTime.until(Instant.now()).compareTo(timeout) < 0) {...}</div><div>}</div><div><br></div><div>The second case illustrates why this is potentially a bit delicate. You better not write this:</div><div><br></div><div><div>void frob(Optional<Duration> optionalTimeout) {</div><div>  Duration timeout = optionalTimeout.orElse(Duration.MAX);</div><div>  Instant deadline = Instant.now().plus(timeout); // oops</div><div>  boolean done = false;</div><div>  while (!done && Instant.now().isBefore(deadline)) {...}</div><div>}</div></div><div><br></div><div>Like Kevin, I am skeptical about Duration.MIN. If it means the most negative Duration, that is just Duration.MAX.negated(); and if it means the smallest positive Duration, that is just Duration.ofNanos(1).</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 3 Sept 2025 at 18:32, Roger Riggs <<a href="mailto:roger.riggs@oracle.com">roger.riggs@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    Hi,<br>
    <br>
    I'd be interested in the range of use cases for Duration.MAX or MIN.<br>
    <br>
    But for deadlines, I think the code should compute the deadline from
    a Duration of its choice based on the use.<br>
    Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that
    ignores information about the particular use that is relevant. Its
    just sloppy code that doesn't bother to express how long is long
    enough to meet operational parameters.<br>
    <br>
    YMMV, Roger<br>
    <br>
    <div>On 9/3/25 8:21 PM, Kurt Alfred Kluever
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Duration.MIN is a whole 'nother bag of worms,
        because Durations are signed (they can be positive or
        negative...or zero). Internally we also have Durations.MIN, but
        it's not public ... and along with it, I left myself a helpful
        note about naming:
        <div><br>
        </div>
        <div>  /** The minimum supported {@code Duration}, approximately
          -292 billion years. */<br>
            // Note: before making this constant public, consider that
          "MIN" might not be a great name (not<br>
            //       everyone knows that Durations can be negative!).<br>
            static final Duration MIN =
          Duration.ofSeconds(Long.MIN_VALUE);</div>
        <div><br>
        </div>
        <div>This reminds me of Double.MIN_VALUE (which is the smallest
          _positive_ double value) --- we've seen Double.MIN_VALUE
          misused so much that we introduced Doubles.MIN_POSITIVE_VALUE
          as a more descriptive alias. A large percent of
          Double.MIN_VALUE users actually want the smallest possible
          negative value, aka -Double.MAX_VALUE.</div>
        <div><br>
        </div>
        <div>If we introduce Duration.MIN, I hope it would not be
          Duration.ofNanos(1), but
          rather Duration.ofSeconds(Long.MIN_VALUE).</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Sep 3, 2025 at 7:59 PM
          ecki <<a href="mailto:ecki@zusammenkunft.net" target="_blank">ecki@zusammenkunft.net</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div>
            <div>If you ask me, I don’t find it very useful, It won’t
              work for arithmetrics, even the APIs would have a hard
              time using it (how do you express the deadline) and APIs
              with a timeout parameter do have a good reason for it,
              better pick “possible” values for better self healing and
              unstuck of systems. In fact I would err on the smaller
              side in combination with expecting spurious wakeups. </div>
            <div dir="ltr"><br>
            </div>
            <div dir="ltr" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt">BTW,
              when you introduce MIN as well, maybe also think about min
              precision, min delta or such. Will it always be 1 nano?</div>
            <div id="m_3477822427307783068m_4262163696471033019ms-outlook-mobile-body-separator-line" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt" dir="ltr">
              <div dir="ltr" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt"><br>
              </div>
            </div>
            <div style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt" id="m_3477822427307783068m_4262163696471033019ms-outlook-mobile-signature"><span style="font-family:Aptos;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">Gruß,</span>
              <div dir="ltr" style="text-align:left;text-indent:0px;background-color:rgb(255,255,255);font-family:Aptos;font-size:12pt;color:rgb(0,0,0)">Bernd</div>
              <div dir="ltr" style="text-align:left;text-indent:0px;background-color:rgb(255,255,255);font-family:Aptos;font-size:12pt;color:rgb(0,0,0)">-- </div>
              <div style="font-family:Aptos;font-size:12pt;color:rgb(0,0,0)"><span style="background-color:rgb(255,255,255)"><a href="https://bernd.eckenfels.net" target="_blank">https://bernd.eckenfels.net</a></span></div>
            </div>
            <div id="m_3477822427307783068m_4262163696471033019mail-editor-reference-message-container">
              <hr style="display:inline-block;width:98%">
              <div id="m_3477822427307783068m_4262163696471033019divRplyFwdMsg" dir="ltr"><span style="font-family:Calibri,sans-serif"><b>Von:</b> core-libs-dev
                  <<a href="mailto:core-libs-dev-retn@openjdk.org" target="_blank">core-libs-dev-retn@openjdk.org</a>>
                  im Auftrag von Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com" target="_blank">pavel.rappo@gmail.com</a>><br>
                  <b>Gesendet:</b> Donnerstag, September 4, 2025 12:41
                  AM<br>
                  <b>An:</b> Kurt Alfred Kluever <<a href="mailto:kak@google.com" target="_blank">kak@google.com</a>><br>
                  <b>Cc:</b> Stephen Colebourne <<a href="mailto:scolebourne@joda.org" target="_blank">scolebourne@joda.org</a>>;
                  core-libs-dev <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>><br>
                  <b>Betreff:</b> Re: Duration.MAX_VALUE</span>
                <div style="font-family:Calibri,sans-serif"> </div>
              </div>
              This is useful; thanks. It would be good to see more of
              your data.
              <br>
              <br>
              My use case is also duration which practically means
              **forever**. I
              <br>
              pass it to methods that accept timeouts, and expect these
              methods to
              <br>
              correctly interpret it.
              <br>
              <br>
              One example of a practical interpretation is
              <br>
              java.util.concurrent.TimeUnit.convert(Duration). This
              method never
              <br>
              overflows; instead, it caps at Long.MAX_VALUE nanoseconds,
              which is
              <br>
              roughly 292 years.
              <br>
              <br>
              Would I be okay, if the proposed duration didn't reflect
              **forever**
              <br>
              but instead reflected **long enough**? I think so. But it
              still
              <br>
              somehow feels wrong to make it less than maximum
              representable value.
              <br>
              <br>
              Personally, I'm not interested in calendar arithmetic,
              that is, in
              <br>
              adding or subtracting durations. Others might be, and
              that's okay and
              <br>
              needs to be factored in. For better or worse, java.time
              made a choice
              <br>
              to be unforgiving in regard to overflow and is very
              upfront about it.
              <br>
              It's not only proposed Duration.MAX. The same thing
              happens if you try
              <br>
              this
              <br>
              <br>
              Instant.MAX.toEpochMilli()
              <br>
              <br>
              I guess my point is that doing calendar arithmetic on an
              unknown value
              <br>
              is probably wrong. Doing it on a known huge/edge-case
              value is surely
              <br>
              wrong. So back to your data. I would be interested to see
              what
              <br>
              triggers overflows for your Durations.MAX.
              <br>
              <br>
              On Wed, Sep 3, 2025 at 8:45 PM Kurt Alfred Kluever <<a href="mailto:kak@google.com" target="_blank">kak@google.com</a>>
              wrote:
              <br>
              >
              <br>
              > Hi all,
              <br>
              >
              <br>
              > Internally at Google, we've had a Durations.MAX
              constant exposed for the past 7 years. It now has about
              700 usages across our depot, which I can try to categorize
              (at a future date).
              <br>
              >
              <br>
              > While I haven't performed that analysis yet, I think
              exposing this constant was a bit of a mistake. People seem
              to want to use MAX to mean "forever" (often in regards to
              an RPC deadline). This works fine as long as every single
              layer that touches the deadline is very careful about
              overflow. The only reasonable thing you can do with MAX is
              compareTo() and equals(). Attempting to do any simple math
              operation (e.g., now+deadline) is going to explode.
              Additionally, decomposing Duration.MAX explodes for any
              sub-second precision (e.g., toMillis()).
              <br>
              >
              <br>
              > As we dug into this, another proposal came up which
              was something like Durations.VERY_LONG. This duration
              would be longer than any reasonable finite duration but
              not long enough to cause an overflow when added to any
              reasonable time. E.g., a million years would probably
              satisfy both criteria. This would mean math operations and
              decompositions won't explode (well, microseconds and
              nanoseconds still would), and it could safely be used as a
              relative timeout.
              <br>
              >
              <br>
              > As I mentioned above, I'd be happy to try to
              categorize a sample of our 700 existing usages if folks
              think that would be useful for this proposal.
              <br>
              >
              <br>
              > Thanks,
              <br>
              >
              <br>
              > -Kurt Alfred Kluever (on behalf of Google's Java and
              Kotlin Ecosystem team)
              <br>
              >
              <br>
              > On Wed, Sep 3, 2025 at 1:53 PM Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com" target="_blank">pavel.rappo@gmail.com</a>>
              wrote:
              <br>
              >>
              <br>
              >> If I understood you correctly, you think we
              should also add
              <br>
              >> Duration.MIN. If so, what use case do you
              envision for it? Or we add
              <br>
              >> if purely for symmetry with Instant?
              <br>
              >>
              <br>
              >> On Wed, Sep 3, 2025 at 6:43 PM Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com" target="_blank">pavel.rappo@gmail.com</a>>
              wrote:
              <br>
              >> >
              <br>
              >> > On Wed, Sep 3, 2025 at 6:06 PM Stephen
              Colebourne <<a href="mailto:scolebourne@joda.org" target="_blank">scolebourne@joda.org</a>>
              wrote:
              <br>
              >> > >
              <br>
              >> > > Hmm, yes. Not sure why that didn't get
              added in Java 8!
              <br>
              >> > > The constants would be MAX/MIN as per
              classes like Instant.
              <br>
              >> > > Stephen
              <br>
              >> >
              <br>
              >> > I thought that naming could be tricky :) The
              public constant
              <br>
              >> > Duration.ZERO and the public method isZero()
              are already there.
              <br>
              >> > However, it does not preclude us from naming
              a new constant MAX.
              <br>
              >
              <br>
              >
              <br>
              >
              <br>
              > --
              <br>
              > kak
              <br>
              <br>
            </div>
          </div>
        </blockquote>
      </div>
      <div><br clear="all">
      </div>
      <div><br>
      </div>
      <span class="gmail_signature_prefix">-- </span><br>
      <div dir="ltr" class="gmail_signature"><font face="sans-serif"><span style="line-height:19px">kak</span></font></div>
    </blockquote>
    <br>
  </div>

</blockquote></div>