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
