[
https://issues.apache.org/jira/browse/COLLECTIONS-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762166#comment-17762166
]
Alex Herbert commented on COLLECTIONS-842:
------------------------------------------
{quote}Maybe just add a second variant?
{quote}
Can you expand on what you mean here?
If we stick to the premise of not breaking binary compatibility, there is no
point adding different methods for addFirst and addLast for current users. They
can continue to use the original methods which we will not remove.
I do not think there is a plan for collections5.
If a downstream user wishes for JDK 21 source compatibility in these classes,
and it is effectively a blocker then we could address that when it is raised.
(Q. Do you have a blocker use case?) Note that this issue could be easily fixed
using a forked repository allowing a locally compatible jar to be created and
used (but not distributed via Maven central). IIUC it would set a precedent for
Commons to officially support releases on two branches, so this would require
some traction from the community to be supported.
> AbstractLinkedList apparently incompatible with JDK 21's java.util.List
> -----------------------------------------------------------------------
>
> Key: COLLECTIONS-842
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-842
> Project: Commons Collections
> Issue Type: Bug
> Components: List
> Reporter: Julian Reschke
> Priority: Major
>
> ...it returns "boolean" in commons-collections4, but is void in JDK 21 (see
> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/util/List.html#addLast(E))
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
