> From: "Per-Ake Minborg" <[email protected]>
> To: "David Alayachew" <[email protected]>, "Remi Forax"
> <[email protected]>
> Cc: "Archie L. Cobbs" <[email protected]>, "core-libs-dev"
> <[email protected]>
> Sent: Tuesday, May 12, 2026 11:37:25 AM
> Subject: Re: [External] : Re: RFR: 8384062: Add a new method
> List::removeAtIndex
> to avoid overload confusion
> 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 ...
will work exactly the same way as with inheritance, when you have a final
method which is overriden by another one
class A {
final void m() { ... }
}
class B extends A {
final void m() { ... }
}
> Best, Per
Rémi
> 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 |
> >> >> 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 ]
