These questions necessitate runnable examples. Do you have any
On Thu, Jul 3, 2025, 10:37 AM Jige Yu wrote:
> Hi JDK Core Devs,
>
> I'm writing to you today with a question about the behavior of
> mapConcurrent() and its interaction with unchecked exceptions. I've been
> experimenting with the A
I can certainly agree that there might have been a better name than Period.
I like your suggestion, and I would even go further and suggest that
Interval would have been a better term.
But Period is certainly acceptable. It captures the meaning well enough --
a period of time between 2 events.
ht
How does it not model an interval?
Here is the official documentation.
*Obtains a Period consisting of the number of years, months, and days
between two dates.*
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/time/Period.html#between(java.time.LocalDate,java.time.LocalDate)
An
Heh, I forgot that my Javadoc was set to 21. Thank you for the correction.
On Mon, Jun 2, 2025, 11:58 PM Jaikiran Pai wrote:
> Hello David,
>
> On 03/06/25 5:17 am, David Alayachew wrote:
> > ...
> >
> > I would much prefer to just use varargs, and list them all
olve over and over.
rootPath.resolve("src", "main", "java");
And I am ignorant about performance, but maybe there is a performance
benefit to be gained here? It appears that I don't need to create multiple
instances of Path anymore.
Thank you for your time and consideration.
David Alayachew
rom:* core-libs-dev on behalf of David
> Alayachew
> *Sent:* Friday, May 23, 2025 10:28 AM
> *To:* Viktor Klang
> *Cc:* core-libs-dev
> *Subject:* Re: [External] : Could someone answer this question about
> Gatherers?
>
> Ty vm.
>
> You don't think this has any
sized. I'll open a separate Issue for
> that next week.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* core-libs-dev on behalf of
> Viktor Klang
> *Sent:* Friday, 23 Ma
answer that
question are people already on this mailing list.
Thank you for your time and help!
David Alayachew
Didn't Brian or one of the Amber folks say that we might (some time in the
near future) get a .match() method on streams, which can take in a pattern?
It's the pattern version of .map().
On Sat, Apr 26, 2025 at 3:13 PM Chen Liang wrote:
> Hi Nir, I think currently the most similar code pattern i
rgs.
>
> And there will be string templates, which will allow one to embed multiple
> values
> unobtrusively, so there's no need for varargs here. And a string templates
> should be
> directly usable from IO.println, so it'll come for "free".
>
> Thus I don
Sorry, forgot to link the thread.
https://old.reddit.com/r/java/comments/1j2pr78/
And here is the comment in question.
https://old.reddit.com/r/java/comments/1j2pr78/compact_source_files_and_instance_main_methods_jep/mfy9dof/
on
seems like a better fit.
Thank you for your time and thoughts.
David Alayachew
Hello Markus,
I already posted a response, but since you added more detail, I will adress
that detail too.
> So how to proceed? Stop all my work for many more months?
Address the criticisms (which you did), and knock on the door once or twice
if you get no responses.
But if after all of that, y
Hello Markus,
I am ignorant about the larger topic, so I will only respond to the
following point.
> Thank you, everybody. As no more comments arrived in the past eight
weeks, I assume that there is implicit agreement with my latest arguments
(see below), so next I will provide a PR to continue d
That's the missing link. Thanks Archie.
Man, I still don't get the decision-making in 1995 to make it not
overridable. It is what it is.
On Sat, Jan 18, 2025, 10:06 AM Archie Cobbs wrote:
> On Fri, Jan 17, 2025 at 7:50 PM David Alayachew
> wrote:
>
>> I guess my next
raised.
On Fri, Jan 17, 2025, 8:14 PM Joseph D. Darcy wrote:
>
> On 1/17/2025 5:00 PM, David Alayachew wrote:
>
> Thanks for the corrections folks. I was thinking from the perspective of
> LSP. I now see that there is the performance perspective to consider too.
>
> N
Set.of(...) and
> Map.of(...). As for megamorphism, I think the chance of encounter at a call
> site is similar, as Set12 and SetN from the Set interface are typically
> combined with HashMap. As for a possible SequencedSet12 and SequencedSetN,
> I think they would normally be seen wi
nd SetN from the Set interface are typically
> combined with HashMap. As for a possible SequencedSet12 and SequencedSetN,
> I think they would normally be seen with LinkedHashSet.
>
> Best regards, Rafael
>
> Am Fr., 17. Jan. 2025 um 00:36 Uhr schrieb David Alayachew <
> d
imit thing. You all know what I am
talking about.
Point is, both of these static factories were meant to be used on a small
number of entries. If it truly has just been not done until now, then the
bug database will confirm that easily.
When I get back, I can check myself.
On Thu, Jan 16, 2025, 6:2
I guess let me ask the obvious question.
Chesterton's fence -- why wasn't this done before? I refuse to believe that
this idea wasn't thought up years ago, which leads me to believe there was
a reason that it hasn't been done.
Is there any way we can look this up in the bug database or something?
> If it's one
of the expected ones, things will proceed normally.
There are expected segfaults in libjvm?
Sorry, I am 100% ignorant about this subject. I just wanted to know if that
was the intended meaning.
On Sun, Dec 8, 2024, 3:46 PM Kim Barrett wrote:
> On 12/8/24 1:56 PM, Davide Perini wr
://openjdk.org/jeps/277
>
> Most the incompatible step, actually removing the declaration in question,
> if it occurs at all, would only occur after a warning period.
>
> HTH,
>
> -Joe
> On 12/2/2024 6:24 PM, David Alayachew wrote:
>
> As a data point of one, we use all of
As a data point of one, we use all of the abovementioned constants
regularly for my day job. In total, we have maybe a couple thousand
instances of that constant being referenced. Ripping out wouldn't be too
painful as long as I was told exactly what the replacements were, but I
wouldn't be thrille
gt; tasks up first.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------
> *From:* David Alayachew
> *Sent:* Thursday, 21 November 2024 15:01
> *To:* Viktor Klang
> *Cc:* Rob Spoor ; core
{
"emoji": "👍",
"version": 1
}
come with trade-offs)
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* core-libs-dev on behalf of
> Viktor Klang
> *Sent:* Tuesday, 19 November 2024 13:19
> *To:* David Alayachew
In general though—short-circuiting in combination with parallelization
> requires a lot of tuning to make sure that the cost of processing more data
> doesn't overtake the benefit of "exiting early".
>
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Archite
/comments/1gukzhb/a_surprising_pain_point_regarding_parallel_java/
Ty vm!
On Thu, Nov 14, 2024 at 5:45 PM David Alayachew
wrote:
> Oh ok. So it truly is a toss-up depending on each implementation when and
> where this occurs.
>
> Ok, then as my final request, I think even informing the us
n that Stream is an interface).
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------
> *From:* David Alayachew
> *Sent:* Thursday, 14 November 2024 12:36
> *To:* Viktor Klang
> *Cc:*
wrote:
> The issue here is that the operation cannot advertise this, as it depends
> on the combination of operations.
>
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* core-l
value is ignored. With some more effort it's
> probably possible to capture any false return value and return that from
> the integrator, but I haven't tried that yet.
>
> * sorted. Obviously every element needs to be inspected.
>
>
> On 13/11/2024 00:37, David Alayac
ck to the source.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* David Alayachew
> *Sent:* Wednesday, 13 November 2024 00:37
> *To:* Viktor Klang
> *Cc:* core-libs-dev
> *Subject:* Re:
Apologies, I did not mean to add reduce(). Please ignore that part.
On Tue, Nov 12, 2024, 6:37 PM David Alayachew
wrote:
> Oh sure, I expect something like distinct() to pull everything. In order
> to know if something is distinct, you have to do some variant of "check
> against
unbounded streams can be processed.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* David Alayachew
> *Sent:* Tuesday, 12 November 2024 15:08
> *To:* Viktor Klang
> *Cc:* core-libs
r Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* David Alayachew
> *Sent:* Tuesday, 12 November 2024 01:53
> *To:* Viktor Klang
> *Cc:* core-libs-dev
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
gt; Software Architect, Java Platform Group
> Oracle
> --
> *From:* David Alayachew
> *Sent:* Monday, 11 November 2024 18:32
> *To:* Viktor Klang
> *Cc:* core-libs-dev
> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> fetching too many elem
t; .collect(forEach(eachList -> println(eachList.getFirst(;
>
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* core-libs-dev on behalf of David
> Alayachew
> *Sent:* Monday,
saying that the Gatherer is
trying to grab all available data before sending any of it downstream.
On Mon, Nov 11, 2024, 8:46 AM David Alayachew
wrote:
> Hello Core Libs Dev Team,
>
> I was trying out Gatherers for a project at work, and ran into a rather
> sad scenario.
>
> I
any way for me to be able to have the Gatherer NOT pull in
everything while still remaining parallel and unordered?
Thank you for your time and help.
David Alayachew
rmance of Stream::flatMap (for ref...
> github.com
>
>
>
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* core-libs-dev on behalf of David
> Alayachew
> *Sent:* Saturday,
But *not letting any of them through into the forEach loop.
On Sat, Oct 19, 2024, 9:36 AM David Alayachew
wrote:
> So to be clear, I added a logger to my BufferedReader. So I know for a
> fact that it is reading data.
>
> And as for the code, it is a very simple para
re this
> will work, but memory-mapped files is a common tool to deal with operations
> that cant fit into RAM.
>
> Regards
>
>
> On Sat, Oct 19, 2024 at 8:54 AM David Alayachew
> wrote:
>
>> Hello Core Libs Dev Team,
>>
>> I have a file that I am streamin
ave no idea.
Regardless, that's about where I gave up and went sequential, since the
clock was ticking.
But I still have a performance problem. How would one suggest going about
this in Java 8?
Thank you for your time and help.
David Alayachew
/10/2024 04:47, David Alayachew wrote:
> > Hello Core Libs Dev Team,
> >
> > Currently, java.io.SequenceInputStream only has 2 constructors -- one
> > that takes in 2 instances of InputStream, and another that takes in an
> > Enumeration of type InputStream.
> >
>
7;t explained
> either.
>
> If you do pick this up, I think it would be useful to find out what kind
> of usage the SequenceInputStream class sees in libraries and whether this
> new constructor is going to be helpful for such usages.
>
> -Jaikiran
> On 17/10/24 10:36 am,
Jaikiran Pai
wrote:
> Hello David,
>
> There's an enhancement request for this here
> https://bugs.openjdk.org/browse/JDK-8305947
>
> -Jaikiran
>
> On 17/10/24 9:17 am, David Alayachew wrote:
> > Hello Core Libs Dev Team,
> >
> > Currently, java.io.Seq
? I don't know if a list, an array, varargs, etc
makes more sense. But I would think a 3rd constructor would improve this
API.
Thank you for your time and help.
David Alayachew
)
>
> On Tue, Sep 3, 2024, 00:59 David Alayachew
> wrote:
>
>> Thanks. Glad to see this finally land. That slidingWindow and other
>> related functions are extremely powerful.
>>
>> On Mon, Sep 2, 2024 at 3:13 PM Mark Reinhold
>> wrote:
>>
>>&
Thanks. Glad to see this finally land. That slidingWindow and other related
functions are extremely powerful.
On Mon, Sep 2, 2024 at 3:13 PM Mark Reinhold
wrote:
> https://openjdk.org/jeps/485
>
> Summary: Enhance the Stream API to support custom intermediate
> operations. This will allow s
ance to try it out and share their experience.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> --
> *From:* David Alayachew
> *Sent:* Sunday, 4 August 2024 09:14
> *To:* core-libs-dev
> *Cc:* Remi F
4, 2024 at 3:14 AM David Alayachew
wrote:
> Hello Core Libs Dev Team,
>
> Apologies for the massive delay. I have been juggling many severe personal
> emergencies, and thus, did not have time or strength to follow up on the
> previous thread --
> https://mail.openjdk.org/piper
y findings, and why I think
this new windowBy function makes sense. Here is the link --
https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127293.html
Thank you for your time and patience!
David Alayachew
On Sun, Jan 28, 2024 at 1:54 AM David Alayachew
wrote:
> Thank you both for
t like making a
database view of a larger database table.
This is my experience using the windowBy Gatherer that Viktor Klang gave
me. Please let me know if there are any questions, comments, or concerns.
Thank you for your time, patience, and understanding!
David Alayachew
[1] = https://adventofcode.
On Wed, 8 May 2024 08:30:39 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request in
On Wed, 8 May 2024 08:30:39 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request in
Nope. We can see your message. You only subscribe if you want to follow
along with the general discussions that you are not explicitly invited to.
On Tue, May 21, 2024 at 7:14 PM wrote:
>
>
> This message is for information purposes only. It is not a recommendation,
> advice, offer or solicitati
Biggest use case is definitely when creating different histograms from the
same dataset. Our friends in sci-py land spend A LOT of time doing this.
Our R friends also use this frequently.
I can imagine this bag implementation would not just be good for
Collections, but would play well with the Col
I am in full support of this idea. I do also appreciate the functionality
of using a BiFunction on the map method instead of a normal
Function, R>.
As for the actual enumeration logic, my vote is that it should simply
enumerate as it arrives, with no context or care given to what came before
it. C
>
>> I am not insisting on anything, I just feel that if there is someone
>> (like me lol) who is willing to take on full development and integration
>> cycle, there aren't much reason to reject such enhancements.
>>
>> сб, 20 апр. 2024 г. в 23:31, David Alayach
Your Bag suggestion has been asked so frequently that there is an FAQ entry
in the official Java Docs.
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3
On Sat, Apr 20, 2024 at 4:25 PM ІП-24 Олександр Ротань <
rotan.olexa...@gmail.com> wrote:
gt; an aggregation of opinions of numbers of other programmers that I
> introduced to Java, especially switchers. Many of then feel those
> "wordiness" of Java and it repulses potential developers, especially when
> there is C# just by the corner. I think that Java has really s
t; approach. While I understand that performance is not as valuable as
> flexibility and clarity, it is still crucial, at least because of it being
> the main factor server maintenance cost after all.
>
> сб, 20 апр. 2024 г. в 00:32, David Alayachew :
>
>> It is not the goal of
on to use .withIndex().
list
.stream()
.withIndex()
.filter(WithIndex.filter(predicate))
.mapToIndex()
.findFirst()
.orElse(-1)
On Fri, Apr 19, 2024 at 5:47 PM wrote:
>
>
> --
>
> *From: *"David Alayachew"
> *To: *"Rem
-1 it would be more
> suitable to use OptionalInt instead, but I would like to hear community
> opinion about that.
>
> сб, 20 апр. 2024 г. в 00:02, David Alayachew :
>
>>
>> No Rémi, I don't think your idea is the right approach. You are working
>> on the wro
going out of order like this slows down the system and forces reviewers
to take extra steps that they wouldn't have to if you had followed protocol.
On Fri, Apr 19, 2024 at 5:02 PM David Alayachew
wrote:
>
> No Rémi, I don't think your idea is the right approach. You are workin
No Rémi, I don't think your idea is the right approach. You are working on
the wrong level of abstraction.
Many users ask requests like this all the time, and what you are suggesting
would be even more error-prone than the equivalent for loop or the IntStream
suggestion that the user above request
.
Any thoughts on this feature?
Thank you for your time and consideration!
David Alayachew
I actually plan to follow through on that email. I just can't right now
because of work emergencies. Literally as soon as those calm down, top of
my list is to give Viktor the lost of code examples where I am using the
windowBy Gatherer he gave me.
On Mon, Mar 25, 2024, 6:24 PM wrote:
> Hello,
>
pport for detecting resource
leaks?
On Sun, Mar 3, 2024 at 10:02 PM David Alayachew
wrote:
> And as a side note, I did some pretty in-depth research on the topic, and
> stumbled on this post on the lambda mailing list during Java 8's creation.
> I am adding it, as it seems to be
/2013-August/002195.html
On Sun, Mar 3, 2024 at 10:00 PM David Alayachew
wrote:
>
> Hello Amber Dev Team and Core Libs Dev Team,
>
> I am making my own implementation of java.util.stream.Stream that reads
> data from the internet lazily. It's basically
> java.nio.file.Files
a resource
unclosed because there are no compiler warnings or errors if I do so.
Are there any plans to make it easier to detect potential resource leaks?
Ideally with a compiler warning or error?
Thank you for your time and help!
David Alayachew
[1] = https://stackoverflow.com/questions/77959436
Thank you to Stuart, Michel, and Joe for taking care of closing my
enhancement and adding helpful comments, I appreciate it!
On Sun, Feb 11, 2024, 5:13 AM David Alayachew
wrote:
> Since I am abandoning this idea, could someone close my JBS ticket?
>
> And please link this message in
, 2024 at 5:10 AM David Alayachew
wrote:
> Hello,
>
> Thank you for your response!
>
> So, I had thought of that before posting this email, and mentally, I had
> hand-waved away the concern by saying that there were plenty of situations
> where equality would still be useful witho
On Sat, 27 Jan 2024 03:57:58 GMT, David Alayachew wrote:
> Adding a function to Objects in order to facilitate equality checking and
> enhance readability. You simply specify the 2 objects that you want to check
> for equality, and then provide the functions which will be used t
when I try again.
And I see the value of "socializing", as @Alan Bateman
put it. I had thought this idea through plenty,
but I can only see from my perspective.
Thank you all for your time and help!
David Alayachew
On Sun, Feb 11, 2024 at 3:26 AM Holo The Sage Wolf
wrote:
> How ben
in question -- any function that takes in T is fair game. This allows
flexibility, and lets developers keep their objects simple, thus
facilitating things like DOP.
Now, perhaps this makes more sense on the BiPredicate interface instead.
However, since this was more equality focused, I figured Objects was a
better fit.
Any thoughts?
Thank you all for your time and help!
David Alayachew
made for me, and I will post a new email thread either tomorrow or the day
after that shows my experience with it. My hope is that I can convince you
that this function absolutely is worth adding.
Thank you for your time and help!
David Alayachew
On Wed, Jan 10, 2024 at 2:29 PM Viktor Klang
wrote
On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew wrote:
>> Adding a function to Objects in order to facilitate equality checking and
>> enhance readability. You simply specify the 2 objects that you want to check
>> for equality, and then provide the functions which will
On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew wrote:
>> Adding a function to Objects in order to facilitate equality checking and
>> enhance readability. You simply specify the 2 objects that you want to check
>> for equality, and then provide the functions which will
On Sat, 27 Jan 2024 17:05:59 GMT, Chen Liang wrote:
> Your API is risky as well: it won't get a compile error if you add a new
> field but forgot to add that field to equality checks too. And since
> initialization happens in ``, your said error is quite easy to detect
> if this class is ever
On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew wrote:
>> Adding a function to Objects in order to facilitate equality checking and
>> enhance readability. You simply specify the 2 objects that you want to check
>> for equality, and then provide the functions which will
On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew wrote:
>> Adding a function to Objects in order to facilitate equality checking and
>> enhance readability. You simply specify the 2 objects that you want to check
>> for equality, and then provide the functions which will
On Sat, 27 Jan 2024 15:36:59 GMT, Chen Liang wrote:
>> David Alayachew has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rather than reiterating the precondition, let's explain why the method
>> failed
> Adding a function to Objects in order to facilitate equality checking and
> enhance readability. You simply specify the 2 objects that you want to check
> for equality, and then provide the functions which will be used to provide
> the values that we will check for equality.
Dav
> Adding a function to Objects in order to facilitate equality checking and
> enhance readability. You simply specify the 2 objects that you want to check
> for equality, and then provide the functions which will be used to provide
> the values that we will check for equality.
Dav
> Adding a function to Objects in order to facilitate equality checking and
> enhance readability. You simply specify the 2 objects that you want to check
> for equality, and then provide the functions which will be used to provide
> the values that we will check for equality.
Dav
> Adding a function to Objects in order to facilitate equality checking and
> enhance readability. You simply specify the 2 objects that you want to check
> for equality, and then provide the functions which will be used to provide
> the values that we will check for equality.
Dav
On Sat, 27 Jan 2024 04:21:02 GMT, David Alayachew wrote:
>> Adding a function to Objects in order to facilitate equality checking and
>> enhance readability. You simply specify the 2 objects that you want to check
>> for equality, and then provide the functions which will
On Sat, 27 Jan 2024 04:21:02 GMT, David Alayachew wrote:
>> Adding a function to Objects in order to facilitate equality checking and
>> enhance readability. You simply specify the 2 objects that you want to check
>> for equality, and then provide the functions which will
> Adding a function to Objects in order to facilitate equality checking and
> enhance readability. You simply specify the 2 objects that you want to check
> for equality, and then provide the functions which will be used to provide
> the values that we will check for equality.
Dav
Adding a function to Objects in order to facilitate equality checking and
enhance readability. You simply specify the 2 objects that you want to check
for equality, and then provide the functions which will be used to provide the
values that we will check for equality.
-
Commit mes
Hello Magnus,
Thank you for closing my bug! Terribly sorry to ask another favor, but
could you link the following link for traceability in the JBS submission?
https://mail.openjdk.org/pipermail/amber-dev/2024-January/008488.html
Thank you again for the time and help!
David Alayachew
On Mon
And this may also be better named as a split method instead of the long
conditionalWindowFixed.
On Wed, Jan 10, 2024 at 1:17 AM David Alayachew
wrote:
> Oh, I made a mistake. Let me try it again.
>
> If the predicate is true, add the element to the current list (create list
> pri
at 1:05 AM David Alayachew
wrote:
> Hello Core Libs Dev Team,
>
> I have been reading through JEP 461 (https://openjdk.org/jeps/461) about
> Gatherers, and I'm really excited for what this will enable for us.
>
> By far, the most important functionality that this API facil
son I think this is worth adding is because it facilitates a really
common use case. We may not want all windows to be the same size.
Is this something worth adding to the Gatherers API?
Thank you for your time and help!
David Alayachew
amber-...@openjdk.org
On Thu, Jan 4, 2024 at 8:29 PM Bradley Willcott
wrote:
> Hi there.
> I am sorry if this is 'off subject'. However, where do I go to propose a
> new java feature? And please be nice :-).
>
> Thanks,
> Brad.
>
Try and search up the idea before posting though. A lot of people have made
feature requests before you.
On Thu, Jan 4, 2024 at 8:40 PM David Alayachew
wrote:
> amber-...@openjdk.org
>
> On Thu, Jan 4, 2024 at 8:29 PM Bradley Willcott
> wrote:
>
>> Hi there.
>>
the abovementioned article --
https://inside.java/2023/12/15/switch-case-effect/#other-switch-tricks
Could someone help me close this on JBS? Or should it just not be closed at
all?
Here is a link to the JBS -- https://bugs.openjdk.org/browse/JDK-8319802
Thank you for your time and help!
David Alayac
est(input)
> ? trueFunction.apply(input)
> : falseFunction.apply(input)
> ;
>
> }
>
> }
On Thu, Nov 9, 2023 at 12:12 AM David Alayachew
wrote:
> It has been a month since I sent this proposal. Since no one has told me
> that this
It has been a month since I sent this proposal. Since no one has told me
that this is a terrible idea, I will submit this as an enhancement to JBS,
and once the ticket is made, start work on creating a pull request.
On Tue, Oct 3, 2023 at 3:13 AM David Alayachew
wrote:
> Whoops, bad imp
1 - 100 of 111 matches
Mail list logo
