Why LinkedBlockingQueue's head is not private?

Question

I'm reading LinkedBlockingQueue code (JDK8u), and I find LinkedBlockingQueue's head field is not private, but last field is private. I can't find any particular opration with head . So why not set head to private ?

/**
 * Head of linked list.
 * Invariant: head.item == null
 */
transient Node<E> head;

/**
 * Tail of linked list.
 * Invariant: last.next == null
 */
private transient Node<E> last;

Answer 1

First some facts.

1. In Java 6, the head field is private.
2. By Java 17, the head field is package private ... and it has the comment about invariants.
3. The change actually happened in Java 8.

So why did they change it?

Well I haven't been able to figure that out so far, but possible reasons might include:

• So that subclasses (in the same package) can access the field, though I can't see any such classes in the published code base.
• To make it easier to test the class. (This is not a good reason to make this change, and I can't see any evidence that this is the reason.)
• It is a "personal style" thing related to inner classes, though I'm not convinced. (Why just do it for head? Why not tail as well?)
• It happened by accident.

After spending a 20 minutes of so looking at the history on Github, I think it was probably an accident. The change appears to have happened in this commit (https://github.com/openjdk/jdk8u/commit/6f31fa54ac050d781656d6e8ed18a40b55ef5c0d) ... according to "git blame". But when I look what is in the commit, I can't see the change at all, let alone the purpose¹. It is baffling.

Maybe it is clearer in the Mercurial history².

At any rate, this whole thing is an exercise in curiosity. It doesn't matter why they changed it, and it doesn't affect any user code that they did³.

---

^{1 - The changeset description says that it is just syncing up with a private repo maintained by the original / primary author of the java.util.concurrent classes.
2 - We are looking a read-only Git mirror of the definitive Mercurial repository. It is possible that something has gotten screwed up in the creation of the mirror.
3 - ... modulo interaction with Heisenbugs already present in the user's code.}