On Tue, 12 May 2026 10:37:12 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). > > Per Minborg has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains three additional > commits since the last revision: > > - Merge branch 'master' into rfe-list-remove-at-index > - Add @apiNote > - Add List::removeAtIndex Thank you for reaching out and checking with the Kotlin team! We really appreciate you keeping Kotlin interoperability in mind. Here is our perspective on the proposed options: The `removeAt` option: This is our preferred choice because it perfectly aligns with Kotlin's existing `MutableList.removeAt(index: Int)`. However, there is one critical condition: it must not be declared as final because otherwise, it will introduce a severe breaking change for Kotlin. Currently, Kotlin's `removeAt` is abstract and overridden by many standard and user-defined collections. A final method with the same signature in the Java interface would break binary compatibility for existing Kotlin code. If it remains non-final, we'll likely integrate it seamlessly. Currently, when some class implements a `kotlin.collections.MutableList` with `removeAt`, we actually generate the method named "removeAt" at the resulting class file, but also a final bridge `remove(int)` which delegates to the former. The `removeAtIndex` option: If making the method non-final is not an option, or if you'd prefer `removeAtIndex` (or any other name that doesn't clash with existing Kotlin signatures), we expect no problems with it, too. Though, we'll likely hide it preserving `removeAt` as a default option to use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31064#issuecomment-4487736869
