y tu… aún usas Tomcat???

Aunque el título es “algo” sesgado, me propongo en este post hacer, de manera no tan humilde, una comparación entre 2 servidores de aplicaciones: Tomcat y GlassFish. Primero que todo, un servidor de aplicaciones, desde una mirada muy somera, no es más que una especie de contenedor, desde el cual se muestran y ejecutan las paginas web, hechas por los desarrolladores. Tomcat es quizás uno de los primeros servidores de aplicaciones, open source, realizado por la comunidad Apache, algunos empleados y  ex-empleados de Sun. Si bien es cierto que en un comienzo Tomcat marcó la pauta en el desarrollo web (de hecho fue donde di los primeros pasos en el manejo de JSP’s), la llegada de GlassFish y Java EE 5 le asestó un golpe del cual difícilmente se podrá recuperar.

Cabe resaltar que Tomcat no es más que un contenedor web, mientras que GlassFish es un conjunto de contenedores de Java EE, dentro de los cuales esta el contenedor web. Esto permite que, entre otras cosas, GlassFish no solo se limite a interpretar jsp’s, sino que brinda compatibilidad con tecnologías de vanguardia como php, ruby, jruby, desde el arranque sin necesitar mayor configuración. Esto implica que bajo GlassFish se puedan correr las aplicaciones hechas para Tomcat sin mayores cambios o configuraciones, lo más seguro es que funcionen de primera. Además cuenta con funcionalidad de cluster y balanceo de carga que permite tener varios servidores respaladando una misma aplicación, incluso se pueden crear servidores virtuales por cada máquina, que solo respondan a determinados puertos. Otra desventaja de Tomcat, sino es la principal, es que NO es 100% compatible con Java EE 5, lo cual es un gran inconveniente en un ambiente productivo, donde se necesitan contar con todas las herramientas disponibles.

Asi como comenté en un post anterior, GlassFish v2, cuenta con un centro de actualización, desde el cual se puede instalar, o actualizar módulos del servidor de forma fluida y sencilla, además la nueva versión, GlassFish v3 Prelude tiene un “preview” de las nuevas tecnologías disponibles en Java EE 6, como por ejemplo JSF 2.0 JPA 2.0. Otra razón para escoger GlassFish es el manejo que se le da a la seguridad, pues permite meadiante la tecnologia “realm” para manejar el login a una aplicación ya sea a través de LDAP, una BD, o un archivo tal y como lo muestra este  tutorial que utiliza NetBeans 6.5

Como vemos GlassFish es más que un contenedorr para desplegar páginas web, es una herramienta muy interesante, que brinda muchas funcionalidades de una manera muy sencilla, incluso para ambientes de producción y a un bajo costo, pues es un producto open source, aunque también cuenta con una linea comercial. Si bien Tomcat ha muchos nos sirvió y algunos siguen utilizando, espero que éstos últimos al menos le den una mirada a GlassFish y lo prueben, no se arrepentirán.

Como empaquetar una aplicación en un solo jar con NetBeans 6.x

Al realizar una aplicación desktop en NetBeans, nos damos cuenta que se crea un .jar con el nombre de la aplicación, pero, si utilizamos alguna libreria extra (de terceros, o un proyecto  distitnto, por ejemplo), entonces NetBeans crea además una carpeta llamada “lib”. Donde residen los jar’s de dichas librerías. Algunas veces, por seguridad o comodidad he deseado empaquetar todo esto en un solo archivo .jar. Pues bien en este artículo publicado en Sun Developer Network (SDN), Robert Eckstein nos dice como hacerlo modificando el archivo build.xml de la aplicación.

…y ahora qué?

Es la pregunta que nos estamos haciendo muchos de los usuarios de productos de Sun, luego de que ya han pasado algunos meses desde la noticia de la compra de la compañía por parte de Oracle. Muchas dudas, muchos rumores, pero aún ningún pronunciamiento oficial por parte de alguna de las dos compañías que nos dé una verdadera luz de guía.

Por un lado los usuarios que trabajan (o trabajamos) día a día con aplicaciones open-source de Sun como NetBeans, MySQL, OpenSolaris, GlassFish, VirtualBox, etc. Muchos desarrolladores, pequeñas, medianas (e incluso grandes) empresas utilizan al menos uno, sino varios, de estos componentes, y se preguntan que suerte correrán estos productos con la llegada de Oracle: ¿desaparecerán?, ¿serán reemplazados?¿dejarán de ser “free”? En mi humilde opinión, considero que estos productos seguirán en pie por mucho tiempo, y bajo las mismas condiciones actuales. La razón es muy simple, todos ellos tienen algo en común; una comunidad open-source. Precisamente para ser open-source, un producto debe estar soportado en una comunidad que (básicamente) lo regule, desarrolle nuevas funciones y corrija “bugs”. La “comunidad” hace rato dejo de ser algo en donde todas o la mayoría de personas involucradas pertenecen a la compañía “dueña” del producto. Por ejemplo, en el caso específico de NetBeans, con un solo click puedes reportar un bug en el IDE, o en listas de correos puedes preguntar y contestar inquietudes a personas de otras ciudades y países, personas comunes y corrientes que aportan su conocimiento sin esperar nada a cambio, salvo quizás mayor conocimiento. Asimismo, existe un grupo inmenso de personas que se encarga de traducir el IDE a 10 o 20 idiomas, todos los días alguien hace un nuevo plugin con una nueva funcionalidad (un reproductor de música, un driver, compatibilidad con un nuevo framework, etc). De esa manera miles de personas NO involucradas con Sun hacen crecer al IDE de manera desinteresada, o bueno si tienen un interés: mejorar el producto. Este patrón de colaboración entre personas del común se repite en todos los demás productos open-source, lo cual considero nos garantiza su existencia por un buen tiempo.

Por otro lado, tenemos los productos licenciados como por ejemplo MySQL Enterprise que que tampoco creo que vayan a desaparecer de la noche a la mañana. Es bien sabido que muchas empresas tienden a ser renuente a cambiar por ejemplo su sistema operativo, o su motor de base de datos, etc. La razón es el temor a los traumatismos que dichas migraciones puedan generar (tiempos, costos, etc), en comparación con la poca o nula mejoría que note el usuario final, todos sabemos como son los usuarios finales, a menos que los datos se teletransporten frente a sus ojos y haya destellos de luces cósmicas, el sistema siempre será lento! ¿Un cambio de motor?¿¿Antes era Diesel??. Por eso tampoco veo en un futuro cercano a Oracle obligando a sus recien adquiridos clientes a pasarse a un nuevo motor de BD, eso sí, seguro habrán cambios en las condiciones de licenciamiento (precio, cantidad, tiempo, etc). En el mercado existen muchas personas que se dedican casi que exclusivamente a ayudar a las empresas a traducir y entender los contratos de licenciamiento de Oracle, esto refleja la complejidad de dichos contratos. Además, se rumora que Oracle aprovechará esta nueva adquisición para visitar clientes (nuevos y viejjos) y realizar auditorías, lo cual sería como excusa para replantear condiciones de licenciamiento.

Por último, a los que temen que Java desaparezca, (y es una inquietud que he oído con frecuencia…) les digo: ¿cuanto tiempo lleva desapareciendo COBOL? =P

Nimbus Look & Feel

Desde el JDK 6 release 10 (jdk6u10), está disponible un nuevo Look & Feel para las aplicaciones en Java: Nimbus Look & Feel. El cual tiene una manera de funcionar muy particular y distinta a como venían funcionando los L&F anteriores.

Para invocarlo simplemente escribimos en el “Main” de nuestra aplicación:

public static void main(String[] args) {
        // TODO code application logic here
        for(UIManager.LookAndFeelInfo laf:UIManager.getInstalledLookAndFeels()){
            if("Nimbus".equals(laf.getName()))
                try {
                UIManager.setLookAndFeel(laf.getClassName());
            } catch (Exception ex) {
            }
        }
    }

No es recomendable poner el L&F directamente asi:

try {
       UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");
     } catch (Exception ex) {// Manejo de excepción...
                                     }

Por varias razones. La principal es que a partir de Java 7, el L&F Nimbus cambiará de paquete y se ubicará en javax.swing.plaf.nimbus. Muchos se preguntarán “Y por qué no lo pusieron ahi desde que lo crearon?” La respuesta es sencilla; Los paquetes java.* y javax.* no pueden ser modificados en releases menores. Por otro lado, nada nos garantiza que nuestra aplicación se vaya a ejecutar en un cliente con jdk6u10 o superior instalado.

Una de las grandes ventajas de Nimbus sobre los otros L&F’s es que este no se encuentra basado en Bitmaps, sino que todo se basa en Vectores, los cuales permiten tener mayor precisión al pintar el componente, sobretodo cuando se agrandan o reducen componentes, cuando se maximiza o restaura una aplicación.

Existe una aplicación de prueba llamada Laffy, con la cual se puede observar todos los componentes Swing, con el L&F de Nimbus. Una vez descarguen jdk6u10, o superior instalado pueden hacer click aqui para darle un vistazo a Laffy y por supuesto, el más reciente Look and Feel de Java; Nimbus. He aqui un vistazo a Laffy.

Nimbus Look & Feel

Los invito a todos a probar en sus aplicaciones este nuevo L&F, seguro sus clientes (o su jefe ;-) ) se mostrarán sorprendidos!

NetBeans 6.7, el próximo release del NetBeans IDE: Tip 1 (Ergonomic)

Luego del exitoso lanzamiento por parte de NetBeans.org de la versión 6.5 y 6.5.1 (versión mejorada del 6.5) de su IDE, vino el anuncio lanzamiento de la versión 6.7 del mismo. Esta versión aún no alcanza su etapa final, sin embargo, esta llena de cambios y mejoras. Hoy hablaré de una de ellas, disponible a partir de Netbeans 6.7 Milestone 2; defininda por el mismo NetBeans Team como “Ergonomic”, ya que permite al IDE acomodarse a las necesidades del desarrollador, cargando solamente los módulos que el/ella necesite.

Cuando por ejemplo instalamos la versión “All” o completa del IDE y vamos a revisar los plugins y y módulos disponibles (Tools->Plugins->Installed), veremos (y sin motivo para alarmarnos…) que muchos de los módulos del IDE están desactivados, y prácticamente estan activos los que pertenecen a la parte base del IDE, como lo muestra la imagen:

Lista de plugins para NetBeans 6.7M3

Los módulos no activos, se activarán según lo requiera el usuario. Por ejemplo, si vamos al wizard para crear una nueva aplicación web, cuando intentamos crear dicho proyecto, en la segunda ventana del asistente, aparecerá un mensaje como este:

Activándose...

Esta característica de acivar módulos por demanda, un poco extraña, inicialmente, busca evidentemente aliviar un poco la carga de trabajo del IDE, pues solo trabaja con las clases que necesita, evitando utilizar carcaterísticas que quizás nunca utilicemos (C++, por ejemplo…).

Cabe aclarar que una vez estos módulos se activan no se vuelven a desactivar, a menos que el usuario así lo indique. Una vez más gracias a todos por leer mis posts, hace un año y unos pocos días que me mudé a wordpress y van casi 20K visitas, simplemente gracias!!! :-)

Nota: para aquellos que se estén preguntando por qué saltaron de 6.5 a 6.7, la razón es tan sencilla como curiosa; no querían que se asociara al IDE con el número 6.6…6, jejej, veanlo aquí ;-)