A circular list has no header, trailer, first nor last element. This forces special cases on you.

You can either have a pseudo element or not.

If you have a pseudo element, then you need to handle it as a special case in getNext and getPrevious as it must be skipped over, but you don't need to worry about what happens when the list is empty or if you are removing something important.

If you have no pseudo element, then there are no special cases for next and previous, but there is a special case for add when the list is empty and remove if you remove the node you are using to link into the list with.

I think it is unfortunate that insert and remove call size. While I understand that you would want to reject a bad index early in the function, calling size gives these functions the property that inserting/removing cost time linear in the size of the list, not linear in the index as may be expected (or hoped for). The out-of-range-ness could be detected during the (inevitable) iteration up to the insertion/removal index.

Generally data structures and algorithms should not print errors to System.out (where it may be mixed awkwardly in the middle of other output, or be invisible in GUI applications, etc, anyway it's a mixing of concerns), but report them to the caller.

The trick is to make sure that, on EVERY operation, you update the item being changed and the two others which reference it (quite handily in a doubly linked list, the two which reference it are also the two it references).

Check each of your methods, and ensure that in each one you are updating 4 fields per change - two in the subject, and one each in the two that are linked from the subject.

While Marc-Andre already talked a lot about Java Style Conventions, here's my 2 cents on your implementation.

Inheriting:

public class List<T> implements java.util.List<T> {

In fact

Naming:

I suggest you change the name of your implementation to avoid confustion. Java already comes with two lists ((interface)java.util.List and (class)java.awt.List), that are just named List, you don't really need to introduce a third one ;)

By the way, if you implement an interface you are required to Override the methods that are specified by it.

public int size();
public boolean isEmpty();
public boolean contains(T item);
public void add(T item);
public void remove(T item);

@Override
public void add(T item) {
    Node<T> oldHead = this.head;
    this.head = new Node<T>(item);
    head.setNext(oldHead);
    oldHead.setPrev(head);
    size++;
}

Which brings me to my next point:

Hiding inner classes:

There is absolutely no need to show how your list works internally by exposing a node-class to all who got your List.

Instead in Java you can use a feature called 'Inner Classes'. It's quite simple:

public class MyList<T> implements List<T> {
    private Node<T> head = null;
    private int size = 0; //you could also use long when you expect more than 2150kk items

    public MyList() {}

    private static class Node<T> {
        private final T value;
        private Node<T> next = null;
        private Node<T> prev = null;

        protected Node<T>(T value) {
            this.key = value;
        }

        T value() {
            return this.value;
        }

        void setNext(Node<T> newNext) {
            this.next = newNext;
        }

        void setPrev(Node<T> newPrev) {
            this.prev = newPrev;
        }

        Node<T> getNext() {
            return this.next;
        }

        Node<T> getPrev() {
            return this.prev;
        }
    }
    //Here goes the rest of MyList implementation
}

I am using a few tricks here:
The first thing you might probably notice is the keyword final. In case you haven't heard of it yet: The compiler enforces, that a final variable is only assigned once. This allows me to make an Instance of Node single-use only. If you want to change an item, you will have to replace it with a whole new node.

Beware this does not prevent changes to Objects themselves. It is very possible to do:

private final Map<String, String> demonstration = new HashMap<String, String>();

public void doSomething() {
    demonstration.put("Demo", "Value");
}

The other thing is that I initialize next and previous not in the constructor. This is just my personal preference!

Additionally the inner class is static. This prevents access from the inner class to the outer one when using this. For more information have a look at this CR-Answer.

While we're at constructors / initialization:

Consistency:

One big issue I see with your code, is that you don't work consistently:

public Node() {
    this.setNext(null);
    this.setPrev(null);
}

---

public List() {
    head = null;
}

You use quite the mix here. In the Node constructor you use the setters - even with this keyword - to instantiate your Node, in your list you do it directly - and without this - on the field.

While both may be legal, I personally prefer using the middle way. As you have seen in the code above I usually initialize fields by using the this, but not the setter methods. In case of equal names it's required to use this so I usually put it everywhere.

Example no. 2:

node<T> f = head, b = head.getPrev();

---

node<T> b = head.getPrev();
b.getPrev().setNext(head);

here you have some statements on one and the same line, while throughout the rest of your code, you mostly place statements on separate lines.

Here I advise to wherever possible use the second approach. One Statement has one line and one line has one (or no) statement.