IMO the version bump is warranted/I'd select option 2 (although if it's not too early for me I don't see these options as being mutually exclusive).
Matt On Fri, Sep 8, 2023, 7:46 AM Alex Herbert <alex.d.herb...@gmail.com> wrote: > JDK 21 has added these methods to java.util.List: > > default public void addFirst(E o) > default public void addLast(E o) > > These are source incompatible with Commons Collections AbstractLinkedList: > > public boolean addFirst(E o) > public boolean addLast(E o) > > This affects AbstractLinkedList and any list that extends it > (CursorableLinkedList and NodeCachingLinkedList). > > This issue was identified by Julian Reschke (see [1, 2]) due to use of > code that extends AbstractLinkedList in Apache Jackrabbit. > > The source incompatibility means that collections, or any project that > extends these List classes, cannot be compiled with Java 21. Class > files compiled with Java < 21 are runtime compatible with Java 21. > > A performance test (on one machine) shows that NodeCachingLinkedList > may no longer offer any performance gain over the base implementation. > The NodeCachingLinkedList differs in that it reuses nodes rather than > allowing garbage collection. Subject to further performance testing, > this implementation can be deprecated. > > CursorableLinkedList provides functionality not in the JDK LinkedList. > This is to allow concurrent changes to the list with list methods and > iterator methods, or multiple iterators, for the lifetime of all > iterators. In contrast JDK LinkedList only allows modification to the > list via the (single) iterator during the lifetime of the iterator. > > The problem then becomes how to support AbstractLinkedList and > CursorableLinkedList. Currently collections4 will not be source > compatible with JDK 21. Any downstream project that extends these > classes will not be source compatible with JDK 21. > > Possible solutions: > > 1. Duplicate AbstractLinkedList (and possibly CursorableLinkedList) in > collections4 and update the methods signatures to be compatible in the > duplicate. > > This solution allows collections4 to be compiled with JDK 8, 11, 17. > It cannot be compiled with 21. Any downstream project can extend the > duplicate class and be compiled under Java 21 (assuming all references > to incompatible classes are removed). > > 2. Bump collections major version to 5 and fix the incompatibility. > > Note that collections 4.4 was released in Jul 2019. This option could > perform one last release of collections 4 to release all fixes and > changes, then proceed to collections 5 for the development branch. > > I am unfamiliar with the entire collections codebase and the clean-up > work required for a major revision bump. Note the new bloomfilter > package is as yet unreleased. So choosing this option provides the > ability to release a 5-beta to receive community feedback on the > bloomfilter API before an official release. > > Any other options are welcomed for discussion. > > Alex > > [1] https://lists.apache.org/thread/lnrzdv348q8g64dlno6xq84wb49vbc2c > [2] https://issues.apache.org/jira/browse/COLLECTIONS-842 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
