java.time lacks start and end aware period data types

2024-06-19 Thread Olexandr Rotan
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

Re: java.time lacks start and end aware period data types

2024-06-19 Thread Olexandr Rotan
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 Olexa

Re: java.time lacks start and end aware period data types

2024-06-19 Thread Olexandr Rotan
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 wrote: > I am aware of ThreeTen-Extra. The issue with this library is that it > lacks native transition to

Enumerated streams

2024-05-07 Thread Olexandr Rotan
I have created some drafts of the EnumeratedStream API. But firstly, I have noticed that we have not formalized problems we are solving with them. Moreover, during the implementation process, I have discovered that there are possibly a much wider range of applications for those streams. Instead of

Re: RFR: 8305457: Implement java.io.IO [v3]

2024-05-08 Thread Olexandr Rotan
Has it been considered to add a readKey() method to IO class? In my experience, it is pretty commonly used by beginners when they write things like console games (snake, catcher game etc.). I am aware there is System.in.read() method, but since we decided to promote some methods to separate methods

Re: RFR: 8330465: Stable Values and Collections (Internal) [v16]

2024-05-16 Thread Olexandr Rotan
Is it possible to make stable values and collections Serializable? I see various applications for this feature in entity classes as a way to preserve immutability of entity fields and at the same time not break current JPA specifications. It is a *very* common task in commercial development. Curren

Re: Streams, parallelization, and OOME.

2024-10-19 Thread Olexandr Rotan
Hi David. I am not a core libs team but I guess I can have some clues :). It is hard to tell without the code, but I assume that there are a few layers to it. 1. Stalling. I would assume it is caused mostly by GC pauses taking too long (forever) if GC does not have any computational powers to run

Re: Range API

2024-09-23 Thread Olexandr Rotan
as addressed this same problem; their approach worth reviewing: > https://github.com/google/guava/wiki/RangesExplained Thanks. I will look into it for references. To my shame, I haven't looked into guava when designing the API, so this will be really useful. Best regards On Mon, Sep 23,

Re: Range API

2024-09-23 Thread Olexandr Rotan
shape pretty heavily on the date time libraries. Nevertheless, as you might see, API is type-agnostic, and one of the goals is to make ranges specializable for different types (although this would require additional research) Best regards On Mon, Sep 23, 2024 at 9:10 PM Olexandr Rotan wrote

Re: Range API

2024-09-22 Thread Olexandr Rotan
ng). > > Your API is unsafe, you can not have a method that creates a Range[] in > a safe way, the combination of erasure + array covariant is nasty (at least > until we have a way to create a read-only arrays). > > regards, > Rémi > > -- > >

Re: Range API

2024-09-23 Thread Olexandr Rotan
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 > wrote: > > >

Re: Range API

2024-09-26 Thread Olexandr Rotan
e is useful > because the exact track length may not be known. The optionality of the end > time > is not represented in the type system. > > Having said that, I’m not sure that a general abstract interface would be > useful for this example. > > On Sep 24, 2024, at 2:13 AM, O

Re: Range API

2024-09-26 Thread Olexandr Rotan
s. So that's a big > project. > > Still, I think investigating use cases involving libraries that work > intensively with ranges like this would likely yield useful information for > what a Range type would want to provide. > > HTH, > -Brian > > > > > >

Re: Does API for transformation of class files in Class-FIle API solves the same problem as code generationg annotation processors?

2024-09-18 Thread Olexandr Rotan
file > transformation start valid and end with a valid class file format. I think > this is the principal difference here. > > Regards, Chen > -- > *From:* core-libs-dev on behalf of > Olexandr Rotan > *Sent:* Tuesday, September 17, 2024 5:49 PM > *To:

Re: New candidate JEP: 485: Stream Gatherers

2024-09-18 Thread Olexandr Rotan
Is in-built gatherers list finalized? I was thinking that Gatherers::uniqueBy(Function) could be very popular among stream users, although it is fairly easy to implement yourself (as well as bunch of currently in-built ones though) On Tue, Sep 3, 2024, 00:59 David Alayachew wrote: > Thanks. Glad

Re: Range API

2024-09-24 Thread Olexandr Rotan
. range instanceof UnboundedEndRange && !(range instanceof UnboundedStartRange). Would appreciate any feedback. Best regards On Tue, Sep 24, 2024 at 12:02 AM Olexandr Rotan wrote: > But do those two use cases really need an abstraction? Is there really >> value in a Range interf

Does API for transformation of class files in Class-FIle API solves the same problem as code generationg annotation processors?

2024-09-17 Thread Olexandr Rotan
Hello there. I am writing to address the overlap between class file transformation using the ClassFile API and the work done by code-generating annotation processors, and whether they ultimately solve the same problem. Annotations such as @Async and @Transactional in popular frameworks are good ex

Re: Does API for transformation of class files in Class-FIle API solves the same problem as code generationg annotation processors?

2024-09-17 Thread Olexandr Rotan
Gruß > Bernd > -- > https://bernd.eckenfels.net > > ------ > *From:* core-libs-dev on behalf of > Olexandr Rotan > *Sent:* Tuesday, September 17, 2024 9:16 PM > *To:* core-libs-dev@openjdk.org > *Subject:* Does API for transformation of class files in Class-FIle API &

Re: Does API for transformation of class files in Class-FIle API solves the same problem as code generationg annotation processors?

2024-09-17 Thread Olexandr Rotan
Sorry for followup letter, just mentioned that I wrote that annotations CAN change the semantics, while I meant CANNOT. With this typo letter makes little to none sense, so correction is important On Tue, Sep 17, 2024, 22:51 Olexandr Rotan wrote: > When I said that bytecode modification

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v7]

2024-10-24 Thread Olexandr Rotan
Hi. Just wanted to express my gratitude to everyone who has been working on this and virtual threads as a whole. I am a big fan of this technology and seeing largest issue go away makes me incredibly happy. Thanks for loom team and everyone else who took part in this great innovation (instead of tu

Re: JEP 473: Proposal for new built-in gatherer `indexed`

2024-12-05 Thread Olexandr Rotan
Hi. There has been a proposal from me (that Chen mentioned), approximately half a year ago. At the time I have insisted on creating stream sub interface, and even got a working prototype for sequential streams, but there have been such a huge complexity blowup in parallisation that I have just deci

Re: Deprecate Double.MIN_VALUE?

2024-12-04 Thread Olexandr Rotan
To add one more voice, not particularly with Java, but I have made the same issue with js Number.MIN_VALUE a bunch of times (assuming it should work as java`s) Integer.MIN_VALUE. And also, would like to note that half-measures may not work as expected or to expected extent, for example you can ver

Re: Range API

2024-11-21 Thread Olexandr Rotan
hat's basically it for now, i will continue with investigation, maybe work will also give some food for though as with schedule, and when I feel like I have some common ground for all of the things I would want to see in the API, I will proceed with some sort of more mature API description

Re: Towards a JSON API for the JDK

2025-05-16 Thread Olexandr Rotan
I would like to add JSON comments from my perspective. I had a requirement of working with JSON in java multiple times during working on the university assignments recently. Since those are small, often one-time-open projects, I did not want (or, often, it was forbidden by assignment) to pull in w