Pushing a branch for adding the IndexedLinkedList.

[coderodde]

This PR contains:

1. IndexedLinkedList: the actual list implementation we try to propose for inclusion in Collections.
2. ExtendedTreeList: the subclass of TreeList used in JMH benchmarking.
3. The actual JMH benchmark (that supports our bold claim that ILL > TreeList)
4. A couple of unit test files for testing.

Limitations so far:

1. We cannot make our unit test files run.
2. Our IDE (NetBeans) introduced two configuration files that failed the assumption of having the license in them.

[garydgregory]

Hello @coderodde
PRs should not include IDE metadata. I've added these NetBean files to the /.gitignore file. If you rebase this PR on git master, these two files will be removed from the PR (but remain locally for you).

[garydgregory]

Please remove these edits.

[garydgregory]

Remove author and version tags. since tags are only needed for new public and protected elements under main.

[garydgregory]

Hello @coderodde
The build fails because the new tests don't cover all of the new code. To see the code coverage, you can run mvn clean verify site and look at the JaCoCo report in the generated report in target/site/jacoco/index.html

[coderodde]

Hello, @garydgregory

Are these correct instructions for rebasing the NetBeans related files:

https://chatgpt.com/s/t_693544c351308191a5467b6d20d0f856

?

[vlsi]

It would be great if the new data structure did not require pulling all the other commons-collections dependencies.
I am sure it is the right time to consider adding the new structure as a new (optional) module of commons-collections, so the users could select the bits they need.

[garydgregory]

Hello, @garydgregory

Are these correct instructions for rebasing the NetBeans related files:

https://chatgpt.com/s/t_693544c351308191a5467b6d20d0f856

?

Hello @coderodde

Thank you for your updates.

Unless you know git, you should go with a known and trusted source, for example:

• https://git-scm.com/book/en/v2/Git-Branching-Rebasing
• https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
• https://docs.gitlab.com/topics/git/git_rebase/

HTH

[garydgregory]

Hello @coderodde,

This class doesn't belong in main. Why is this needed at all?

[coderodde]

Hello @garydgregory ,

I had to roll ExtendedTreeList in order to provide such methods as getFirst() and friends for the actual JMH benchmark. Shall I remove it from the PR?

[garydgregory]

Hello @coderodde

Thank you for your quick reply.

I think I see what's happening here: java.util.LinkedList<E> implements Deque<E> but org.apache.commons.collections4.list.TreeList<E> doesn't. It looks like ExtendedTreeList implements Deque methods but doesn't actually implement the interface with an implements Deque<E> in the code. Then I see IndexedLinkedList implements Deque. So we have a bit of a mismatch.

So:

• It's good that IndexedLinkedList implements Deque<E>
• It's not good that ExtendedTreeList doesn't

If all of that makes sense and you agree, do you think that org.apache.commons.collections4.list.TreeList<E> should implement Deque<E> first, then ExtendedTreeList would become superflous.

If you agree, you can create a PR that causes org.apache.commons.collections4.list.TreeList<E> to implement Deque<E>, with tests 😉

Another wrinkle is that IndexedLinkedList doesn't fit in the JRE's collection framework by extending java.util.AbstractSequentialList<E> or java.util.AbstractList<E>. Is there a reason to not fit it in?

Thank. you!

[garydgregory]

No need for a fully qualified name java.io.Serializable -> Serializable.

[garydgregory]

Hello @coderodde

Thank you for your update and for working through my questions and comments 😄

Is the intent to replace TreeList with your new implementation? We don't want 2 implementations of the same kind of class. It seems so to me, let me know.

If so, and the purpose of this PR, move ILL to the jmh package and call it TreeListNew. Then, if the new code proves better, we can just replace the old with the new in a secondary step.

Also, the TreeList Javadoc makes claims compared to ArrayList and LinkedList. I don't see JMH tests to support these claims, unfortunately. We don't want a new implementation to be worse compared to these existing claims.

Do you see an improvement or degradation there?

Thank you!