Documentation contradictions about ReentrantReadWriteLock. Does eventually write lock has priority over read lock or not in fair mode?

Question

From ReentrantLock javadoc:

Fair mode
When constructed as fair, threads contend for entry using an approximately arrival-order policy. When the currently held lock is released either the longest-waiting single writer thread will be assigned the write lock, or if there is a group of reader threads waiting longer than all waiting writer threads, that group will be assigned the read lock.

A thread that tries to acquire a fair read lock (non-reentrantly) will block if either the write lock is held, or there is a waiting writer thread. The thread will not acquire the read lock until after the oldest currently waiting writer thread has acquired and released the write lock. Of course, if a waiting writer abandons its wait, leaving one or more reader threads as the longest waiters in the queue with the write lock free, then those readers will be assigned the read lock.

A thread that tries to acquire a fair write lock (non-reentrantly) will block unless both the read lock and write lock are free (which implies there are no waiting threads). (Note that the non-blocking ReentrantReadWriteLock.ReadLock.tryLock() and ReentrantReadWriteLock.WriteLock.tryLock() methods do not honor this fair setting and will acquire the lock if it is possible, regardless of waiting threads.)

Maybe it is problem with my English but I see contradictions at this decription:
From first paragrapgh I don't understand meaning of approximately arrival-order policy

1. from first paragraph I understand that lock acquire the oldest waiting thread. If oldest thread - read thread then it will be group of read threads which wait longer than the longest waiting write thread.
2. From second paragraph I understand that read lock will not acquire if write lock exists in wait-set.

Please clarify this contradiction.

Answer 1

Here, quoting from your quote:

or if there is a group of reader threads

In other words: a writer wins over a single reader; but when a group of readers wants the lock, those get the lock.

Regarding the question: "and what does group actually mean" ... that would be an implementation detail, only available by looking into the source code.