Sorry to send as follow up, those "to summarize" sentence is a question, not a statement. Sorry for possible confusion
On Thu, Jun 20, 2024, 00:12 Olexandr Rotan <rotanolexandr...@gmail.com> wrote: > I am aware of ThreeTen-Extra. The issue with this library is that it > lacks native transition to java.time types, java.time hierarchy is closed > and therefore there is no in-all-ways complete way to integrate it in a > project without seams all over the place. > > The issue with ranges and comparables is the fact that it is impossible to > implement multiple interfaces with different type parameters. This leads to > an issue, that, for example, Range<BigDecimal> cant be used against > BigInteger, Float, Long etc etc. This is why, I think, this idea in current > Java is inherently bad. > > So, to summarize, the main reason why there is no such types in java.time > is the fact that there just were tasks with higher priorities at the > moment. If so, I might do some research and draft some APIs myself and > present it to the Java team to determine whether it is ok or not to > continue development in this direction or not. > > > > On Wed, Jun 19, 2024 at 11:29 PM Stephen Colebourne <scolebou...@joda.org> > wrote: > >> There are a variety of ways that a range of the timeline can be defined. >> And some would argue that Java should have a general purpose Range class to >> cover all Comparable classes rather than a few specific ones for Java time. >> >> Ultimately, Java time chose to avoid the issues by not addressing the >> design space. There were plenty of other things to tackle at the time. >> >> BTW, see ThreeTen-Extra for some range and interval classes. >> >> Stephen >> >> >> >> On Wed, 19 Jun 2024, 20:44 Olexandr Rotan, <rotanolexandr...@gmail.com> >> wrote: >> >>> Greetings to the Java community. I have a question regarding the design >>> of java,time package. >>> >>> Commercial Java developers deal with time periods all the time with >>> different validations regarding intersection of periods, big data >>> processing, entity auditing etc etc. And it is surprising for everyone to >>> look into java.time for the first time and find out that there is no start >>> and end aware span data types at all! >>> >>> There is no rocket science in implementing such data types yourself, >>> that's for sure. However, as always, there are hidden spikes in these >>> waters.To use these types in JPA entities, you would have to write a custom >>> converter to familiar for database type, which ties project tightly to >>> database, which is contrary to what JPA was intended for . To use it in >>> auditing. one would have to write a custom auditor as no framework or >>> library knows about our custom data type. Same goes for big data >>> processing: no library or framework would support processing series of your >>> custom data type, at least unless you provide some adapter using library >>> mechanisms, if those exist at all. This rant could go on and on, but the >>> points are: >>> >>> 1) Lack of standardization for such data types leads to obstacles on >>> each step of development: constant writing of adapters, converters and blah >>> blah blah. Each of those serves as a space to make mistakes. One-two easy >>> implementations are not likely to be the source of errors, but the more a >>> project grows, the more dependencies it acquires, the more it is likely to >>> fall for some subtle specific feature of some library and spend hours or >>> even days debugging. >>> 2) One could rightfully argue that for small projects or microservice >>> projects with no shared codebase and different team for each service, this >>> whole mess I described above is overengineering. Seriously, not everyone >>> would want to go through all of that for one-two usages of class in the >>> domain layer of the project, and, moreover, not everyone should. However, >>> leaving it be "as is" is a screaming source of data inconsistencies, as it >>> is now responsibility of developer (or even worse, user) to keep in mind >>> the requirement to update all fields, that combined form that start- and >>> end-aware period (like start date/datetime and Period/Duration as common >>> way to emulate such thing) >>> >>> So, the question is: was it a conscious decision to omit such types back >>> in the day when java.time was designed, or is it a blindspot created by >>> deadlines/lack of resources/something else? >>> >>> Would appreciate anything some of you have to share on this topic. >>> >>> Best regards >>> >>
