Llegamos a ustedes gracias a:



Noticias

Desarrolladores de Java se regocijan

Porque las API privadas se mantienen -por ahora

[19/08/2015] Para encarar una controversia en torno a una popular pero no soportada API de Java, los planes de Oracle ahora apuntan a hacer inaccesibles por defecto la mayoría de las API internas en Java 9, dejando accesibles sólo algunas de ellas.

La cuestión se ha centrado en sun.misc.Unsafe, una API no compatible que ha sido fundamental para los desarrolladores externos de tecnología Java, como el proveedor de plataforma de datos en memoria Hazelcast, que teme que el plan para eliminar el acceso en Java 9 haría inviables sus productos. Pero una JEP (JDK Enhancement Proposal) publicada esta semana que propone encapsular la mayoría de las API internas dejaría que algunas de ellas, incluyendo sun.misc.Unsafe, fueran accesibles en Java 9. El upgrade de Java es el próximo año.

En una lista de correo de openjdk publicada esta semana, Mark Reinhold, arquitecto jefe del grupo de plataformas Java de Oracle, considera a la encapsulación una parte de la modularización de Java 9, que es la característica clave del upgrade. Por defecto, estas API internas no serían accesibles para el código que no sea el JDK. "Este cambio mejorará la integridad de la plataforma, ya que muchas de estas API internas definen operaciones privilegiadas y sensibles a la seguridad. En el largo plazo también reducirá los costos en los que incurren aquellos que mantienen el propio JDK y por los responsables de las bibliotecas y aplicaciones que, a sabiendas o no, hacen uso de estas API internas no estándar, inestables y no compatibles.

Reinhold añadió que era "bien conocido que algunas bibliotecas populares hacen uso de estas API internas, como sun.misc.Unsafe, para invocar métodos que serían difíciles, si no imposibles, de implementar fuera del JDK.

Para asegurar la amplitud de las pruebas y la adopción de esta versión de Java, Oracle propone hacer frente a estas API "críticas de la siguiente manera: Si hay un reemplazo soportado en JDK 8, será encapsulado; si no tiene un reemplazo soportado en el JDK 8, entonces será encapsulado en JDK 9 (Java 9), por lo que sigue siendo accesible para el código externo. Si hay un reemplazo soportado en el JDK 9, entonces las API serían dejadas de lado en el JDK 9, encapsuladas y, posiblemente, retiradas en el JDK 10, dijo Reinhold.

Christoph Englebert, evangelista técnico y Arquitecto senior de soluciones de Hazelcast, dio un suspiro de alivio. "Afortunadamente, Oracle parece escuchar a la gente.

La propuesta de Reinhold es "interesante, señaló el analista John Rymer, de Forrester Research. "Creo que la pelota está de vuelta en la cancha de los proveedores externos, para ser más específicos sobre el desastre inminente. La respuesta de Reinhold sugiere que Oracle los tiene cubiertos, pero entonces, ¿dónde están los vacíos?

La JEP sí menciona algunos riesgos y supuestos del plan de encapsulación. "Si alguna API interna crítica que es ampliamente utilizado no es identificada para cuando se lance el JDK, entonces las aplicaciones que dependen de ella fallarán. La solución provisional para esta situación sería que el usuario final exponga la API a través de línea de comandos antes mencionada; en el largo plazo, en una actualización del JDK 9 la API podría ser trasladada al módulo jdk.internal y exportada para uso externo.