Ha nacido una nueva máquina virtual, JamVM. Se trata de una máquina virtual absolutamente libre y compatible con la especificación de Java 2. Se ha testeado en arquitecturas PowerPC e i386. Está diseñada para utilizarse con las librerías GNU Classpath por lo que soporta la mayor parte del JDK 1.3 y algo del 1.4. JamVM no funciona con las clases del JDK de SUN ni de IBM. Su instalación es muy sencilla y podéis ver todo lo que ofrece en la página web del proyecto Un saludo.
SnipSnap, un framework muy sencillo para la creacrión de weblogs con soporte Wiki ha llegado a la versrión 0.4. Poco a poco se le van añadiendo características interesantes como permalinks, recuento de dýas desde la creacrión de los mensajes, lanzamiento simple desde un ýnico jar y correccrión de numerosos errores. Podéis descargaros la ýltima versrión desde aquí.
Filip, el creador del módulo de clustering para Tomcat 5 nos obsequia a todos con un pequeño tutorial de implementacrión de clustering con Tomcat 4. El código aunque en estado beta nos permitirý crear fýcilmente un cluster con servidores Tomcat. Podéis echarle un vistazo aquí. Seguro que a muchos os interesa.
Copyright (c) 2002, Martín Pérez Mariñán y Alberto Molpeceres Touris. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/).
Introducción
Hace unos meses publicamos un trabajo[1] sobre arquitectura empresarial y software libre bajo la plataforma empresarial de Java, J2EE. En este trabajo se muestra como construir arquitecturas empresariales competitivas utilizando única y exclusivamente productos basados en software libre.
El hecho de poder construir arquitecturas empresariales basadas en Java y productos libres tiene una importancia grandísima, aún así, existen todavía muchas dudas al respecto del grado de libertad del que se disfruta actualmente en la raiz de todas las plataformas Java, es decir, en el lenguaje propiamente dicho.
En este artículo hemos intentado realizar un profundo análisis histórico de las relaciones entre el mundo de Java y el mundo del software libre. En este análisis recorreremos la historia de dichas relaciones y los sucesos más importantes que se han producido durante estos años. Veremos cuales son los organismos que rigen la evolución de las plataformas basadas en Java y como se han ido liberalizando paulatinamente. Por último, veremos el soporte actual que ofrece Java para el desarrollo de soluciones libres ya sea en su plataforma empresarial, estándar o móvil.
Cuando no existía el JCP
Desde que apareció en el mundo de la informática, allá por 1995, Java, como lenguaje y como plataforma ha ocasionado siempre sentimientos enfrontados. Mientras una parte del mercado se mostró entusiasmado por su soporte de múltiples plataformas, otra parte lo consideraba inaceptablemente lento, y una tercera parte, el mundo del software libre, lo denostaba por su caracter de software propietario, a pesar de que la plataforma de desarrollo se ofrecía de forma gratuita.
Java nace como un lenguaje de programación propietario de la mano de SUN Microsystems. Pese a ello SUN advierte pronto la necesidad de implicar a cuantas más empresas y desarrolladores mejor, por lo que crea la posibilidad licenciar su tecnología y desarrollar soluciones en base a ella, y se muestra abierta a las aportaciones de programadores particulares.
El mayor problema de esta licencia está en que la propiedad del software será siempre de SUN Microsystems y/o sus empresas licenciatarias, esto es, cualquier mejora o cambio realizado por un licenciatario, debería ser entragado a SUN Microsystems para, una vez aceptados, ser distribuidos al resto de licenciatarios. Por supuesto dicha situación no era ni mucho menos favoracedora del desarrollo de la plataforma.
No se permitía tampoco crear clases que estuvieran dentro de la jerarquía de paquetes java.*, javax.* o sun.*, lo que impedía que la gente pudiera realizar su propia implementación de alguna librería de Java y reemplazarla limpiamente en la versión oficial.
A pesar de todo ello, empezaron a crearse grupos de amantes del software libre intentando crear implementaciones independientes del compilador y la máquina virtual, como Kaffe [25] y Japhar [27]. Por su parte era también imposible la distribución pública de JDK o JRE de sitios externos a SUN, ya que era requerida la aceptación explícita de la licencia.
Aún así, eran también numerosas las opiniones a favor de dicha situación, ya que el mantener Java bajo el control de SUN Microsystems favorecía un desarrollo uniforme, e impedía desarrollar versiones devaluadas de la plataforma como en el caso del kit de desarrollo de Microsoft.
Febrero de 1999: SUN Community Source License ( SCSL )
Pero como hemos dicho, el estricto control que mantenía SUN Microsystems sobre Java era un cuello de botella para el desarrollo de la plataforma, por lo que en Febrero de 1999 se comienzan (se había hecho público Java 2 un par de meses atras) a hacer públicas las mayorías de las APIs de Java bajo una nueva licencia: SUN Community Source License [2]
Esta nueva licencia, que según SUN Microsystems recogía lo mejor del software libre y del propietario, distinguía entre cinco tipos de usos: investigación, TCK (Technology Compatibility Kit), uso interno, uso comercial y uso de la marca registrada Java.
Desde este momento era también posible descargar gratuitamente el código fuente de varias APIs, incluido el JDK, para usos no comerciales. Además, era posible mantener los cambios que realizasemos a las clases del API siempre que pasaran los test de compatibilidad pertinentes, aunque aún habría que pagar unas tasas en caso de uso distinto al de investigación (esto es, uso interno o comercial).
El mayor problema para el mundo del software libre, que ofrecía esta licencia, era que al aceptarla y ver el código fuente de las clases del kit de desarrollo, estabas aceptando que dicho código era propiedad intelectual de SUN Microsystems, y por consiguiente, no podías participar en la implementación de cualquier otra implementación independiente de la plataforma Java. Obviamente, esta licencia se alejaba mucho de ser "lo mejor del mundo del software libre" como había se había afirmado.
Diciembre 1998: La creación del JCP
Un poco antes de la liberación del código fuente de la plataforma Java, SUN Microsystems comenzó a plantearse la necesidad de estandarizar el desarrollo dentro de su plataforma. Poco a poco, con el paso del tiempo, el uso de Java se fue extendiendo cada vez más, sobre todo por entornos universitarios y poco a poco comenzaba a sonar cada vez más en la industria.
Todo esto hacía que comenzasen a surgir diferentes tecnologías ( EJB, Servlets/JSP, JSSE, etc. ) que era necesario estandarizar de algún modo para que cada licenciatario no ofreciese sus implementaciones propias. Era necesario conseguir que un organismo imparcial se encargase de controlar los diferentes desarrollos que se produjesen en la plataforma para asegurar su evolución.
La primera opción para SUN fue enviar el lenguaje a una organización dedicada al control de estándares como la ISO. La opción fue descartada y esto provocó muchas críticas por parte de la rama más escéptica de la comunidad Java. La versión oficial de SUN para justificar dicha decisión fue ( y sigue sisendo ) que enviando el lenguaje a uno de estos organismos se perdería una de las características más importantes de la plataforma: su dinamismo. Según SUN Microsystems, enviando Java a un organismo de este estilo no se lograría nada más que convertirlo en un nuevo CORBA que caería en desuso debido a su lenta evolución.
Era necesario crear otro organismo, y SUN decidió crearlo el mismo, de este modo, se decidió constituir el Java Community Process ( JCP )[3].
Java Community Process ( JCP )
Java, siempre fue criticado por ser única y exclusivamente de SUN. A raiz de todas esas críticas, como ya hemos comentado en el apartado anterior, SUN decidió el 8 de diciembre de 1998 dar la posibilidad a todo el mundo de participar en la evolución de Java y de todas las plataformas que se basan en Java. Con esa intención se creó el JCP, el organismo encargado de asegurar la evolución de Java.
La función del JCP es controlar la evolución de las diferentes especificaciones basadas en el lenguaje Java. Este organismo se encarga de decidir que especificaciones son aprobadas, además de controlar la creación y evolución de dichas especificaciones.
El JCP es un organismo formado por multitud de empresas de las más importantes dentro del mundo de la informática y las telecomunicaciones. Empresas como SUN, IBM, SAP, BEA, IONA, Oracle, Nokia, Siemens, Siebel, Motorola, etc., exceptuando obviamente a Microsoft.
Organismos de dirección
En el JCP existen dos comités[4] diferentes, uno encargado de las especificaciones que afectan a J2SE y J2EE, y otro encargado de las especificaciones que afectan a J2ME. Cada uno de estos comités está formado por 16 miembros. Una parte de esos miembros es elegida mediante votación pública por parte de todos los participantes en el JCP, mientras que otra parte es elegida por los licenciatarios más importantes de SUN. Este último tipo de miembros es ratificado mediante votación pública por parte de todos los miembros del JCP.
¿Quién puede participar?
Cualquier persona, organización con o sin ánimo de lucro y empresa puede participar dentro del JCP. El coste de participación en la versión actual del JCP es:
Entidades comerciales : 5000 dólares
Organizaciones académicas y sin ánimo de lucro: 2000 dólares
Para convertirse en un miembro del JCP es necesario firmar un contrato que se denomina Specification Participation Agreement ( JSPA )[5]. Firmando este acuerdo aceptamos las condiciones y reglas de participación dentro del JCP. Este acuerdo dura un año y es renovable y requiere el pago de las cantidades que vimos anteriormente.
Java Specification Participation Agreement for an Individual Expert Group Participant ( IEPA )
Existe una segunda forma de participar dentro del JCP. En esta forma, no es necesario convertirse en un miembro de dicho organismo sino que se puede participar como experto individual en alguna tecnología. Estos expertos tienen que cubrir el Java Specification Participation Agreement for an Individual Expert Group Participant ). Este acuerdo es otro contrato entre SUN Microsystems y en este caso una persona individual en el cuál esta última se compromete a no revelar las interioridades de todo el trabajo llevado a cabo por el grupo de expertos que colaboran en el desarrollo de la especficación..
Una persona que quiera participar en varias especificaciones simultáneamente tendrá obligatoriamente que darse de alta como miembro del JCP, aunque esto como vimos no le supone coste alguno. Por ejemplo Doug Lea, profesor de informática en la universidad estatal de Nueva York es el líder de la especificación Concurrency Utilities (JSR-166) además de miembro del comité ejecutivo de J2SE y J2EE.
Java Specification Request ( JSR )
JSR[7] es el acrónimo de Java Specification Request. Cuando una persona o entidad cree que es necesario la presencia de una determinada tecnología dentro de las plataformas basadas en Java, lo que hace es crear un JSR y presentarlo para su aprobación. Dentro de este documento se relata por que es necesaria dicha tecnología, por que no se pueden abordar los problemas que soluciona con las tecnologías existentes, como afectará esta tecnología a otras tecnologías existentes, etc.
Los JSR pueden formar parte de una plataforma estándar de Java, ya sea J2EE, J2SE o alguno de los diferentes profiles de J2ME. Para ello sólo tiene que explicitar dentro del JSR la intención de convertirse en una especificación estándar dentro del JSR. La decisión final sobre la inclusión de un JSR dentro de una de las plataformas estándares de Java es tomada únicamente por el líder de las especificaciones de dichas plataformas.
Todo JSR una vez finalizado, ha de proporcionar:
Una especificación en formato electrónico.
Un test de compatibilidad.
Una implementación de referencia.
Umbrella JSR ( UJSR )
SUN Microsystems es un miembro de ambos comités ejecutivos y tiene privilegios especiales en los JSRs que definen las plataformas J2SE, J2ME y J2EE. Estos JSRs se denominan JSRs paraguas. Además de esta protección, Java cuenta con otros mecanismos de protección hacia el exterior. En particular, SUN Microsystems tiene en propiedad los dominios java.* y javax.*. Cualquier cambio en estos espacios de nombres ha de ser gestionado a través del JCP.
Aún más, estos paraguas evitan cualquier cambio en el lenguaje o cualquier cambio en la máquina virtual. Asimismo, no se puede realizar tampoco ningún cambio sobre Java Native Interface ( JNI ) ni modificar ninguno de los paquetes distribuidos con la versión estándar de Java, J2SE.
Estas medidas no son demasiado bien vistas desde el exterior. El principal argumento de SUN Microsystems al respecto es que se trata de proteger a las diferentes plataformas de alteraciones indebidas ya que se tratan de las especificaciones más importantes. Permitir cambios en estas especificaciones podría poner en peligro aspectos como la compatibilidad hacia atrás o la portabilidad de las aplicaciones entre plataformas. Asimismo, permitir la creación de desarrollos bajo los nombres de java.* o javax.* podría dar lugar a diferentes versiones del lenguaje que no harían más que confundir al usuario e incluso poner en duda de nuevo la propiedad de multiplataforma de Java ( ej: Microsoft Visual J++ ).
El proceso de desarrollo
La creación de una especificación bajo el JCP es un proceso de desarrollo iterativo[8], donde la especificación va pasando por diferentes fases:
Envio de la especificación: Si queremos crear una especificación sobre alguna tecnología en particular, lo primero que deberemos hacer es proponer dicha especificación al comité que corresponda del JCP. Una vez enviada la especificación, y tras un par de semanas, el comité emitirá su veredicto y veremos aprobada o rechazada nuestra especificación.
Revisión de la comunidad: Una vez tengamos preparada una versión preliminar de nuestra especificación, ésta ha de pasar una fase de revisión por parte de la comunidad. En esta fase los miembros del JCP, y sólo ellos, pueden revisar la especificación y aportar todos los comentarios que crean convenientes. Esta fase dura de uno a tres meses. La última semana después de cerrarse la revisión pública se procede a una votación en la que se decide si la especificación puede pasar a su fase final.
Revisión pública: Si todo va bien y la comunidad aprueba la especificación, tendremos que prepararla y retocarla para su revisión pública. En esta fase la especificación se pone a disposición de todo el mundo en general y cualquiera puede desacargarla y revisarla personalmente. Es en este momento cuando cualquier persona, incluso sin ser miembro del JCP, puede opinar y tratar de mejorar la especificación.
Al tiempo que se reciben opiniones, es en esta fase cuando es necesario terminar de desarrollar la implementación de referencia ( RI ) y el conjunto de pruebas ( TCK ) que se pondrán a disposición del público.
Si todo va bien, tras un período que nuevamente puede llevar de tres a seis meses, se produce una nueva votación por parte del comité ejecutivo en la que se decide si se aprueba la versión final de la especificación. Si ésta es aprobada, la especificación se convertirá en un estándar más del mundo Java.
Fase de mantenimiento: En esta fase se produce el mantenimiento de la especificación. Durante esta etapa podremos añadir y corregir características que consideremos necesarias. Cualquier modificación en la especificación requerirá la necesidad de pasar nuevas fases de revisión pública y las respectivas votaciones por parte del comité ejecutivo antes de que dichas modificaciones puedan ser aprobadas.
Las partes de un JSR
Como hemos visto anteriormente, todo JSR una vez finalizado ha de ofrecer tres cosas: una especificación pública en formato electrónico, un conjunto de tests de compatibilidad y una implementación de referencia. Veamos un poco más en detalle cada uno de estos puntos.
La especificación
La especificación no tiene demasiada historia. Se trata de un fichero electrónico, en formato PDF, que describe la tecnología resultado del esfuerzo realizado por el grupo de trabajo de un JSR determinado. Normalmente en estas especficaciones se describen las partes de la tecnología realizada, los roles de las personas que utilizarán dicha tecnología, como se relacionan entre si las diferentes partes y personas que utilizarán la tecnología, etc.
Estas especificaciones se pueden descargar públicamente desde la web de SUN. Además, como hemos visto, durante la fase de desarrollo de la especificación existe una fase de revisión pública donde se puede acceder a estos documentos y todo el mundo, aunque no forme parte del JCP, puede expresar sus opiniones sobre el desarrollo realizado hasta ese momento.
El test de compatibilidad
Toda especificación ha de ofrecer obligatoriamente un test de compatibilidad: el Technology Compatibility Kit ( TCK ) [9] Este test consta de un conjunto de pruebas que aseguran que una determinada implementación es compatible con la especificación a la que corresponden los tests. El JCP pone a disposición de los creadores de cada especificación una serie de herramientas ( Java Compatibility Test Tools [10] ) para la creación de estos tests de compatibilidad.
Los tests de compatibilidad tradicionalmente han sido siempre una fuente de confusión en cuanto al grado de libertad de la plataforma Java. Como veremos posterioremente, hasta Noviembre del 2002, era necesario pagar una cuota de varios miles de dólares para poder pasar un test de compatibilidad. Esto era debido a que sólo los licenciatarios de SUN Microsystems podían acceder a dichos conjuntos de pruebas.
Sin embargo, lo cierto es que el hecho de no poder pasar dichos tests de compatibilidad sin ser un licenciatario de SUN Microsystems no es ninguna traba para la creación de implementaciones libres de cualquier tecnología. Se trata simplemente de una cuestión de marketing. Cuando una empresa pasa los tests de compatibilidad, gana el derecho de colgarse la medalla de implementación certificada de una especificación determinada. Esa medalla puede suponer importantes ventajas comerciales, y es esa la razón por la que la mayor parte de implementaciones comerciales de cierta importancia pasen dichos tests.
Aún así, que nuestra implementación no pase los tests de compatibilidad, de ningún modo implica que no sea compatible con la especificación. Lo único que indica este hecho es que no hemos considerado conveniente el pasar dichas pruebas.
Por poner un simil de muy fácil comprensión. Una empresa de coches si quisiese certificar que su proceso de desarrollo cumple con los estándares de calidad marcados por las normas ISO debería contratar un organismo de certificación como AENOR que garantizase que cumple todas esas normas. Sin embargo, que no quiera realizar el desembolso que eso supone no quiere decir que sus coches no sean buenos, ni siquiera que no esté cumpliendo con los estándares de calidad marcados por la ISO. Puede cumplir con esos estándares pero negarse a pagar ese dinero.
Independientemente de todo esto, lo cierto es que los tests de compatibilidad suponen una importante garantía para los usuarios y desarrolladores de las diferentes implementaciones ya que sabiendo que están utilizando una implementación compatible con la especificación, tienen garantizado que sus desarrollos serán portables entre diferentes implementaciones que sean también compatibles.
La implementación de referencia
Toda especificación ha de ofrecer también obligatoriamente una implementación de referencia. Esta implementación de referencia además ha de haber pasado previamente todos los tests de compatibilidad. Las implementaciones de referencia son importantes por numerosos aspectos:
Por un lado se trata de implementaciones que aparecen mucho antes que las versiones comerciales/libres de una especificación, por lo que permiten la familiarización temprana con la tecnología.
Por otra parte se trata de implementaciones que tienen certificada su compatibilidad por lo que nos sirven para crear desarrollos que posteriormente podremos portar a otras implementaciones que también sean compatibles con la especificación.
Al tratarse normalmente de implementaciones más simples de lo normal nos permiten una adaptación mucho más sencilla a las diferentes tecnologías.
Antes de utilizar una implementación de referencia para producción es necesario que nos aseguremos de si es apta para dicho uso. Algunas implementaciones como la de Servlets/JSP ( Apache Tomcat ) son aptas para entornos de producción, sin embargo, otras como la de J2EE no se recomiendan en absoluto para dichos entornos.
Críticas al JCP
Aunque la labor del JCP parece adecuada, lo cierto es que si se analiza desde el punto de vista del desarrollo del software libre nos encontramos con que expone una serie de limitaciones demasiado grandes:
Cuotas: Para participar dentro de este organismo es necesario pagar una cuota de participación destinada a paliar los gastos administrativos de dicho organismo. Además, si alguien implementa alguna de las especificaciones es necesario que pase un test de compatibilidad. El problema radica en que para pasar este test hay que ser licenciatario de SUN Microsystems lo que deriva en más dinero a pagar. Obviamente los más perjudicados por esto son los grupos de desarrollo de software libre y en general las asociaciones sin ánimo de lucro.
Derecho de veto SUN Microsystems tiene el derecho y privilegio de poder anular cualquier especificación si no es de su agrado.
Patentes: Si alguna especificación tiene patentes dentro de ella, en caso de que se implemente dicha especificación será necesario que se respeten dichas patentes.
Licencias: Por si fuese poco, no se permite modificar la licencia de ninguna especificación, test de compatibilidad o implementación de referencia. Normalmente dicha licencia está basada en la SCSL que vimos anteriormente. Esto plantea grandes problemas a la hora de la creación de software libre, ya que por ejemplo no sería posible extender la implementación de referencia o intentar aprender conocimientos de dicha implementación para utilizarlos posteriormente en algún proyecto libre.
El presente: JCP 2.5
Estaba claro que todas las restricciones que tenía la versión JCP 2.1 no hacían más que poner serias trabas al desarrollo de software libre. Una de las organizaciones más afectadas era la fundación Apache. Esta fundación se encontraba en una situación muy ambigua. Por una parte sus miembros estaban desarrollando implementaciones de referencia de algunas especificaciones, como por ejemplo la de Servlets/JSP, JDOM o Axis. Estas implementaciones estaban sujetas a la política de licencias de SUN Microsystems. Sin embargo, por otra parte, Apache ofrecía gratuitamente el código fuente de todas estas implementaciones, un hecho que iba absolutamente contra todas las licencias del JSPA bajo el que se estaban desarrollando dichas implementaciones. No sólo eso sino que también ofrecía con licencias libres sus implementaciones de referencia y su proceso de desarrollo no se basaba en el JCP sino que era público
Todo esto ponía a la fundación Apache en una situación de ilegalidad absoluta. Las relaciones entre SUN Microsystems y la fundación Apache eran magnificas y habían estado trabajando codo con codo conjuntamente durante mucho tiempo. El apoyo de SUN Microsystems a Apache era de sobra conocido, sin embargo, la ética de la fundación obligó a ésta a exigir que se remodelase el JCP para solucionar esta situación tan molesta.
Una muestra del descontento de la fundación Apache es que durante los dos últimos años emitió un NO en la fase de aprobación de nada más y nada menos que 14 JSRs diferentes. Las razones principales no eran deficiencias técnicas sino que casi siempre eran problemas en las licencias de dichos JSRs como por ejemplo el caso del API de logging del JDK 1.4 que prácticamente ilegitimaba a log4j de Apache, un proyecto longevo y de gran éxito.
Concretamente, la fundación Apache exigió[11] que el nuevo JSPA cumpliese al menos las siguiente condiciones:
Una licencia de una especificación no debería prohibir la creación de una implementación compatible. Al menos se deberían permitir implementaciones que cumplan la licencia Apache u otras más libres. Si una especificación tiene alguna porción de código sujeta a alguna patente que no permita su uso libre, dicho código ha de estar disponible de un modo no restringido y libre de todo coste.
El nuevo JSPA ha de permitir a cualquier grupo de expertos la creación de su propia implementación de referencia y/o test de compatibilidad y liberarlos bajo una licencia libre, nuevamente como mínimo bajo licencia Apache, si así lo desean. Hasta el momento eso ya se había hecho con éxito con las especificaciones de Servlets, JSP y Taglibs.
El nuevo JSPA ha de permitir que un grupo de expertos puedan utilizar foros de discusión públicos así como permitir la posibilidad de publicar drafts públicos cuando lo deseen, incluso antes de que se realice la revisión pública de una especificación. Sólo se protegerían las discusiones explíticamente confidenciales.
El nuevo JSPA ha de permitir que las entidades sin ánimo de lucro o académicas tengan fácil acceso a los TCKs sin tener que pagar los cientos o miles de dólares necesarios hasta el momento.
Consciente de esto, y consciente de la importancia de tener el soporte de una fundación como Apache ( independientemente de sus aportaciones ), SUN Microsystems decidió remodelar el JCP. El encargado de realizar esta remodelación fue Don Deutsch[12], vicepresidente del departamento de estándares, estrategia y arquitectura de Oracle.
Don, lideró un grupo formado por ejecutivos que formaban el JCP y cuya misión era estudiar y revisar los derechos y responsabilidades de todos los miembros y licenciatarios de dicho organismo. El objetivo principal era ayudar a pequeños desarrolladores, organizaciones, entidades educacionales, etc., a competir de una manera más efectiva con las grandes organizaciones empresariales.
El proceso de liberalización duró 25 meses y se hizo público en Marzo del año 2002. En Junio de ese mismo año, la fundación Apache y SUN Microsystems llegaron a un acuerdo definitivo y a partir de Noviembre del 2002 entró en funcionamiento la versión 2.5 del JCP.
Ventajas del JCP 2.5
Cuotas: Un comité se encargará de decidir si una asociación sin ánimo de lucro, un grupo de software libre, universidad, etc., es apto para participar en el JCP o puede pasar los tests de compatibilidad. El propósito de esta limitación es intentar evitar en la medida de lo posible la diversificación de las implementaciones. Este comité está formado por tres personas: un representante del mundo académico o del mundo del software libre, un representante de SUN Microsystems y un tercer representante elegido democráticamente por los miembros del JCP.
No sólo eso sino que este comité también se encargará de decidir que organizaciones y entidades son aptas también para acceder a los test de compatibilidad.
Derecho de veto: SUN Microsystems ha renunciado al derecho de veto que tenía sobre las especificaciones que no lideraba.
Patentes: A partir de ahora, si una especificación tiene alguna patente, las implementaciones no están obligadas a respetar dicha patente.
Licencias: La novedad más importante, sin duda alguna, es que ahora es posible implementar cualquier especificación, test de compatibilidad o implementación de referencia con cualquier licencia por libre que sea. Esto es un hito importantísimo dentro de la historia de Java ya que por primera vez se legitiman las diferentes implementaciones libres de multitud de especificaciones. A partir de ahora, será posible extender implementaciones de referencia existentes, crear nuevas versiones comerciales, pasar los test de compatibilidad, etc., sin los problemas existentes hasta el momento.
Especificaciones afectadas
El proceso de liberalización no es inmediato. En un principio, todas las nuevas especificaciones (JSRs) iniciadas desde el 29 de Octubre del 2002 operan bajo los términos del nuevo JSPA. De este modo, todas las entidades, organismos o personas que participen en estos JSRs disponen ya de estos nuevos derechos.
Por otra parte, respecto a las especificaciones iniciadas anteriormente al 29 de Octubre del 2002 pueden darse dos casos diferentes. Por un lado, todas las nuevas versiones de dichas especificaciones pasan a regirse automáticamente por el nuevo JCP. Para el resto de versiones se deja la decisión de modificar el JCP por el que se rigen al líder de la especificación. Si dicho líder decide migrar de versión, con el consenso del resto de miembros del JSR, tan sólo tiene que rellenar un formulario y enviarlo al JCP para realiar dicha migración.
¿Qué falta por hacer?
A pesar de que los cambios en el JCP han sido bastante grandes, desde SUN Microsystems afirman que todavía no son suficientes. Esta afirmación coincide con la opinión de casi todas las organizaciones y empresas vinculadas al mundo de Java. La mayor parte de la comunidad Java coincide en que loss siguientes pasos de liberalización deberían encaminarse hacia :
Liberalizar las especificaciones afectadas por los viejos JSPA que todavía mantienen las antiguas restricciones. Aquí es de esperar que poco a poco los diferentes JSR vayan migrando de versión según salgan nuevas versiones de dichos JSRs o los miembros del JSR vayan requiriendo su paso al nuevo proceso.
Liberalizar los UJSRs. La especificación de Java, así como algunos de los UJSR dode SUN Microsystems conserva derechos especiales, no se encuentra sujeta al proceso del JCP y por lo tanto no le son aplicables las nuevas políticas. Lo que anhela ahora la comunidad Java es que se liberen dichos JSRs, aunque como veremos posteriormente esta liberación no está exenta de peligros.
¿ Funciona el JCP ?
A esta pregunta podremos encontrar dentro de la comunidad Java diferentes respuestas aptas para todos los gustos, desde bendiciones hasta maldiciones de todo tipo. Frank Sommers y Sonali Shah publicaron el 31 de Enero en la revista JavaWorld[13] [14] una serie de datos estadísticos del funcionamiento del JCP durante estos últimos años que pueden aclararnos un poco más la respuesta a esta pregunta.
Hemos querido recoger estos datos en este artículo porque nos han parecido realmente interesantes y porque suponen el primer estudio estadístico sobre la realidad del JCP. Tenemos que agradecer tanto a Frank como a Sonali y como a la revista JavaWorld que nos hayan dado permiso explícito para poder publicar las figuras de dichas estadísticas y de este modo poderos hacer llegar estos datos mucho más fácilmente.
Hasta Enero del 2003 había en el JCP 220 JSRs diferentes, en fases de desarrollo muy distintas. De todos estos, durante el año 2002 se finalizaron nada más y nada menos que 44 especificaciones diferentes, un número nada desdeñable. Se espera que el número de especificaciones finalizadas en este año 2003 sea incluso superior, pudiendo rondar las 50 o 60.
En cuanto a la duración de las especificaciones, Frank y Sonali encontraron que varía mucho según la especificación. Nos encontramos con especfificaciones como el JSR-296 ( Java API for XML Processing 1.1 ), CLDC ( J2ME Connected Limited Device Configuration ) o el JSR-44 ( OSS Common API ) que no llegan a los 300 días de desarrollo mientras que otras como el JSR-24 ( JAIN SPA TSM, DS and SAM 1.0 API ), el JSR-6 ( Unified Printing API ) o ( Java SASL especfication ) superan los 1100 días de desarrollo.
Lo cierto es que estos datos alertan sobre la cantidad de desarrollos diferentes que se están produciendo dentro de la comunidad Java. Según Jason Hunter, vicepresidente de la fundación Apache, hemos llegado a un punto donde un desarrollador ya no puede colgarse el título de experto en Java debido a la gran cantidad de tecnologías diferentes que nos podemos encontrar. En una entrevista telefónica otorgada a los dos autores que estamos utilizando como referencia en este apartado, Jason Hunter admitió que existía preocupación dentro de los comités ejecutivos del JCP debido a este estallido de especificaciones y comenzaba a plantearse la posibilidad de establecer algún tipo de limitación.
Otro análisis muy interesante que ofrecen Frank y Sonali es el del número de especificaciones en el que participa cada grupo. SUN Microsystems, obviamente, se lleva la palma con 166 especificaciones, seguido de lejos por IBM que participa en 104, a continuación vienen Oracle con 69, HP con 47 y Motorola también con 47. SUN Microsystems también domina la estadística de lideración de especificaciones aunque cada vez menos, sobre todo en el ámbito de las telecomunicaciones en el que parece ceder la batuta a empresas del sector.
Estas últimas gráficas no dejan de ser un tanto sorprendentes. Si por un lado tenemos que SUN Microsystems es la empresa líder en participación, lo cierto es que si Oracle e IBM juntas participan en más especificaciones que la propia SUN Microsystems, cosa impensable hasta hace unos años. Lo mismo podríamos decir del cuarteto formado por HP, Motorola, Nokia y BEA.
En la gráfica de liderazgo llama considerablemente la atención que SUN Microsystems no llegue a acaparar el 50% de las diferentes tecnologías basadas en Java lo que disipa de algún modo la idea que todavía mantienen numersosas personas de que todo lo relacionado con Java es propiedad exclusiva de dicha empresa.
¿ Es Java Libre ?
Esta pregunta, que hasta ahora hemos visto formulada en multitud de foros, revistas, portales o publicaciones, no tiene una fácil respuesta. Para poder intentar responder lo más honestamente posible sería necesario realizar una segunda pregunta adicional: ¿Qué es Java?. Aunque parezca extraño, la respuesta a esta pregunta no es única, ya que por Java nos podemos estar refiriendo a:
Un lenguaje de programación.
Una especificación de una máquina virtual.
Una especificación de un formato binario ( código de bytes ).
Un conjunto de clases y librerías que nos permiten la realización de programas mediante un dialecto determinado.
Según a que concepto nos estemos refiriendo al hablar de Java, la respuesta a la pregunta formulada anteriormente se verá alterada. Para cualquiera de las tres primeras acepciones la respuesta es SI, Java es libre. Las especificaciones son públicas y están disponibles para todo el mundo, por lo que cualquiera puede descargárselas y crear su propia implementación del lenguaje, su propia máquina virtual o su propio formato de código, y además cualquiera puede distribuir estas creaciones libremente. De hecho una de las prácticas más comunes dentro de entornos académicos es la creación de variaciones del lenguaje, máquina virtual, compiladores de múltiples lenguajes a código de bytes, etc., para experimentación de diferentes tecnologías[49]
Si por el contrario, creemos que Java es un conjunto de librerías y clases, es decir, un kit de desarrollo, en este caso tendremos que decir que su libertad depende. ¿De qué depende? Sencillo, depende de quién haya creado dicho kit de desarrollo. Analicemos más detenidamente las posibilidades en este punto:
Utilizar el JDK de SUN MicrosystemsEl JDK[15] ( Java Developer's Kit ) es el kit de desarrollo oficial de desarrollo con Java ya que es SUN Microsystems la empresa que lo distribuye. Este SDK no es libre. Sú código fuente se distribuye bajo la licencia SCSL, licencia que como vimos es muy restrictiva. Esta licencia permite ver el código fuente pero no la realización de modificación alguna. Tampoco se permite redistribuir el kit de desarrollo ni versiones modificadas del mismo.
Utilizar un kit de desarrollo de algún licenciatario de SUN Microsystems: Otra opción que se nos plantea es utilizar un SDK proporcionado por algún licenciatario de SUN Microsystems, por ejemplo el de IBM. Estos SDKs tampoco son libres, ya que normalmente lo que se licencia es el código fuente. A pesar de que el licenciatario optiene permisos para modificar el software original y distribuirlo, no se produce lo mismo para los usuarios de éstos nuevos SDKs.
Utilizar una implementación independiente: Como hemos visto anteriormente, Java no sólo es un SDK sino que también es una especificación de un lenguaje, máquina virtual y de un formato de código de bytes. Estas especificaciones son públicas y cualquiera puede implementarlas desde cero, razón por la que existen numerosas implementaciones libres como veremos a continuación. El único requisito para dichas implmenetaciones es que no pueden llamarse Java ( palabra propiedad de SUN Microsystems ). Estas implementaciones, incluso pueden certificarse como compatibles con Java aunque esto requeriría ya el pasar a ser licenciatario de SUN Microsystems. Ejemplos de este tipo de implementaciones son GCJ[16] o Jikes [17]
Los posibles peligros de una liberación
Mucha gente opina que SUN Microsystems debería liberar su kit de desarrollo, de modo que fuese posible utilizar su código fuente para realizar modificaciones y mejoras. Una nueva pregunta que nos podríamos plantear sería: ¿ Pondría dicha liberación en compromiso a la plataforma Java ? La opinión de SUN Microsystems es que sí.
SUN Microsystems no desea liberar el código fuente de su SDK por una razón muy simple: Si lo libera, ¿ cómo podría garantizarse entonces la condición de _Write Once and Run Anywhere_ ? Muchos expertos opinan que no se podría, ya se han dado casos como el de Visual J++, donde empresas como Microsoft han creado variaciones importantes del lenguaje que ponen en serio compromiso la condición de multiplataforma del mismo.
Sin embargo, no son pocos los que abogan por una liberación definitiva del código fuente de Java. Incluso empresas como IBM afirman que es un paso fundamental[18], y que debería haberse producido hace ya mucho tiempo.
Ahora bien, según Danese Cooper, ejecutivo de SUN Microsystems, son muchas las reuniones que ha habido ya con líderes del mundo Open Source y miembros de SUN Microsystems y ambos concordaban en una cosa: la compatibilidad obligatoria y el software libre no pueden coexistir.
Este último concepto es bastante interesante y seguro que a más de uno os ha hecho exclamar un ¡¿Cómo?!. Expliquémoslo un poco más detalladamente. Ahora mismo, la licencia de los UJSRs, como por ejemplo la del kit de desarrollo, establece un corsé que limita la aparición de implementaciones que se aparten de la especificación. La licencia claramente explicita que no se pueden crear ni superconjuntos ni subconjuntos de dichas especificaciones, por lo tanto es ilegal realizar implementaciones que se aparten de lo estríctamente marcado ( cómo sucedió con la implementación de Microsoft ). Liberar los UJSRs permitiría la creación de implementaciones libres y por lo tanto legitimaría la ampliación o reducción de lo marcado por una especificación y como consecuencia se daría pie a que implementaciones devaluadas se hiciesen con el mercado aprovechándose de condicionantes externos.
¿Dónde está pues el punto de equilibrio ? La solución desde luego no es sencilla. Aunque el tiempo lo dirá, la opción más sensata probablemente sea el paso de la especificación del lenguaje al seno del JCP para de este modo permitir la participación de toda la comunidad en su evolución.
Implementaciones libres
SUN Microsystems ofrece el código fuente de su SDK para consulta, pero nadie puede modificarlo ni redistribuirlo sin ser un licenciatario de su tecnología.
En la actualidad son tres las plataformas basadas en el lenguaje Java. Estas tres plataformas se diferencian en los dispositivos hacia los que están enfocados.
Por una parte tenemos J2ME, una plataforma pensada para el desarrollo de aplicaciones en pequeños dispositivos como teléfonos móviles, tarjetas inteligentes, set-top-boxes, etc.
Por otra parte tenemos J2SE que es la plataforma estándar de Java. Esta plataforma está enfocada al desarrollo de aplicaciones para ordenadores personales y estaciones de trabajo.
Por último tenemos la plataforma empresarial, J2EE. Esta plataforma se cimienta en la plataforma estándar y está pensada para el desarrollo de aplicaciones que se ejecutarán en servidores y mainframes.
Soluciones libres bajo J2ME
Debido al escaso tiempo que ha transcurrido desde la salida de las primeras versiones de CLDC y MIDP al mercado, lo cierto es que el número de implementaciones libres de J2ME es muy escaso o prácticamente nulo. Existen gran cantidad de implementaciones comerciales como las de Insignia [19], Esmertec [20] o NSI [21], pero parece que por ahora los grupos de desarrollo libres no se han animado a crear implementaciones sólidas de la plataforma móvil de Java.
La principal razón de esto seguramente radique en que los dispositivos móviles normalmente ya traen incluida una máquina virtual, por lo que muchos desarrolladores se limitan a crear aplicaciones para dichas implementaciones en lugar de intentar crear nuevas soluciones mejoradas.
De todos modos, existen algunos proyectos recientes, que aunque no implementan la plataforma J2ME, si que han tenido cierta repercusión dentro del mundo de los pequeños dispositivos. Estamos hablando de Waba y alguna de sus ramificaciones de las que entraremos en más detalle a continuación.
Waba
Waba [22] fué una de las primeras máquinas virtuales para dispositivos móviles. Fue creada a principios del 2000 por Rick Wild, bajo licencia GPL, pero a pesar de tener un éxito relativo, su autor no continuó con su desarrollo. Aún así, el proyecto inicial sirvió como base a dos nuevas iniciativas: la primera intentó continuar el desarrollo de Waba bajo SourceForge[23], pero sin demasiado éxito; por su parte, la segunda iniciativa desembocó en la creación de SuperWaba[24], máquina virtual de la que hablaremos posteriormente y que todavía se mantiene activa.
Waba se desarrollo inicialmente para PalmOS y Windows CE, pero a pesar de que no se continua con su desarrollo ni se ofrece soporte, ha sido una plataforma lo suficientemente interesante para que programadores independientes la hayan portado a otros dispositivos, como por ejemplos PCs con MS-DOS, Nintendo GameBoy y PDAs Zaurus con Linux.
SuperWaba
SuperWaba [24] es una máquina virtual y entorno de ejecución para dispositvos móviles, distribuida bajo LGPL y con soporte para PalmOS, Windows CE y Pocket PC. El proyecto trata de autofinanciarse ofreciendo soporte técnico.
SuperWaba se creo a partir de Waba, pero su desarrollo ha sido totalmente distinto, siendo en este caso muy activo y donde se ha ampliado toda la funcionalidad que ofrecía el original Waba. Aún así, este proyecto sigue siendo un 99% compatible con la funcionalidad que ofrecía su predecesor.
SuperWaba tiene una comunidad relativamente grande y activa, además de un producto competitivo. Al igual que Waba, presenta el gran problema de ser una plataforma , aún escrita en Java, totalmente propia. Las clases a usar son propias de Waba/SuperWaba, y no tienen nada que ver con J2ME.
Soluciones libres en J2SE
J2SE es sin duda la plataforma Java más utilizada por tratarse de la plataforma estándar y en la que se basan tanto la plataforma móvil como la empresarial. Como ya hemos visto, la licencia del kit de desarrollo de SUN Microsystems pone demasiadas trabas para el desarrollo de software libre. Existen una serie de kits de desarrollo adicionales que sin embargo nos permiten crear este tipo de software sin ninguna limitación.
En los siguientes apartados veremos implementaciones más abiertas que la de SUN Microsystems. En primer lugar hablaremos de kits de desarrollo, que aunque no son libres desde un punto de vista estricto, lo cierto es que ofrecen mucha más libertad en aspectos como la libre distribución por lo que pueden ser de gran interés para muchas personas. Por último veremos más en profundidad detalles sobre otros kits de desarrollo y máquinas virtuales absolutamente libres.
Alternativas al JDK de SUN Microsystems
Aunque no son máquinas virtuales completamente libres, la verdad es que la importancia de alguna de estas máquinas virtuales nos obliga a nombrarlas, aunque no entremos en detalles sobre las mismas. Existen una serie de máquinas virtuales, ofrecidas en algunos casos por licenciatarios de SUN Microsystems, con licencias mucho más permisibles que la SCSL.
Dentro de este grupo se encuadra por ejemplo Blackdown, el primer JDK que estuvo disponible para Linux. Aún cuando SUN Microsystems no tenía intención de portar su SDK a Linux, ofreció su colaboración y de este modo el equipo de Blackdown y el equipo de Blackdown tuvo acceso al código gratuitamente, aunque el resulrado de su trabajo siguiera la misma licencia que la otorgada por SUN Microsystems al JDK original.
Otra máquina virtual con una licencia mucho más relajada es la de IBM. Esta máquina virtual ofrece también su código fuente de manera gratuita, y lo que es más importante, no limita de ningún modo su redistribución.
Soluciones totalmente libres
A diferencia de las anteriores, las máquinas virtuales que vamos a ver a continuación son totalmente libres. Estas implementaciones se denominan también cleanroom, quiere esto decir que son implementaciones que parten absolutamente desde cero y que no toman como referencia ni una sóla línea de código de la implementación original de SUN Microsystems o de otro licenciatario de Java, ya que en caso contrario se trataria de implementaciones ilegales.
Para poder participar en estas implementaciones es necesario no haber aceptado nunca la licencia SCSL para el kit de desarrollo de SUN Microsystems. Esto se traduce en que un desarrollador que se haya descargado alguna vez el código fuente de dicho kit de desarrollo, y lo haya estado utilizando, no puede hacer uso del conocimiento adquirido a partir de la lectura y análisis su código fuente.
Kaffe
Kaffe [25] es una implementación del entorno de ejecución de Java auspiciada por la empresa Transvirtual Technologies Inc. [26]
Kaffe esta disponible para una gran variedad de arquitecturas, entre las que estan i386, Sparc, PowerPC, StrongARM, y sistemas operativos como Linux, FreeBSD, Solaris, Irix, etc, y esta disponible en versiones comerciales y de escritorio (esta bajo GPL). Kaffe se hizo famosa por soportar gran parte de las extensiones que realizó Microsoft en su JDK, haciéndolas ejecutables es distintas plataformas.
Como entorno de ejecución contiene todas las herramientas necesarias para ejecutar programas (JVM, appletviewer, etc), pero también aporta las necesarias para el desarrollo, ya sea por medio de incluir otros productos open source (como el compilador KJC de KOPI) o enlaces a las herramientas proporcionadas por SUN Microsystems en su JDK.
La última versión estable es la 1.0.7, de Julio del 2002, y no tiene soporte completo para JDK 1.2.
Japhar
Japhar [27] es una implementación realizada por The Hungry Programmers [28] distribuida bajo licencia LGPL. Japhar no es una implementación completa de la plataforma J2SE sino que se trata únicamente de una máquina virtual. La principal consecuencia de esto es que Japhar necesita una implementación externa del resto de clases de la plataforma J2SE para ser realmente de utilidad.
La última versión estable del proyecto es la 0.11, de Junio del 2002, e implementa gran parte de JDK 1.1 y algo de JDK 1.2.
GNU Classpath
GNU Classpath [29] es una implementación con licencia LGPL y relacionada directamente con la Free Software Foundation. En un principio el proyecto estuvo muy ligado a la JVM Japhar, pero en las últimas versiones se han ido separando hasta el punto de que Japhar ya no puede ejecutar las clases de Classpath en su totalidad.
Aún no existe ninguna versión estable liberada de Classpath, por lo que solo se puede obtener a través del acceso directo a su árbol CVS o versiones alfa disponibles de vez en cuando.. La razón de dicha decisión es la de esperar a tener implementada una funcionalidad que pueda ser de suficiente interés para los usuarios, y que de momento es practicamente completa para la versión 1.1 del JDK y bastante avanzada para la 1.3, trabajándose ya en algunos puntos hacia la compatibilidad con el JDK 1.4. No os dejeis intimidar por versiones alfa, por ejemplo con el de la versión actual, la 0.05 (la más actual), puesto que eso solo indica hasta donde quieren llegar, no donde estan (como hemos dicho, con gran parte de la compatibilidad con JDK 1.3 terminada).
Las librerías GNU Classpath son utilizadas por gran cantidad de proyectos libres, como por ejemplo GCJ [17], Jikes RVM [30], Kissme [31], SableVM [32] o e-Leos [33], e incluso por varios productos comerciales, como IPJV [34] o JamaicaVM [35].
En la actualidad, y puesto que ambos proyectos estan auspiciados por la Free Software Foundation se está llevando a cabo, aunque lentamente, la unión de este proyecto con GCJ, máquina virtual de la que hablaremos posteriormente.
GNU Classpath Extensions
Classpath extensions [36] es el proyecto GNU destinado a implementar todas esas APIs que forman parte de la plataforma Java y que no son partes del kit de desarrollo estandar, como podrían ser JavaMail, JAXP y Java Servlets.
Entre las APIs ya funcionales se encuentran Servlets 2.3, javax.net, JAXP y JavaMail, estando en proceso de desarrollo otras como Java Activation Framework y Java Cryptography Architecture. Este proyecto es uno de los más interesantes para participar ya que muchas de estas APIs están siendo migradas a licencias más libres dentro del JCP que permiten su uso indiscriminado.
GCJ
GCJ ( GNU Compiler for Java ) es otro proyecto auspiciado por la Free Software Foundation y que como hemos dicho está en proceso de unión con Classpath. GCJ es un compilador que es capaz de compilar código Java a código de bytes o a código nativo de plataforma. Adicionalmente GCJ puede transformar código de bytes en código nativo. En ambos casos, el código nativo resultante es enlazado con la librería libgcj, distribuida bajo licencia GPL y que es donde están implementado el SDK de Java y el propio entorno de ejecución.
El estado de GCJ es similar al de Classpath (gran soporte para 1.1, bueno para 1.3 y trabajando en la 1.4) en lo referente a las partes fundamentales del API (java.lang, java.io, java.util, java.net, etc), aunque no tiene soporte para AWT (y mucho menos Swing), pero el trabajo para soportarlo esta ya en marcha, y su unión con Classpath, con ya mucho soporte para AWT y Swing terminado, puede convertirlo en una herramienta de gran potencial
Se está realizando también un trabajo importante en la integración de libgcj con las librerías SWT del proyecto Eclipse, que son unas librerías gráficas para Java capaces de usar el API nativo de la plataforma para crear interfáces de usuario. Como indicativo de esto, decir que ya es capaz de ejecutar el entorno de desarrollo Eclipse [37] [38].
GCJ esta disponible para una gran número de arquitecturas,como i386, Itanium, PowerPC, Sparc o ARM, y sistemas operativos, como GNU/Linux, Windows, FreeBSD, Irix o Solaris, formando parte del compilador GNU GCC, pudiendo hacer uso de todas las herramientas relacionadas, como el depurador GDB.
GCJ, junto con Classpath y Jikes, son sin duda la punta de lanza del desarollo de soluciones libres para la plataforma Java, y sin duda uno de los proyectos más activos y a tener en cuenta.
Jikes
Jikes es un compilador de código fuente a código de bytes de Java, creado por la sección Alphaworks [39] de IBM, y se trata de un producto totalmente libre, liberado bajo la licencia IBM's Public License [40]. Aunque se creo dentro de IBM, hoy en día ningún miembro de IBM esta dedicado al proyecto, siendo éste un proyecto en el que participan desarrolladores de todo el mundo.
Jikes es estríctamente compatible con las especificaciones del lenguaje Java y con la de la máquina virtual de Java, y pasa por ser el compilador más eficiente que existe para este lenguaje. Jikes además presenta características únicas como la compilación incremental, no presente en otros kits de desarrollo como el de SUN Microsystems.
Existen binarios disponibles para Windows, Linux y AIX, sobre arquitecturas i386 y PowerPC, aunque a partir del código se han conseguido fácilmente binarios para FreeBSD y OS X entre otras plataformas.
Por último, recordar que Jikes es sólo un compilador, y que será necesario conseguir las clases del API de Java de algún otro modo, ya sea de algún JDK licenciado o utilizando las del proyecto Classpath que vimos anteriormente.
Otras implementaciones
Otras máquinas virtuales interesantes, en fases de desarrollo, aunque menos conocidas son Kissme, SableVM o Jikes RVM, siendo esta última una versión de Jikes enfocada al mundo de la investigación y que está siendo utilizanda en gran cantidad de proyectos, donde diferentes investigadores realizan pruebas sobre diferentes aspectos como técnicas avanzadas de recolección de basura, paralelismo, control de concurrencia, etc.
Lamentablemente, como en muchas otras ocasiones, muchos otros proyectos han perecido sin llegar a su destino, como porejemplo ElectricalFire [41], la máquina virtual auspiciada por Netscape y Mozilla.
Soluciones libres en J2EE
J2EE, la plataforma empresarial de Java, está más de moda que nunca. Con más de cinco años de vida, esta plataforma basada en especificaciones abiertas está suponiendo uno de los mayores nichos de software libre que podemos encontrar en la actualidad en todo el panorama informático. En, "Arquitectura Empresarial y Software Libre, J2EE" [1], describimos como crear una arquitectura empresarial basada única y exclusívamente en productos libres y describimos gran cantidad de éstos.
Aunque el número de referencias sobrepasaba los ochenta productos, lo cierto es que el número de proyectos libres que se alojan bajo la cúpula de influencia de la plataforma empresarial de Java es muchísimo mayor. Aún así, en este artículo nos centraremos tan sólo en las implementaciones libres de J2EE, es decir, en los servidores de aplicaciones.
JBoss
Jboss[42] es el servidor de aplicaciones libre por excelencia. Su licencia es LGPL y está implementado al 100% en Java. Tiene más de 150.000 descargas mensuales lo que le convierte en el servidor de aplicaciones más descargado del mundo. JBoss está abalado por un grupo de desarrollo formado por arquitectos con gran experiencia y repartido por todo el globo.
La serie 3.x de JBoss soporta el estandar J2EE 1.3. Entre sus características destacan su nueva base sobre la especificación JMX, el soporte de EJB 2.0 y la posibilidad de crear clusters. Otra de las cosas más interesantes de este servidor de aplicaciones es que lo podemos descargar en versiones que integran Apache Tomcat[43] o Jetty[44] como contenedores web.
De JBoss es que rotúndamente podemos afirmar que es un gran ejemplo para toda la comunidad de software libre. El grupo JBoss es una entidad con ánimo de lucro que está obteniendo grandes beneficios a partir de la venta de documentación, consultoría, formación y seminarios y servicios en general. Fruto de toda esta actividad, JBoss aglutina acuerdos con numerosas firmas comerciales como BASF, Motorola, MacDonalds, Nortel, WorldCon, Down Jones Indexes o gobiernos como el alemán, el noruego o el de Estados Unidos.
Una anéctoda curiosa sobre JBoss se remonta a Enero del 2003 cuando al responsable de GetThere, una empresa dedicada a la venta online de viajes turísticas, le preguntaron si no tenía miedo de utilizar dicho servidor de aplicaciones en sus proyectos. La respuesta fue contundente: "JBoss nos ha ahorrado 1.6 millones de dólares el año 2002. Además, tenemos el código fuente, ¿qué nos puede pasar?"
Por poner algunos datos más, recientemente la empresa TogetherSoft realizó una encuesta entre sus clientes en la que se encontró que el 43% de los encuestados estaban utilizandoJBoss como desarrollo, siendo el siguiente servidor de aplicaciones utilizado BEA WebLogic con un 26%. Aunque estos datos se refieren únicamente a entornos de desarrollo no dejan de ser llamativos. Además, JBoss está siendo alabado en todo el mundo y prueba de ello es la elección por parte de los lectores de las prestigiosas revistas Java Developer's Journal y JavaWorld como mejor servidor de aplicaciones del año 2001.
A principios de Diciembre del 2002, JBoss recibió la luz verde por parte de SUN Microsystems para comenzar su proceso de certificación como compatible con la plataforma J2EE 1.4. Jboss será el primer servidor de aplicaciones libre que reciba el galardón de certificado y demuestra que el proceso de apertura de Java está comenzando a dar sus frutos.
Este proceso está perjudicando a numerosas compañías como BEA o Pramati que basan su línea de negocio prácticamente de manera exclusiva en la venta de servidores de aplicaciones. Estas empresas por una parte se encuentran conque los gigantes de la informática como IBM u ORACLE se pueden permitir el lujo de "regalar" sus servidores de aplicaciones a cambio de otra serie de productos de su extensa gama. Por otra parte, estas empresas comienzan a ver como servidores como JBoss se van haciendo poco a poco con otra gran parte del pastel, debido a que su prestigio va creciendo exponencialmente. Todo esto hace que comiencen a aparecer rumores de crisis, como por ejemplo el caso de BEA en Febrero del 2003.
JOnAS
Aunque quizás no tan conocido como JBoss este servidor de aplicaciones, por sus características, es uno de los proyectos más ambiciosos del mundo del software libre en Java y no sería de extrañar que pronto superase a JBoss en aceptación.
JonAS[45] surgió en el 1999 y actualmente se encuentra ya por la versión 3.0. Entre sus características más notables está el soporte de EJB 2.0, incluido CMP 2.0, la integración de productos de software libre como Apache Tomcat como contenedor web o JORAM como sistema de mensajería. Además tiene la ventaja de que incluye herramientas adicionales como una utilidad de administración o un generador automático de EJBs. La documentación de JOnAS está disponible gratuitamente en su página web.
JonAS está abalado por un importante consorcio, ObjectWeb[46]. Este consorcio formado por empresas como Bull, France Telecom o Inria centra sus esfuerzos en la creación de software libre para el desarrollo de aplicaciones empresariales. Productos como JORAM[47] o Enhydra[48] forman parte también de los proyectos alojados por este consorcio y su integración con JOnAS es excelente.
Conclusiones
El JCP es el organismo encargado de controlar la evolución de las diferentes plataformas y tecnologías basadas en Java. Es el organismo que decide que especificaciones se aprueban, que especificaciones se rechazan y que controla la evolución de dichas especificaciones.
El JCP está formado por gran cantidad de empresas, no se trata de un organismo unilateral. Además, como hemos visto, dichas empresas participan activamente dentro del proceso de desarrollo y controlan gran cantidad de especificaciones.
La liberación del JCP ha abierto definitivamente las puertas al mundo del software libre. Las nuevas condiciones de la licencia de participación dentro del JCP son mucho más abiertas y permiten la realización de especificaciones, implementaciones de referencia y tests de compatibilidad con licencias libres lo que además de beneficiar a la evolución del software libre, legitima todas las implementaciones anteriores de especificaciones.
La plataforma Java es una plataforma abierta donde todo el mundo puede participar y opinar. Cualquiera puede participar dentro del JCP y opinar sobre las diferentes especificaciones durante las fases de revisión pública. Además, ahora con la nueva licencia de participación el JCP ha abierto sus puertas a las organizaciones sin ánimo de lucro y entidades académicas.
Existen bastantes implementaciones libres y algunas de ellas están teniendo mucho éxito. Poco a poco, como en el caso de JBoss, dichas implementaciones van madurando y le están comiendo cada vez más terreno a las implementaciones comerciales.
Alberto Molpeceres Touris trabaja como desarrollador J2EE en Alemania para la empresa T-Systems del grupo Deustche Telekom
Martín Pérez Mariñán
Martín Pérez Mariñán trabaja en España para INTECNO, una empresa del Grupo DINSA, desarrollando aplicaciones empresariales para el Hospital Juan Canalejo de A Coruña. Martín es Ingeniero de Sistemas por la Universidad de La Coruña además de SUN Certified Java Programmer y SUN Certified Java Developer.
Desde el 20 de marzo se encuentra disponible la nueva especificación del lenguaje, la 1.1. Para celebrar el centenar de descargas de la MuSE (Munki Standard Edition) se lanza su versión 1.3.1 con soporte para la nueva especificación y mejoras en el intérprete y el paquete 'filesystem'.
viernes, marzo 21, 2003 at 11:01AM 
