Las clases ocultas podrían llegar a Java

Una propuesta ante el equipo de desarrollo de OpenJDK agregaría clases ocultas a Java, una capacidad destinada a mejorar la eficiencia de las implementaciones de lenguaje integradas en la JVM.

Las clases ocultas son clases que no pueden ser utilizadas directamente por el código de bytes de otras clases, de acuerdo con la propuesta de mejora de JDK. Más bien, las clases ocultas están destinadas a ser utilizadas por marcos que generan clases en tiempo de ejecución y las usan indirectamente a través de la reflexión. Una clase oculta se puede definir como miembro de un nido de control de acceso y su cargador de clases puede hacer referencia débilmente a ella. Todavía no hay un calendario para cuándo pueden aparecer clases ocultas en Java.

Al explicar la motivación detrás del plan, la propuesta establece que muchas implementaciones de lenguaje basadas en la JVM aprovechan la generación dinámica de clases para lograr eficiencia y flexibilidad. El compilador javac de Java, por ejemplo, no traduce una expresión lambda en un archivo de clase dedicado en tiempo de compilación, sino que emite bytecode para generar e instanciar dinámicamente una clase. Del mismo modo, los lenguajes JVM que no son Java a menudo implementan características de orden superior mediante el uso de proxys dinámicos para generar clases dinámicamente.

Los implementadores de estos lenguajes generalmente quieren que una clase generada dinámicamente sea parte de una clase existente generada estáticamente y que tenga propiedades deseables de las clases generadas dinámicamente, como la no detección y el control de acceso. Sin embargo, las API estándar que definen una clase no fueron diseñadas con estos propósitos en mente.

Si las API estándar pudieran definir clases ocultas, no detectables con un ciclo de vida limitado, los marcos dentro y fuera del JDK que generan clases dinámicamente podrían definir clases ocultas, mejorando la eficiencia del lenguaje JVM.

Los objetivos de la propuesta de clases ocultas incluyen:

  • Permitir que los marcos definan las clases como detalles de implementación no detectables del marco, de modo que otras clases no puedan vincularlos ni descubrirlos mediante la reflexión.
  • Desuso de la API no estándar, misc.Unsafe :: defineAnonymousClass, con el objetivo de eliminarlo en una versión futura.
  • No cambiar el lenguaje Java en absoluto.
  • Soporte para extender un nido de control de acceso con clases no detectables.
  • Admite la descarga agresiva de clases no detectables, dando a los marcos la flexibilidad para definir según sea necesario.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *