LinkedList implementation implementing the List interface in Java

So here it is, my linked-list implementation in Java. I have coded against Java's List interface as if my LinkedList could replace the standard java.util.LinkedList and it should make no difference.

I am however aware of that I did not implement Deque, as only implementing List is a task on its own already.

This code has been implemented using Java 8.

```
/**
*
* @author Frank van Heeswijk
* @param Type of elements the list stores
*/
public class LinkedList implements List {
/ Fake head node, meaning that it is not part of the List it represents. /
private Node head;

/ Fake tail node, meaning that it is not part of the List it represents. /
private Node tail;

/ If this list is a sublist of a LinkedList, then the parent will be in this variable. /
private LinkedList parentList;

/ The amount of modifications that occured to this LinkedList so far. /
private int modificationsCount;

/ The size of this LinkedList. /
private int size;

public LinkedList() {
this(Collections.emptyList());
}

public LinkedList(final Collection collection) {
this.head = new Node(null);
this.tail = new Node(null);
connect(head, tail);
addAll(collection);
}

private LinkedList(final Node head, final Node tail, final int size, final LinkedList parentList) {
this.head = head;
this.tail = tail;
this.size = size;
this.parentList = parentList;
}

@Override
public int size() {
return size;
}

@Override
public boolean isEmpty() {
return (size() == 0);
}

@Override
public boolean contains(final Object object) {
return iteratorToStream().anyMatch(elem -> elem.equals(object));
}

@Override
public Iterator iterator() {
return listIterator();
}

@Override
public Object[] toArray() {
return iteratorToStream().toArray();
}

@Ov

Lots of extra objects

The largest single criticism I have is the creation of LinkedLists where they are not necessary. Creating Objects in Java is a performance issue, especially when done often.

Methods like the following:

@Override
public E get(final int index) {
    assertIndex(index);
    return listIterator(index).next();
}

Create an object (the ListIterator) in order to get a member. This is overkill.

This pattern is repeated often.

Rule of thumb, if your code is going to act on just one member in the list, then using an iterator is probably not the best solution.
Iterator "implemented"

The bulk of your logic is implemented in the ListIterator. This is a backwards way of doing it. The Iterator should call methods bck in the list, and not the other way around.
assertIndexExclusive

This should be called assertIndexInclusive (it includes the range end).
Bug in subList

The following code:

public List subList(final int fromIndex, final int toIndex) {
    .....
    if (toIndex - fromIndex == 0) {
        return new LinkedList<>(head, head.next, 0, this);
    }

is buggy. Your code will create the sublist in the wrong place if, for example, fromIndx and toIndex are both 1.
Bugs in clear()

clear() is not modifying the modifiedCount. It should (but only if the list was not empty)
General, small things

• iterator() should be really fast and 'tight'. Iterators are used extensively for things like enhanced-for loops in Java. Borrowing a LinkedList is a heavy-weight solution for something that should be fast.

• head and tail in your LinkedList could be final.

StackExchange Code Review Q#46490, answer score: 8