I examined the LinkedBlockingQueue.java file in the jdk7u source code and saw that both fields (head, last) are naturally defined as hidden. This is a commonly used technique in programming languages based on OOP to prevent direct client access to fields. Relevant lines of code are available below:

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

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

Coming to your question, it's possible that you come across different uses when browsing from a different source. However, you are always responsible for questioning and investigating its reliability. I recommend looking at more sources to get good code practices.

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.}