Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

1.3K
Vistas
¿Por qué se permiten métodos estáticos dentro de una clase interna no estática en Java 16?

Sabemos que se puede acceder a una clase interna no estática utilizando la instancia de la clase externa, por lo que un método estático es menos significativo dentro de una clase no estática. Pero desde Java 16 se permiten métodos estáticos dentro de una clase interna no estática.

¿Por qué existió esta restricción en primer lugar? ¿Por qué se permite esto en la versión más nueva?

 public class OuterClass { class InnerClass { static void printMe() { System.out.println("Inside inner class"); } } public static void main(String[] args) { InnerClass.printMe(); } }
over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

Está solicitando el razonamiento de un cambio en Java 16, por lo que debe comenzar por consultar las Notas de la versión para ver si tiene algo que decir. Lo hace:

JEP 395: Registros ( JDK-8246771 )
herramientas/javac
Se han añadido registros al lenguaje Java. Los registros son un nuevo tipo de clase en el lenguaje Java. Actúan como portadores transparentes de datos inmutables con menos ceremonia que las clases normales.

Desde que las clases anidadas se introdujeron por primera vez en Java, con la excepción de los campos finales estáticos inicializados por expresiones constantes, se ha prohibido que las declaraciones de clases anidadas internas declaren miembros estáticos. Esta restricción se aplica a clases de miembros no estáticos, clases locales y clases anónimas.

JEP 384: Registros (Segunda vista previa) agregó soporte para interfaces locales, clases de enumeración y clases de registro, todas las cuales son definiciones estáticas. Esta fue una mejora bien recibida, que permite estilos de codificación que reducen el alcance de ciertas declaraciones a contextos locales.

Si bien JEP 384 permitió clases e interfaces locales estáticas, no relajó la restricción sobre las clases e interfaces de miembros estáticos de las clases internas. Una clase interna podría declarar una interfaz estática dentro de uno de los cuerpos de sus métodos, pero no como miembro de la clase.

Como siguiente paso natural, JEP 395 relaja aún más las restricciones de anidamiento y permite que se declaren clases, métodos, campos, etc. estáticos dentro de las clases internas.

Para más detalles, ver JEP 395 .

over 4 years ago · Santiago Trujillo Denunciar

0

El razonamiento específico se da en JEP 395

Miembros estáticos de clases internas

Actualmente se especifica que es un error de tiempo de compilación si una clase interna declara un miembro que es explícita o implícitamente estático, a menos que el miembro sea una variable constante. Esto significa que, por ejemplo, una clase interna no puede declarar un miembro de clase de registro, ya que las clases de registro anidadas son implícitamente estáticas.

Relajamos esta restricción para permitir que una clase interna declare miembros que sean explícita o implícitamente estáticos. En particular, esto permite que una clase interna declare un miembro estático que es una clase de registro.

En otras palabras, era necesario eliminar la restricción sobre miembros estáticos de clases internas para un caso particular; es decir, permitir que las clases de record se declaren en clases internas. Pero decidieron aprovechar para quitar la restricción en todos los casos.

Esto implica que los diseñadores han llegado a la conclusión de que la restricción original en su conjunto no era necesaria por razones técnicas ni deseable.


¿Por qué existió esta restricción en primer lugar?

Esa es una pregunta más difícil. La decisión de hacer esa restricción se habría tomado en 1996 o principios de 1997 cuando se estaba diseñando Java 1.1. Es poco probable que alguien todavía pueda recordar con precisión las razones detrás de la decisión original. Entonces, a menos que alguien pueda encontrar una fuente escrita contemporánea, nunca lo sabremos con seguridad.

(Brian Goetz comentó anteriormente: "... en el momento en que se agregó nested (Java 1.1), había múltiples interpretaciones posibles de static dentro de otra clase, por lo que la pregunta se aplazó" . Eso ciertamente tiene sentido, pero esto podría ser ( solo) el recuerdo de una persona de algo que sucedió hace ~ 25 años. Si fuera yo, no confiaría en mi memoria desde tan atrás. A menos que tuviera minutos contemporáneos, notas, etc. para consultar).

Hay algunas especulaciones sobre la justificación de la restricción original aquí:

  • ¿Por qué Java prohíbe los campos estáticos en las clases internas?
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda