Range API

Tue Sep 24 09:13:27 UTC 2024

As part of the redesigning  process , I am researching whether or not there
are use cases that require asserting that the range is exactly
half-bounded. This is important because I plan to switch to
BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags and runtime
checks: Here is what I gathered for now.

- *Date/Time Handling (Historical or Forecast Data)*: When dealing with
events that started at a specific time but have no known end (e.g.,
open-ended employment contracts or ongoing subscriptions)
- *Stream Processing (Real-time Event Streams)*: In real-time systems, you
might process data that has a start time but no defined end, such as
monitoring a live video feed or logging system. The range is bounded at the
start and unbounded at the end as more data will continuously arrive.
- *Data Pagination (Fetch Until Condition)*: When implementing pagination,
sometimes you might want to fetch items starting from a specific index up
to an unbounded limit (e.g., fetching all items after a certain point until
memory runs out or a condition is met).
- *Auditing and Monitoring*: In systems where audit trails or logging data
should capture all events after a certain point (bounded start) with no
foreseeable end (unbounded end), such as monitoring changes to records in a
database starting from a fixed timestamp.
- *Scientific or Statistical Ranges*: When modeling physical systems or
statistical ranges, you might want to capture measurements that begin at a
known threshold but theoretically have no upper or lower bound. For
example, recording temperature data starting at absolute zero and
increasing without any known upper limit.
- *Inventory or Resource Allocation*: Resource allocation policies, such as
those for virtual machines, may be based on known minimum allocation
thresholds but have flexible or unbounded resource caps, depending on
availability.

I am writing to ask whether anyone who worked with such systems could
confirm/deny that those are real use cases. If so, would it be satisfying
enough to assert one-way unboundness with instanceof checks, i.e. range
instanceof UnboundedEndRange && !(range instanceof UnboundedStartRange).
Would appreciate any feedback.

Best regards

On Tue, Sep 24, 2024 at 12:02 AM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> But do those two use cases really need an abstraction? Is there really
>> value in a Range interface?
>> Given the two classes above, which are IMO candidates for the JDK, they
>> work fine as isolated value types without a generalized abstraction.
>
>
> I see this a bit differently. In the examples you provided, there are
> basically no methods that would somehow indicate that Interval is something
> more than generic Range<Instant> besides toDuration(), and same goes for
> LocalDateRange. Therefore, I see generic ranges not as "abstracting"
> ranges, but rather adapting them for the general case. Range<Instant> and
> Interval are roughly identical, with differences easily coverable by few
> static methods.
>
> Similarly, I'm not sure what a Range value type would accomplish. Don't
>> get me wrong - if fully integrated into the language, with literals and
>> looping syntax there might be a case, but we are a long way from that.
>
>
> Well, every feature started somewhere. There is clearly a demand for range
> support, both numeric, chronological, and potentially many others. Amber is
> considering integrating ranges as patterns, so anyway internal
> representation will be needed.
>
> Sorry to be a bit down given the massive effort made here, but the harsh
>> truth is that I've yet to see a "Range" API that I like, and I especially
>> find mixing bounded/unbounded and inclusive/exclusive gets complicated and
>> unpleasant very fast.
>
>
> Your opinion is valuable too. I am not pushing on integrating this
> changes, PR mostly serves research purpose, and final form could (and most
> likely will) differ a lot from the current state of API.
>
> Ranges are indeed not easy to model, they always could use some
> syntax-level dsl. If the demand shows to be high enough, this may also be
> the subject of discussion. Nevertheless, ranges in general are really
> popular. Chronological ranges are one of the most common business object
> attributes, numeric ranges could be useful for research and visualization
> etc. For now, I will continue on evolving the API, to see if it is possible
> to arrive at the point where the API is smooth enough to become a candidate.
>
> PS: Regarding chronological ranges specifically, this was my motivation in
> the first place (
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125271.html)..I
> was initially a fan of nominal date and time ranges, but when I started
> modeling the API, I discovered that, surprisingly, there is little to none
> tdatetime-specific operations that could be made on ranges. Therefore, I
> came to the conclusion that ranges generalize too well to miss on this.
> Some people here argue it is too strict to oblige range elements to be
> comparable, let alone chronological types.
>
> On Mon, Sep 23, 2024 at 11:24 PM Stephen Colebourne <scolebourne at joda.org>
> wrote:
>
>> I've always found the generic concept of a "range" tricky to express
>> in a sensible API. When authoring Joda-Time and java.time I avoided it
>> as much as possible.
>>
>> ThreeTen-Extra has two classes - Interval and LocalDateRange - which
>> cover the two main use cases.
>>
>> https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/package-summary.html
>>
>> But do those two use cases really need an abstraction? Is there really
>> value in a Range interface?
>> Given the two classes above, which are IMO candidates for the JDK,
>> they work fine as isolated value types without a generalized
>> abstraction.
>>
>> Similarly, I'm not sure what a Range value type would accomplish.
>> Don't get me wrong - if fully integrated into the language, with
>> literals and looping syntax there might be a case, but we are a long
>> way from that. (ie. some language designs are built around ranges as a
>> first class concept, but Java isn't, and I have doubts that it would
>> be a good fit to try and pivot that way now.) In particular, I
>> struggle with a generified Range type - it just "feels wrong" to me.
>>
>> Sorry to be a bit down given the massive effort made here, but the
>> harsh truth is that I've yet to see a "Range" API that I like, and I
>> especially find mixing bounded/unbounded and inclusive/exclusive gets
>> complicated and unpleasant very fast. And that is before you consider
>> discrete versus continuous.
>> Stephen
>>
>>
>> On Sun, 22 Sept 2024 at 20:02, Olexandr Rotan
>> <rotanolexandr842 at gmail.com> wrote:
>> >
>> > Hello everyone! I am writing here today to invite everyone to
>> participate in the discussion regarding the Range APi proposal I have made
>> into JDK. Here is the pull request link:
>> https://github.com/openjdk/jdk/pull/21122, and PR text:
>> >
>> > This pull request describes the methods of the Range<T> interface. The
>> Range<T> interface represents a bounded or unbounded range. (From now on,
>> range, span and interval are used interchangeably, but docs only use
>> "range")
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/6f792510/attachment.htm>