On Wed, 16 Apr 2025 00:01:18 GMT, Chen Liang wrote:
>> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and
>> `j.l.String.hashIsZero`. This means the VM can trust these fields to never
>> change which enables constant folding optimizations.
>>
>> This PR is tested in tier
- Original Message -
> From: "Stuart Marks"
> To: "Remi Forax" , "Ron Pressler"
> , "David Alayachew"
>
> Cc: "cay horstmann" , "core-libs-dev"
>
> Sent: Tuesday, April 15, 2025 12:10:54 AM
> Subject
- Original Message -
> From: "Ron Pressler"
> To: "Remi Forax"
> Cc: "cay horstmann" , "core-libs-dev"
> , "David Alayachew"
>
> Sent: Monday, April 14, 2025 11:46:25 PM
> Subject: Re: [External] : Re: My exper
- Original Message -
> From: "Ron Pressler"
> To: "cay horstmann"
> Cc: "core-libs-dev" , "David Alayachew"
>
> Sent: Monday, April 14, 2025 10:30:40 PM
> Subject: Re: My experience using Java to do CLI Scripting
> (moved from amber-dev)
>
> Hi.
>
> This does what you want (and could
> From: "Chen Liang"
> To: "Remi Forax" , "core-libs-dev"
>
> Sent: Thursday, April 10, 2025 8:16:39 PM
> Subject: Re: java.lang.String hashCode and @Stable ?
> Hi Remi,
> I think this is probably due to these fields being added too early -
> From: "Glavo"
> To: "Chen Liang"
> Cc: "Remi Forax" , "core-libs-dev"
>
> Sent: Thursday, April 10, 2025 8:54:57 PM
> Subject: Re: java.lang.String hashCode and @Stable ?
> Hi Chen,
> I think we can choose an arbitrary non-zer
On Thu, 10 Apr 2025 13:46:17 GMT, Per Minborg wrote:
> > > ```
> > >
> > > I will take a look at it.
> > > ```
> >
> >
> > As i said in another mail to core-lib this morning, it seems that the field
> > storing the hashcode of String is not marked with @stable. That's may be
> > the issue.
>
On Thu, 10 Apr 2025 12:51:43 GMT, Per Minborg wrote:
>
> ```
>
> I will take a look at it.
As i said in another mail to core-lib this morning, it seems that the field
storing the hashcode of String is not marked with @Stable. That's may be the
issue.
-
PR Comment: h
Question,
why String.hash and String.hashIsZero are not declared @Stable ?
regards,
Rémi
On Mon, 7 Apr 2025 16:00:41 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix typo in return type
Hello,
I do not know if you know but
On Mon, 7 Apr 2025 16:00:41 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix typo in return type
src/java.base/share/classes/java/lang
Hi Per,
last week, at JChateau, we had a one hour session about stable values, I've
build the JDK with this PR so we can discuss about it.
To present the API, i start from the double check locking, rewriting it to use
the StableValue API.
The main remark was that methods like orElseSet() or isS
Just a comment "en passant",
array, List or String in Java tend to use the from/to index convention instead
of the offset+length convention which is the convention for system calls
(read/write etc).
regards,
Rémi
> From: "Roger Riggs"
> To: "core-libs-dev"
> Sent: Monday, March 17, 2025 7
> From: "Viktor Klang"
> To: "Remi Forax" , "Fabian Meumertzheim"
>
> Cc: "Paul Sandoz" , "core-libs-dev"
>
> Sent: Wednesday, February 19, 2025 11:43:33 AM
> Subject: Re: [External] : Re: JDK-8072840: Presizing for Stream
> From: "Viktor Klang"
> To: "Paul Sandoz" , "Fabian Meumertzheim"
>
> Cc: "core-libs-dev"
> Sent: Thursday, February 13, 2025 11:30:59 PM
> Subject: Re: JDK-8072840: Presizing for Stream Collectors
> Indeed. I hope I didn't sound discouraging about the possibility to propagate
> the stream siz
> From: "Glavo"
> To: "core-libs-dev"
> Sent: Thursday, January 30, 2025 4:22:00 PM
> Subject: All classes in jdk.internal.random are not serializable
> Hi,
> My friend was migrating from Random to RandomGenerator, but he ran into a
> roadblock:
> Random is serializable, but those new implementa
> From: "Rafael Winterhalter"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "joe darcy"
>
> Sent: Tuesday, January 21, 2025 10:17:35 AM
> Subject: Re: Factory methods for SequencedSet and SequencedMap
> Wouldn't this already be po
Hello Jan,
what you are suggesting is not a backward compatible change.
If we add BigDecimal,valueOf(float), then a program recompiled with the new JDK
may change its behavior,
you can think that the new behavior is more "correct" that the current one, but
changing the behavior of existing pr
What can be done is to have Set.of()/Map.of() to delegate to
SequenceSet.of()/SequenceMap.of() so there is only one implementation at
runtime.
Also, technically, there is a way to change the return type in a binary
compatible way ... if union types are supported in the language.
In that case,
> From: "Rafael Winterhalter"
> To: "core-libs-dev"
> Sent: Thursday, January 16, 2025 8:13:17 AM
> Subject: Factory methods for SequencedSet and SequencedMap
> Hello,
Hello,
> I am happily taking SequencedSet and SequencedMap into use, but one
> inconvenience I encounter is the lack of facto
> From: "Viktor Klang"
> To: "Remi Forax" , "core-libs-dev"
>
> Sent: Thursday, January 2, 2025 12:26:08 PM
> Subject: Re: [External] : Gatherers.fold()
> Hi Rémi,
Happy new year,
>>Thinking a little more, i do not understand why fol
as first
parameter and not just a value given that the Gatherer is created with
ofSequential().
regards,
Rémi
[1] https://adventofcode.com/2024/day/19
[2] https://github.com/forax/advent-of-code-2024
that this optimization occurs, it means that you have to
generate the catch in the same method blob.
One solution i've explored (10 years ago) but not pursue is to generate a code
that the VM can de-optimize by itself without you having to generate a new code
[ https://github.com/forax/v
On Thu, 21 Nov 2024 17:21:07 GMT, Andrew Haley wrote:
> Test bug.
>
> Another bug caused by the result of `Math.abs()` being negative. I also tried
> `floorMod()`, which would have been cleaner, but it increased the runtime of
> this extremely time-sensitive benchmark.
Let say that the defini
- Original Message -
> From: "Andrey Turbanov"
> To: "core-libs-dev"
> Sent: Thursday, November 7, 2024 9:17:00 AM
> Subject: Can LinkedHashMap(accessOrder=true) be guarded by ReadWriteLock ?
> Hello.
> I've got a question about LinkedHashMap created with accessOrder=true flag.
> Usually
Hello,
I was discussing with a student, she was trying to use the SortedMap interface
but had trouble with tailMap() no being a strictly higher view from a key.
The solution was to use NavigableMap instead of SortedMap because it provides
more methods to get lower/higher subMap and entries from k
ooleanValue();
>>
>> I would go even a step further and use `value` instead of `booleanValue()`,
>> `intValue()` etc because there is no need to call a method to get the value.
>>
>>
>> if (obj instanceof Boolean b) {
>> return value == b
On Wed, 23 Oct 2024 02:06:20 GMT, Joe Darcy wrote:
> Noticed this refactoring opportunity while doing some other work in the area.
src/java.base/share/classes/java/lang/Boolean.java line 259:
> 257: public boolean equals(Object obj) {
> 258: if (obj instanceof Boolean b) {
> 259:
On Mon, 15 Jul 2024 11:33:30 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
On Mon, 15 Jul 2024 10:50:34 GMT, Jorn Vernee wrote:
> This is what I was thinking of as well. close() on a shared arena can be
> called by any thread, so it would be possible to have an executor service
> with 1-n threads that is dedicated to closing memory.
This delays both the closing of th
On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
> From: "Viktor Klang"
> To: "Remi Forax" , "core-libs-dev"
>
> Sent: Thursday, June 13, 2024 12:52:03 PM
> Subject: Re: [External] : Gatherer and primitive specialization
> Hi Rémi,
> Given that Collector has not been specialized since
Hello,
the Gatherer API do not provide primitive specialization while intermediate
methods like map(), flatMap() or mapMulti() do.
Unlike collectors where it is okay to not be specialized because most
collectors mutate a collection that is not specialized too,
gatherers can process/transform val
On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote:
> Extracting duplicate method references to static field reduce proxy class
> spinning and loading. In this case 2 less classes loaded when using
> `findAny()` on each type of stream.
For constant method reference, the solution is to use
> From: "-"
> To: "Remi Forax"
> Cc: "Chen Liang" , "core-libs-dev"
> , "hotspot-dev" ,
> "kulla-dev"
> Sent: Thursday, May 23, 2024 2:56:58 PM
> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes
- Original Message -
> From: "Chen Liang"
> To: "core-libs-dev" , "hotspot-dev"
> , kulla-...@openjdk.org
> Sent: Thursday, May 23, 2024 1:28:01 PM
> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes
> On Thu, 23 May 2024 03:28:30 GMT, Chen Liang wrote:
>
>> Please rev
On Wed, 15 May 2024 11:27:04 GMT, ExE Boss wrote:
>>> Maybe export this interface to `jdk.unsupported`?
>>
>> I don't we should do that. In general, we need jdk.unsupported to go away in
>> the long term. Also integrity of the platform depends on java.base being
>> very stingy and not exportin
On Tue, 7 May 2024 16:09:08 GMT, Pavel Rappo wrote:
>> I do not think the step to "standardise" a preview feature exists ? When a
>> preview feature becomes a released feature, the code is very lightly edited,
>> at least it this is my experience.
>>
>> You can change both readln and readLine
On Tue, 7 May 2024 11:00:52 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 74:
>>
>>> 72:
>>> 73: @Override
>>> 74: public String readln(String prompt) {
>>
>> this code can be simplified using an early return (and the body of the
>> tr
On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo wrote:
> Please review this PR which introduces the `java.io.IO` top-level class and
> three methods to `java.io.Console` for [Implicitly Declared Classes and
> Instance Main Methods (Third Preview)].
>
> This PR has been obtained as `git merge --sq
> From: "David Alayachew"
> To: "Remi Forax"
> Cc: "ІП-24 Олександр Ротань" , "core-libs-dev"
>
> Sent: Friday, April 19, 2024 11:02:12 PM
> Subject: Re: Addition of Predicate-based findIndex and findLastIndex methods
> to
>
Hello,
for me, it seems what you want is Collector on Stream which is able to
short-circuit,
so you can write
list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
and in reverse
list.reversed().stream().collect(Collectors.findFirst(s -> s.contains("o")))
Using a Stream here is
On Fri, 12 Apr 2024 14:53:01 GMT, Viktor Klang wrote:
>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that
>> it is both competitive performance-wise as well as improve correctness.
>>
>> Below is the performance of `Stream::flatMap` (for reference types):
>>
>> Before
On Fri, 12 Apr 2024 14:53:01 GMT, Viktor Klang wrote:
>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that
>> it is both competitive performance-wise as well as improve correctness.
>>
>> Below is the performance of `Stream::flatMap` (for reference types):
>>
>> Before
On Fri, 12 Apr 2024 14:53:01 GMT, Viktor Klang wrote:
>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that
>> it is both competitive performance-wise as well as improve correctness.
>>
>> Below is the performance of `Stream::flatMap` (for reference types):
>>
>> Before
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-noth
> From: "Viktor Klang"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "Paul Sandoz"
>
> Sent: Wednesday, January 24, 2024 2:45:15 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated
> As a (related) side-n
> From: "Viktor Klang"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "Paul Sandoz"
>
> Sent: Wednesday, January 24, 2024 2:34:11 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated
> Presuming that you mean mut
> From: "Viktor Klang"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "Paul Sandoz"
>
> Sent: Monday, January 22, 2024 10:06:27 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated
>> The flags are in s
> From: "Viktor Klang"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "Paul Sandoz"
>
> Sent: Monday, January 22, 2024 4:22:11 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated
> Hi Rémi,
Hello,
> For
> From: "Viktor Klang"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "Paul Sandoz"
>
> Sent: Thursday, January 18, 2024 5:14:38 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated
>> And for A.andThen(B)
> From: "Viktor Klang"
> To: "Remi Forax"
> Cc: "core-libs-dev"
> Sent: Wednesday, January 17, 2024 9:00:32 PM
> Subject: Re: Gatherer API : wildcards complaint
> Ah, now I see what you mean! Thank you \uD83D\uDC4D
> The reason for the
> From: "Viktor Klang"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "Paul Sandoz"
>
> Sent: Thursday, January 18, 2024 3:36:07 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated
> I suspect that it is a rather
> From: "Viktor Klang"
> To: "Remi Forax" , "core-libs-dev"
>
> Sent: Wednesday, January 17, 2024 8:48:07 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated
> Hi Rémi,
> You can find some of my benches here: [
> htt
> From: "Viktor Klang"
> To: "Remi Forax"
> Sent: Wednesday, January 17, 2024 6:01:38 PM
> Subject: Re: Seing a Collector as a Gatherer
> Hi Rémi,
> Yes, this was something I was hoping to get into the preview, but I wasn't
> sure
> where
> From: "Viktor Klang"
> To: "Remi Forax" , "core-libs-dev"
>
> Sent: Wednesday, January 17, 2024 5:49:01 PM
> Subject: Re: Gatherer API : wildcards complaint
> Hi Rémi,
> Thank you for the feedback—examples would be much appreciated
Hello,
I may have overlook that, but it seems there is no method to see a Collector as
a Gatherer.
A Gatherer is more general than a Collector and a Gatherer with a greedy
integrator that does not call Downstream.push in the intergator and only once
is the finisher is basicaly a Collector.
In
Hello,
this is a minor complaint but I do not see a raison to not getting this right.
Currently the Gatherer API does not use the wildcard correctly, which is not
fully an issue because there is "enough" wildcards that if you rely on the
inference, it will work.
The problem is that when you wri
this intermediate operation keep the size, which is important if the
terminal operation is toList() because if the size is known, toList() will
presize the List and avoid the creation of an intermediary ArrayList.
See
https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/
Hello,
i've played quite a lot with the Gatherer API and overall, i quite like how
things work conceptually.
But i think the public API can be improved.
First, the documentation is not fully clear that a Gatherer has 3
characteristics,
1/ Is it sequential or parallelizable (can be parallel is a
> From: "Viktor Klang"
> To: "David Alayachew" , "core-libs-dev"
>
> Sent: Wednesday, January 10, 2024 2:33:45 PM
> Subject: Re: Gatherers -- conditionalWindowFixed?
> Hi David!
> Apologies for the late reply, there's been lots of catching up to do after the
> holidays.
> >I'm really excited f
> From: "Remi Forax"
> To: "David Alayachew"
> Cc: "core-libs-dev"
> Sent: Wednesday, January 10, 2024 8:19:15 AM
> Subject: Re: Gatherers -- conditionalWindowFixed?
> Hello David,
> testing the gatherer api, I also wanted a "window&
Hello David,
testing the gatherer api, I also wanted a "window" operation as the one you are
describing.
My use cases is a text file with some sections containing items organized like
this
:section1
item1
item2
item3
:section2
item1
item2
...
For me the signature of such method, win
- Original Message -
> From: "Pavel Rappo"
> To: "Roger Riggs"
> Cc: "core-libs-dev"
> Sent: Tuesday, January 2, 2024 5:31:06 PM
> Subject: Re: Blessed modifier order does not include sealed/non-sealed
> Hi Roger,
>
> Happy New Year to you too!
>
> Although it's a _somewhat_ separate
- Original Message -
> From: "Pavel Rappo"
> To: "core-libs-dev"
> Sent: Tuesday, January 2, 2024 12:56:08 PM
> Subject: Blessed modifier order does not include sealed/non-sealed
> I couldn't find any prior discussions on this matter.
>
> I noticed that bin/blessed-modifier-order.sh has
On Tue, 19 Dec 2023 11:01:12 GMT, Hannes Greule wrote:
> Isn't Arrays.equals() used under the hood?
No, for arrays == is used
-
PR Comment: https://git.openjdk.org/jdk/pull/17143#issuecomment-1863374656
- Original Message -
> From: "Viktor Klang"
> To: "core-libs-dev"
> Sent: Tuesday, November 14, 2023 11:32:48 AM
> Subject: Re: RFR: 8319123: Implementation of JEP-461: Stream Gatherers
> (Preview) [v7]
> On Tue, 14 Nov 2023 09:48:13 GMT, Rémi F
On Tue, 14 Nov 2023 07:51:42 GMT, Viktor Klang wrote:
>> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Addressing last review feedback
Hello,
the relat
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/Gatherers.java line 64:
> 62: *needlessly
> 63: * 3. allows for more efficient composition and evaluation
> 64:
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/GathererOp.java line 232:
> 230: */
> 231: @SuppressWarnings("unchecked")
> 232: private GathererOp(Gatherer gat
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/GathererOp.java line 448:
> 446: private final long targetSize;
> 447: private final Hybrid leftPrede
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/GathererOp.java line 180:
> 178: finisher.accept(state, this);
> 179: sink.end();
> 180:
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/GathererOp.java line 95:
> 93: public void accept(X x) {
> 94: final var b = rightMost;
> 95:
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/GathererOp.java line 50:
> 48: */
> 49: final class GathererOp extends ReferencePipeline {
> 50: @SuppressWarnings("unch
On Wed, 8 Nov 2023 17:22:05 GMT, Rémi Forax wrote:
>> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
>
> src/java.base/share/classes/java/util/stream/Gatherer.java line 490:
>
>> 488: * more elements sent to it, {@code false
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/Gatherer.java line 444:
> 442: */
> 443: static Gatherer of(
> 444: Supplier initializer,
wildcards ar
On Wed, 8 Nov 2023 15:17:57 GMT, Viktor Klang wrote:
>> It's still possible to have a situation where PECS signature could be
>> useful, and I don't see any downsides. A user may want to reuse the same
>> static integrator instead of creating several identical lambdas just because
>> the targe
On Sun, 5 Nov 2023 16:18:52 GMT, Tagir F. Valeev wrote:
>> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
>
> src/java.base/share/classes/java/util/stream/Gatherer.java line 330:
>
>> 328: static Gatherer ofSequential(
>> 329: Integrator integrator,
>> 330:
On Wed, 8 Nov 2023 17:10:05 GMT, Tagir F. Valeev wrote:
>> Has this proven to be a problem for things like
>> [Collectors.mapping(…)](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Collectors.html#mapping(java.util.function.Function,java.util.stream.Collector))
>>
On Tue, 31 Oct 2023 13:19:30 GMT, Viktor Klang wrote:
>> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
>
> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 242:
>
>> 240: }
>> 241:
>> 242: // Terminal evaluation methods
>
> This is needed i
On Fri, 3 Nov 2023 16:51:34 GMT, Viktor Klang wrote:
>> Since stream facilities are package-private, we can just use no access
>> modifier and remove all new `protected` access modifier (on methods, fields,
>> constructors) in this PR.
>
> @liach We could do that, yet I'm not sure that is stric
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223:
> 221: * consumed
> 222: */
> 223: protected AbstractPipeline(AbstractPipeline
On Fri, 3 Nov 2023 16:43:30 GMT, Jan Lahoda wrote:
>> Consider code like:
>>
>> void test(Object o) {
>> switch (o) {
>> case X1 -> {}
>> case X2 -> {}
>> ...(about 100 cases)
>> ```
>>
>> javac will compile the switch into a switch whose selector is an indy
>> invocation
On Fri, 3 Nov 2023 15:32:34 GMT, Jan Lahoda wrote:
>> Consider code like:
>>
>> void test(Object o) {
>> switch (o) {
>> case X1 -> {}
>> case X2 -> {}
>> ...(about 100 cases)
>> ```
>>
>> javac will compile the switch into a switch whose selector is an indy
>> invocation
On Fri, 3 Nov 2023 15:29:05 GMT, Jan Lahoda wrote:
> Thanks for all the comments so far - I think I've either reflected them, or
> wrote a comment to each of them. Please let me know if there's something
> else, or if I've forgotten something.
You idea to use an extra array is clever. Using an
On Fri, 3 Nov 2023 15:32:34 GMT, Jan Lahoda wrote:
>> Consider code like:
>>
>> void test(Object o) {
>> switch (o) {
>> case X1 -> {}
>> case X2 -> {}
>> ...(about 100 cases)
>> ```
>>
>> javac will compile the switch into a switch whose selector is an indy
>> invocation
On Fri, 3 Nov 2023 15:32:34 GMT, Jan Lahoda wrote:
>> Consider code like:
>>
>> void test(Object o) {
>> switch (o) {
>> case X1 -> {}
>> case X2 -> {}
>> ...(about 100 cases)
>> ```
>>
>> javac will compile the switch into a switch whose selector is an indy
>> invocation
On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote:
> Consider code like:
>
> void test(Object o) {
> switch (o) {
> case X1 -> {}
> case X2 -> {}
> ...(about 100 cases)
> ```
>
> javac will compile the switch into a switch whose selector is an indy
> invocation to `SwitchB
On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote:
> Consider code like:
>
> void test(Object o) {
> switch (o) {
> case X1 -> {}
> case X2 -> {}
> ...(about 100 cases)
> ```
>
> javac will compile the switch into a switch whose selector is an indy
> invocation to `SwitchB
On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote:
> Consider code like:
>
> void test(Object o) {
> switch (o) {
> case X1 -> {}
> case X2 -> {}
> ...(about 100 cases)
> ```
>
> javac will compile the switch into a switch whose selector is an indy
> invocation to `SwitchB
On Thu, 2 Nov 2023 12:24:31 GMT, Jim Laskey wrote:
>> Uhmm. In the spec I see implicit classes named here:
>>
>>
>> For reference, the following constructs are declared implicitly in source
>> code, but are not marked as mandated because only formal parameters and
>> modules can be so marked
> From: "Viktor Klang"
> To: "Tyler Kindy"
> Cc: "core-libs-dev"
> Sent: Monday, October 30, 2023 10:59:48 PM
> Subject: Re: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
> That's also a good point, and I've heard from multiple sources that sometimes
> you want to make sure tha
On Fri, 8 Sep 2023 18:55:29 GMT, altrisi wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Fix additional formating issue
>> - Don't use polymorphism and reformat code
>
> With the recent changes this ends up just
rare in Java because usually classes that share
>> implementation details are in the same package (or in the same nestmate
>> nest).
>
> @forax Note that HashMap uses a similar subclassing idiom for the iterators
> of the keySet, values, and entrySet collections in or
On Thu, 7 Sep 2023 11:48:51 GMT, Per Minborg wrote:
> This PR proposes to slightly improve some iterators of `AbstractMap`:
>
> * Code reuse
> * A field declared `final`
> * Add missing `@Override` annotations
Hello,
In Java, sharing code may have a runtime cost (or not) depending on the shape
On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote:
>> 8268829: Provide an optimized way to walk the stack with Class object only
>>
>> `StackWalker::walk` creates one `StackFrame` per frame and the current
>> implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per fr
On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote:
>> 8268829: Provide an optimized way to walk the stack with Class object only
>>
>> `StackWalker::walk` creates one `StackFrame` per frame and the current
>> implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per fr
On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote:
>> 8268829: Provide an optimized way to walk the stack with Class object only
>>
>> `StackWalker::walk` creates one `StackFrame` per frame and the current
>> implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per fr
Sorry, you can not do that.
Optional is a value based class [1] (see the javadoc) so the class has to be
final.
And more generally, the API of a classes of OpenJDK will not change based on
some stylistic issue, OOP or not.
regards,
Rémi Forax
[1]
https://docs.oracle.com/en/java/javase
1 - 100 of 208 matches
Mail list logo
