Examiné el archivo LinkedBlockingQueue.java en el código fuente jdk7u y vi que ambos campos ( head , last ) se definen naturalmente como ocultos. Esta es una técnica comúnmente utilizada en lenguajes de programación basados en programación orientada a objetos para evitar el acceso directo del cliente a los campos. Las líneas de código relevantes están disponibles a continuación:

 /** * 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;

En cuanto a su pregunta, es posible que encuentre diferentes usos cuando navega desde una fuente diferente. Sin embargo, usted siempre es responsable de cuestionar e investigar su confiabilidad. Recomiendo buscar más fuentes para obtener buenas prácticas de código.

Primero algunos hechos.

1. En Java 6, el campo head es private .
2. En Java 17, el campo head es paquete privado... y tiene el comentario sobre invariantes.
3. El cambio realmente ocurrió en Java 8.

Entonces, ¿por qué lo cambiaron?

Bueno, hasta ahora no he podido descifrarlo, pero las posibles razones pueden incluir:

• Para que las subclases (en el mismo paquete) puedan acceder al campo, aunque no puedo ver ninguna de esas clases en la base de código publicada.
• Para que sea más fácil probar la clase. (Esta no es una buena razón para hacer este cambio, y no puedo ver ninguna evidencia de que esta sea la razón).
• Es una cosa de "estilo personal" relacionado con las clases internas, aunque no me convence. (¿Por qué solo hacerlo por la head ? ¿Por qué no también por la tail ?)
• Ocurrió por accidente.

Después de pasar 20 minutos mirando la historia en Github, creo que probablemente fue un accidente. El cambio parece haber ocurrido en este compromiso ( https://github.com/openjdk/jdk8u/commit/6f31fa54ac050d781656d6e8ed18a40b55ef5c0d )... de acuerdo con "culpa de git". Pero cuando miro lo que hay en la confirmación, no puedo ver el cambio en absoluto, y mucho menos el propósito ¹ . es desconcertante

Tal vez sea más claro en la historia de Mercurial ² .

En cualquier caso, todo esto es un ejercicio de curiosidad. No importa por qué lo cambiaron, y no afecta ningún código de usuario que hayan hecho ³ .

^{1: la descripción del conjunto de cambios dice que solo se está sincronizando con un repositorio privado mantenido por el autor original/principal de las clases java.util.concurrent .
2 - Estamos buscando un espejo Git de solo lectura del repositorio definitivo de Mercurial. Es posible que algo se haya estropeado en la creación del espejo.
3 - ... modulo de interacción con Heisenbugs ya presentes en el código del usuario.}