Pronto sabremos los planes que tiene Oracle para el Java Community Process

Cuál va a ser el futuro del Java Community Process (JCP) es algo que ahora mismo no está claro en absoluto. Resulta bastante obvio que por un lado Oracle no está contento con cómo funciona. Y la comunidad tampoco está contenta: después de que Apache, Tim Peierls y Doug Lea abandonasen el organismo de estándar a finales del año pasado, está claro que hay algo que no está funcionando de modo adecuado, al menos para la comunidad.

Otro claro hecho que apunta al descontento de la comunidad (inclusive los propios miembros del JCP) es que el año pasado por primera vez en la historia del cuerpo de estándares un candidato al Comité ejecutivo (Hologic) propuesto por la compañía que es dueña de Java no fue ratificado por el JCP. El candidato fue rechazado, obligando a Oracle a proponer otro candidato.

Algunas mentes influyentes dentro del mundo Java (los chicos de Javaposse por ejemplo) tienen la impresión de que es posible que Oracle esté maniobrando para "desmantelar el JCP". Y Forrester parece estar de acuerdo también en que el cuerpo de estándares cada vez va a ser menos relevante.

Todas estas nubes van a comenzar a despejarse en breve. Patrick Curran, chair del JCP, en una entrevista en Java Spotlight Podcast (un podcasts corporativo oficial de Oracle) indicó que efectivamente son necesarios cambios al JCP. Y que esto se van a realizar de un modo bastante similar a como al final se decidió hacer los cambios para la siguiente versión de Java SE: en dos etapas.

En las próximas semanas, Oracle enviará dos Java Specification Request (JSR) al JCP cuyo propósito es cambiar cómo el propio JCP funciona. Dada la normativa del JCP, cambios al actual proceso de funcionamiento del organismo tienen que ser decididos y aprobados por el propio organismo de estándares.

Según Curran, el primero de estos JSR propondrá cambios que serán fácilmente aceptables por el JCP. Por tanto, se aprobará rápido y se implementarán a corto plazo (al estilo de lo que se hizo con Java SE 7). El segundo, propondrá cambios más radicales que requerirán más tiempo para refinarlos y alcanzar un consenso (al estilo de Java SE 8).

En el podcast no han dicho demasiado sobre en qué van a consistir estos cambios. Sólo unas pocas palabras bastante poco concretas sobre "hacer más abierto el proceso", palabras que al final pueden acabar significando cualquier cosa o absolutamente nada.

Con casi total seguridad, uno de los puntos más controvertidos serán los términos de licenciamiento de las implementaciones de las especificaciones. Quizás las cosas vayan a mejor y se eliminen las restricciones que actualmente existen (motivo por el cual Apache abandonó el cuerpo de estándares). O quizás todavía vayan a peor... y el propio hecho de que Oracle no cediese el año pasado y Apache se viese forzado a abandonar el JCP no augura muy buenas noticias en este sentido. En cualquier caso, pronto sabremos qué es lo que planean.