> 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 < [ mailto:[email protected] | > [email protected] ] > wrote: >> ----- Original Message ----- >> > From: "Archie L. Cobbs" < [ mailto:[email protected] | [email protected] ] > >>> To: "core-libs-dev" < [ mailto:[email protected] | >> > [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 < [ >>> mailto:[email protected] | >> > [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 | >> >> 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 | >> > https://git.openjdk.org/jdk/pull/31064#issuecomment-4423405317 ]
