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
>>
>
>
