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.

eBook gratuito sobre Jenkins (Hudson)

John Ferguson Smart, de Wakaleo Consulting (una consultora de Nueva Zelanda), ha publicado una revisión de su eBook gratuito sobre Jenkins (el antiguo Hudson, y aunque en la portada del libro todavía habla de Hudson ellos mismos se refieren a él en su web como Jenkins :) ).

En esta nueva revisión el libro añade un capítulo sobre las distintas opciones de notificación que tiene el servidor de integración continua. Sin duda, se trata de un excelente recurso para aquellos interesados en aprender a trabajar con Jenkings.

Para aquellos que todavía no conozcáis Jenkings, os voy a explicar una forma fácil de echarle un vistazo: simplemente haced un clic aquí y después visitad en vuestro navegador http://localhost:8080/. El enlace contiene una versión de Jenkins empaquetado como una aplicación Java Web Start. Con sólo hacer esto tendréis acceso a una versión demo del servidor de integración continua que está corriendo en vuestro propio equipo:

 

A partir de agosto de este año habrá que tomar cursos oficiales de Oracle para certificarse

Para ponerse en la línea con las prácticas mafiosas comunes dentro de la industria tecnológica, así como dentro de la propia compañía, Oracle va a cambiar los requerimientos para poder acceder a varias certificaciones, incluyendo la de Java SE 6 Developer y la de  Java EE 5 Enterprise Architect. A partir del 1 de agosto de este año requerirá atender por lo menos a un curso de formación oficial antes de hacer el examen de la certificación.

Esta práctica, lejos de ser algo exclusivo de Oracle, es una técnica mafiosa muy común dentro de la industria tecnológica. Si las certificaciones realmente certificasen conocimientos, cualquiera podría presentarse a ellas e intentar obtenerla en base a méritos propios. Pero no, prácticamente en todos los casos (Java con Sun era una rara excepción) además de tener que presentarte al examen de la certificación (y pagar por él) tienes que haber tomado un caro curso de formación oficial por el cual todavía vas a tener que pagar bastante más.

Hasta el 31 de julio de este año sigue siendo posible presentarse directamente a los exámenes de certificación sin necesidad de tomar el curso oficial. Si alguno de vosotros está planteándose obtener alguna de las certificaciones Java afectadas por esta norma, le recomiendo que se apure a tomar el examen.

¿Qué valor tienen este tipo de certificaciones oficiales en vuestro país? ¿Resultan realmente útiles para encontrar trabajo o mejorar tu posición? 

JavaHispano Podcast - 109- Noticias Marzo 2011 (a)

Publicado un nuevo número del podcast de javaHispano. En esta ocasión Abraham Otero y Alfredo Casado hablarán de las noticias más interesantes publicadas recientemente en el portal. De las noticias que hablarán:

• Javahispano cumple 10 años
• Resumen del Spring I/O
• Final de la JavaCup 2011
• Algunos comentarios sobre el futuro de java de un analista de Forrester
• Llamada a las armas para esta comunidad. Todo el mundo a apoyar a Koshuke
• IcedRobot, un fork de Android basado en el OpenJDK
• Nokia y Microsoft unen fuerzas para intentar ser relevantes en el mundo de la movilidad
• Nuevo proyecto de Eclipse Foundation: Orion Platform

Interesantes reflexiones sobre la longevidad de los programadores

Davy Brion ha escrito una interesante entrada reflexionando acerca de la longevidad de los programadores en su blog . Comienza con una pregunta bastante curiosa: ¿Cuántos programadores conoces que tengan más de 40 años? Según él, para la mayor parte de la gente la respuesta a esta pregunta será "0". Yo conozco alguno, pero tengo que reconocer que son muy pocos.

Para los desarrolladores que conoces por encima de 40 años ¿cuántos de ellos son buenos? (Curiosamente en mi caso, todos). Según él, muchos desarrolladores según van envejeciendo van comenzando a coger más responsabilidades de gestión. Poco a poco, y casi sin darse cuenta, dejan de escribir código y por tanto dejan de ser programadores. Seguro que todos habéis visto esta historia más de una ocasión.

Los pocos programadores que siguen programando por encima de los 40 años, se desmotivan, o piensan que ya lo saben todo y dejan de aprender. Siguen haciendo las cosas como las hacían hace 10-15 años y dejan de ser buenos programadores.

Davy Brion no quiere seguir ninguno de estos dos caminos. Ni quiere dejar de programar, ni quiere convertirse en un mal programador. Y para ello propone considerarse siempre un estúpido y tratar de aprender cosas nuevas continuamente, y cuestionarse todo lo que uno hace para evitar caer en el "esto ya lo hice así una vez hace 10 años, así que lo vuelvo hacer del mismo modo ahora".

¿Cuántos programadores por encima de 40 años conocéis vosotros? ¿Son buenos o malos? Y ¿queréis vosotros seguir programando cuando estéis por encima de los 40 años?