👌 David reacted via Gmail <https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>
On Tue, May 12, 2026, 5:37 AM Per-Ake Minborg <[email protected]> wrote: > Changing language features is definitely out of scope for this issue. One > thing to keep in mind is how methods can be manually resolved in case there > are *several* interface methods with the same name from a plurality of > implemented interfaces. Imagine the interfaces Foo and Bar both having a > final bazz() method ... > > Coming back to the name, I agree that removeAt would be a better choice > in a vacuum scenario. I've taken a look at a large number of libraries, and > it seems that usage of this name is mostly connected to Kotlin's > https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.collections/-abstract-mutable-list/#50165078%2FFunctions%2F1935454986 > and > some other similar Kotlin classes. The method mentioned is not "open", so > it might not be a problem for that particular. However, > https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.collections/-array-deque/ > declares > an open "removeAt" method. It is possible that we could add a new default > method, and the aforementioned could continue to work anyhow. > > Here are some other random examples: > cc.unitmesh:unit-eval:jar:all:0.1.7 > <https://jpg-data.us.oracle.com/artifactory/remote-repos/cc/unitmesh/unit-eval/0.1.7/> > public method in org.intellij.markdown.lexer.Stack implements > java.util.List.removeAt(int) > ai.tock:tock-bot-admin-server:jar:shaded:19.9.0 > <https://jpg-data.us.oracle.com/artifactory/remote-repos/ai/tock/tock-bot-admin-server/19.9.0/> > public method in com.beust.klaxon.JsonArray implements > java.util.List.removeAt(int) > > br.com.gamemods:nbt-manipulator:jar:3.1.0 > <https://jpg-data.us.oracle.com/artifactory/remote-repos/br/com/gamemods/nbt-manipulator/3.1.0/> > public method in br.com.gamemods.nbtmanipulator.NbtList$subList$1 > implements java.util.List.removeAt(int) > br.com.gamemods:nbt-manipulator:jar:3.1.0 > <https://jpg-data.us.oracle.com/artifactory/remote-repos/br/com/gamemods/nbt-manipulator/3.1.0/> > public method in br.com.gamemods.nbtmanipulator.NbtList implements > java.util.List.removeAt(int) > > Seems they emanate from Kotlin, but I have not checked. In total, I came > across over 4,000 usages of "removeAt" and zero usages of "removeAtIndex". > > Best, Per > > > > > > ------------------------------ > *From:* David Alayachew <[email protected]> > *Sent:* Tuesday, May 12, 2026 9:06 AM > *To:* [email protected] <[email protected]> > *Cc:* Archie L. Cobbs <[email protected]>; core-libs-dev < > [email protected]> > *Subject:* Re: [External] : Re: RFR: 8384062: Add a new method > List::removeAtIndex to avoid overload confusion > > Rémi, I am talking about introducing a new language feature. As in, give > interfaces the ability to define a method like so. > > @FunctionalInterface > public BlahInterface { > int blahImpl(); > final int blahUsefulDerivedMethod() {/* do something with blahImpl() > */} > } > > Adding default feels like a needless signifier, but at this point, I am > bikeshedding. > > On Tue, May 12, 2026 at 1:33 AM <[email protected]> wrote: > > > > > > > ------------------------------ > > > > *From: *"David Alayachew" <[email protected]> > > *To: *"Remi Forax" <[email protected]> > > *Cc: *"Archie L. Cobbs" <[email protected]>, "core-libs-dev" < > > [email protected]> > > *Sent: *Tuesday, May 12, 2026 3:21:17 AM > > *Subject: *Re: [External] : Re: RFR: 8384062: Add a new method > > List::removeAtIndex to avoid overload confusion > > > > Well, it would be better to just make it a final method in that case. No > > point for the default. > > > > > > We are trying to add a method to an existing interface hence the > "default" > > and > > we are trying to avoid that method to be overridden hence the "final". > > > > regards, > > Rémi > > > > > > On Mon, May 11, 2026 at 6:51 PM Remi Forax <[email protected]> wrote: > > > >> ----- Original Message ----- > >> > From: "Archie L. Cobbs" <[email protected]> > >> > To: "core-libs-dev" <[email protected]> > >> > Sent: Monday, May 11, 2026 8:04:08 PM > >> > Subject: Re: RFR: 8384062: Add a new method List::removeAtIndex to > >> avoid overload confusion > >> > >> > On Thu, 7 May 2026 06:45:36 GMT, Per Minborg <[email protected]> > >> wrote: > >> > > >> >> This PR proposes to add a new `default` method `List::removeAtIndex`. > >> >> > >> >> There are two overloads of the method `List::remove`, and if the list > >> is of type > >> >> `List<Integer>`, the overload resolution could pick a surprising > >> variant. > >> >> > >> >> Hence, it is better to add a separate method that removes an element > >> based on > >> >> its index. > >> >> > >> >> It is proposed that the `E remove(int index)` method is _not_ > >> `@Deprecated`. > >> >> Instead, we add verbiage to promote the new method over the old one. > >> >> > >> >> --------- > >> >> - [X] I confirm that I make this contribution in accordance with the > >> [OpenJDK > >> >> Interim AI Policy](https://openjdk.org/legal/ai). > >> > > >> > I sympathize with this change: `remove` is a textbook example of "bad > >> > overloading". > >> > > >> > I also definitely sympathize with Remi's concern: we have two > >> > identically-behaving methods where one is the most correct one to > >> invoke while > >> > the other is the most correct one to override. That's not ideal! We'd > >> be happy > >> > if API-clients pretty much *forgot* `remove(int)` existed, but when > >> they go to > >> > extend `AbstractList` we want them to suddenly remember. > >> > > >> > I don't think there's a fix for this (barring extremely weird ideas). > >> > >> Do you classify "default final" methods to say: you can use it but you > >> can not override it, as a weird idea ? > >> > >> regards, > >> Rémi > >> > >> > > >> > ------------- > >> > > >> > PR Comment: > >> https://git.openjdk.org/jdk/pull/31064#issuecomment-4423405317 > >> > > > > >
