Category Archives: Java

¿Cuántos programadores Java hacen falta…

…para redondear en potencia de dos al alza un número?.

Apple vs Sun, Leopard sin soporte para Java 6

La nueva versión del sistema operativo de Apple, ese que usa la gente cool, OS X Leopard ha sido publicado y me ha llamado bastante la atención su curiosa “feature” de no soportar Java 6. Si Apple dio un gran golpe bajo a Sun al no incorporar Java en su iPhone, este nuevo movimiento es toda una declaración de guerra, cuanto menos. Movimiento digno de Microsoft.

Se pueden ver numerosas protestas de usuarios que se sienten traicionados. Desde luego es una buena táctica para perder mercado, y alejarse totalmente del sector empresarial. Tarde o temprano, supongo, que deberá soportarlo pues no es que sea una tecnología minoritaria que digamos. Eso si, en vez de eso, Leopard te incluye de serie Ruby y Ruby on Rails, parece ser que no se han enterado que ha muerto.

Ahora mismo me viene a la mente el acuerdo no muy lejano entre Sun y Canonical para la incorporación de paquetes en Ubuntu para el desarrollo de aplicaciones en la plataforma Java. Mmmm… Mac OS X & Ruby VS Ubuntu & Java, mejor no haré comentarios más profundos, que me entra la risa floja.

Ahora si que se puede decir con plenas palabras que OS X es cool que te cagas, pues a todos los desarrolladores de la plataforma Java (el lenguaje más usado actualmente) les impide trabajar. Así te puedes dedicar a oír cosas con el iTunes, mirar tus fotos en el iPhoto y molarte a ti mismo con el iPichas. Cada vez estoy más convencido en pillarme un mac de esos, si me apuras, incluso dos. Con patatas, por favor.

Por cierto, mención especial a este post de un usuario de macs expresando su frustración en forma de código Java, enorme.

Curso online sobre Java y Web Services

java logo En JavaPassion.com Sang Shin, evangelizador de tecnologías Java, ofrece cursos online gratuitos sobre diversos campos Java. Estos cursos consisten en una serie de contenidos preparados por el propio Sang, tareas a realizar para enviárselas y un foro para comunicación de problemas, preguntas, comentarios, etc… Tiene un curso sobre Java en general, posiblemente no muy útil para cualquiera que haya programado ya en esta plataforma, pero un filón de oro para quien quiera aprender y comenzar en Java; otro sobre AJAX, un tanto ambicioso y demasiado disperso en cuanto a temario para mi gusto; otro sobre J2EE que parece realmente interesante, aunque bastante duro, pues toca muuuchas cosas, pero muchas; y, finalmente, otro de servicios Web.

Pasado mañana, viernes 24, comienza el curso sobre servicios web, no parece que haya que dedicar mucho tiempo, no porque trate pocas cosas, sino porque tiene una duración bastante larga. Así resumiendo, los temas más importantes que se tratan son:

  • JAXB y JAX-WS: nuevas apis de java para XML Binding y Web services, la primera la uso hasta para hacer el café y la segunda no me gustó nada cuando la probé, y no soy el único
  • SOAP & REST: REST powah, muerte a SOAP.
  • Otros modelos SOA: BPEL, JBI, Open ESB.
  • Seguridad, gestión y rendimiento en servicios Web

Al final, si has enviado todos los ejercicios y participado activamente en las discusiones, te da un diploma. Te podrías hacer el diploma con Gimp, si, pero no sería lo mismo y lo sabes ;). Por las impresiones de gente que ha cursado otros cursos, parece que malos no son. Una lastima no haber conocido la página antes (por ejemplo cuando me tocó aprender Java).

Por mi parte, dentro de dos días comenzaré con las primeras transparencias. Muchas cosas las conozco, pero sobre todo los últimos temas creo que serán bastante interesantes.

Actualización Abril 2008: ya terminó hace unos meses, y tengo mi diploma :).

Simple Google Web Toolkit plugin for Maven2

GWT es un toolkit que te permite programar interfaces web mediante Java, que luego son compiladas para producir html, javascript y css. Como toda aplicación Java, hay que tener preparado algún método para empaquetar y distribuir dicha aplicación. La mejor alternativa actualmente es Maven, como expliqué en un post anterior. Maven se integra perfectamente cuando desarrollas una aplicación web en Java, permitiéndote crear archivos war listos para ser instalados en cualquier contenedor de servlets fácilmente.
 
Actualmente existen plugins para maven para poder usar con él GWT, pero como uno de ellos es demasiado complejo (o eso dicen, no lo he usado), otro es demasiado simple, y tenía ganas, me hice mi propio plugin, para que haga lo que en mi opinión debería de hacer un puñetero plugin de GWT para maven.
 
Primero, características del mismo, qué narices hace, y para qué sirve

  • Compila usando una instalación de GWT local
  • Independiente de la versión de GWT (esto es importante, el plugin “simple”, no lo era)
  • Elimina clases java de la parte cliente innecesarias, puesto que éstas son compiladas por GWT, por lo tanto no deben de ser añadidas al war final puesto que nunca van a ser usadas. ¿Cómo se hace esto? Se borran todos los ficheros de la parte cliente excepto aquellos directorios llamados common.
  • Mueve los ficheros compilados por GWT a la carpeta raíz de la aplicación web (¿por qué hacer esto?, bicosyes, y porque así no tenemos urls tipo /com.mycompany.myApp/myApp.html, sino /myApp.html como debe ser)

Vale, y ¿qué se puede configurar?

  • Directorio de GWT, por defecto /opt/gwt
  • Sistema operativo, por defecto linux
  • Borrar clases java de gwt, si o no
  • Mover ficheros compilados de gwt, si o no

¿Cómo puedo usarlo en mi pom.xml?

<plugin>
		<!-- GWT compiling -->
		<groupId>com.bicosyes</groupId>
		<artifactId>simple-gwt</artifactId>
		<version>0.1</version>
		<configuration>
				<gwtHome>/opt/gwt</gwtHome>
				<os>linux</os>
				<modules>
						<module>com.bicosyes.HolaMundoWeb</module>
				</modules>
				<move>true</move>
				<delete>true</delete>
		</configuration>			
		<executions>
				<execution>
						<id>Compile gwt</id>
						<phase>compile</phase>
						<goals><goal>gwt</goal></goals>
				</execution>
				<execution>
						<id>Cleaning gwt stuff</id>
						<phase>process-classes</phase>
						<goals><goal>gwtClean</goal></goals>
				</execution>				
		</executions>
</plugin>

En este caso, las opciones gwtHome y os se podrían omitir, puesto que se tomarían esos valores por defecto. Respecto a la acción de borrar clases, como he comentado brevemente antes, se borrarán todos los archivos de la carpeta client/ del modulo gwt, excepto las carpetas con el nombre common, ¿por qué hacerlo de esta forma?, pues porque la parte server de la aplicación necesitará incluir en su código clases de la parte cliente, una solución sería duplicar estas clases (o en un SO decente usar enlaces simbólicos, ln -s) y otra sería crear un paquete common dentro de client, al cual se hará referencia desde las clases del servidor. ¿Por qué usar common como nombre?, ¿por qué no?, principalmente porque se me ocurrió así de primeras y encima luego se lo vi usar a uno de IBM en un artículo, así que no debe de ser una solución tan mala.
 
Vale, ahora ya solo queda saber cómo instalarnos el plugin, pues dos formas tenemos, ambas muy sencillas

  • Opción 1
    $ svn checkout http://svn.bicosyes.com/SimpleGWTmvn/simple-gwt
    $ cd simple-gwt/
    $ mvn install
  • Opción 2
    $ wget http://bicosyes.com/code/simple-gwt-0.1.jar
    $ mvn install:install-file \
             -Dfile=simple-gwt-0.1.jar \
             -DgroupId=com.bicosyes \ 
             -DartifactId=simple-gwt \
             -Dversion=0.1 \
             -Dpackaging=maven-plugin \
             -DgeneratePom=true \
             -DcreateChecksum=true

Por supuesto, animo a cualquiera que quiera, coger y modificar el código para añadir funcionalidad, es realmente simple hacer plugins para maven, y el código es bastante corto y comprensible. Cuando tenga tiempo (es decir, cuando me salga de las narices) tengo pensado añadir alguna funcionalidad más, he aquí la lista:

  • Crear (o completar si existe ya) el web.xml con las definiciones de los servlets y mapeos de los mismos a partir del fichero definición de los modulos de gwt
  • Permitir configurar los directorios donde puede haber clases que necesite el servidor (para lo de borrar y tal)

Maven, entre el amor y el odio

La plataforma para la creación de aplicaciones a nivel empresarial es por excelencia Java (truenos de fondo…). Por lo normal, en todas las aplicaciones reales y serias que se hacen sobre Java, una de sus principales dificultades es el conjunto (elección y organización) de tecnologías (en este lote incluyo librerías, drivers, plugins, plataformas, servidores, herramientas y un largo etcétera interminable y del cual desconoceré la mayor parte y tú, aunque creas lo contrario, seguro que también). Una vez pasado el largo planteamiento inicial del componente que se desea a realizar, toca mancharse las manos y ponerse a programar. En cuanto te empieces a dar cuenta estarás ante una monstruosidad que sino llega a ser por tu querido IDE (eclipse, netbeans, vim+par de cojones) no podrías compilar y ponerlo en funcionamiento ni en tus sueños eróticos (tarea no trivial, entre otras cosas, por todo el conjunto de tecnologías externas de las cuales se suelen usar). Si a esto le sumas la tarea, no muy rara de darse, de mover todo el proyecto a otro sistema, empezarán a aparecer por ahí curiosas variables y similares que hay que cambiar por que son dependientes de un sistema en concreto. En definitiva, el proceso de gestión y construcción del proyecto se convierte en un autentico infierno, solo comparable al uso de Internet Explorer (OMFG!).
 
Para suavizar e intentar facilitar todo esto, existen herramientas para automatizar todo el proceso, la más conocida y usada actualmente es Ant (Netbeans la usa para todo el proceso de compilación), pero solo hace falta abrir uno de sus ficheros de configuración, build.xml, de un proyecto aleatorio para empezar a plantearse que quizá va a ser peor el remedio que la enfermedad. Vamos que su configuración es de todo menos intuitiva. Y su curva de aprendizaje (y mantenimiento) es pareja a bailar claque con un oso asiático en celo en la espalda.
 

Logo de Maven

Ahora es cuando digo que maven es bueno, bonito y barato y nos soluciona la papeleta. En parte así es, mucho más simple y potente que Ant (Maven hace lo mismo que Ant, y ambos son proyectos de Apache, uno de ellos más nuevo que el otro, adivina cual…), en definitiva un digno sucesor de Ant, mucho mejor, aunque no perfecto. Antes de seguir hablando pondré un “hola mundo” que así ya se entiende mejor qué es todo esto. Atención al pom.xml (project object model):

$ mkdir HolaMundo && cd HolaMundo
$ mkdir -p /src/main/java/com/bicosyes/hola # com.bicosyes.hola será el package
$ cat > /src/main/java/com/bicosyes/hola/Hola.java << EOF
package com.bicosyes.hola;
public class Hola
{
public static void main(String [] args)
{
System.out.println("¡Hola mundo!");
}
}
$ cat > pom.xml << EOF

4.0.0
com.bicosyes # grupo al cual pertenece el proyecto
HolaMundo # el nombre
1 # versión del componente
$ mvn install # install!, compila y genera el .jar
$ java -cp target/HolaMundo-1.jar com.bicosyes.hola.Hola
¡Hola mundo!

Pues vaya lata tener que hacer todo eso para un puñetero Hola mundo, ¿no?. Pues si, como nos gusta complicamos la vida a veces… Si no fuese porque además, maven, nos permite ejecutar test JUnit, recopilar informes de los test ejecutados, pasar pruebas de checkstyle, generar javadocs en diferentes formatos, crear packages jar/war/ear/ejb, subirlo a servidores remotos y cosas por el estilo que desconoceré. Además de todo esto, me he dejado su principal característica para el final, gestión de dependencias (al más puro estilo apt-get). Se usan repositorios de librerías (ésta es la principal), en el pom.xml se indicará qué librerías son usadas en el proyecto y qué versiones de las mismas (por ejemplo log4j versión 1.2.14). Indicando eso, al intentar realizar el proceso de compilación, maven las descargará, y si éstas, a su vez, dependen de otras librerías, hará lo necesario para que sus dependencias sean resueltas. Ahora ya todo esto del tal maven suena mejor, ¿no?. Sabes que si.
 
Uno de los principales fuertes de maven (desde mi punto de vista) es su facilidad y su modularidad (propio de la fundación Apache) que se traduce en una gran facilidad para escribir plugins y usarlos. Tenemos desde plugins de reporting hasta plugins para ejecutar tareas Ant (si, el de antes), pasando por deployment en servidores tomcat, por citar algunos que conozco de primera mano.
 
¿Alguna parte negativa? Hombre pues salvo el Monstruo de Espagueti Volador, nada es perfecto. El mayor punto negativo está en que, lógicamente, no vamos a tener todo en el repositorio y resignarse a usar la versión ‘X’ no es una opción, por lo que no es muy raro el tener que instalar en un repositorio propio controlado las versiones de las librerías que necesitemos (con todo lo que esto conlleva… piensa en las dependencias, por ejemplo…). Además el plugin para ejecutar test JUnit funciona dependiendo de la posición de los planetas, he debugeado pero sin mucho éxito, lo tengo como tarea pendiente (de baja prioridad por ahora).
 
Algunos enlaces para empezar

Impresión desde aplicaciones Java con CUPS

Las JVM tienen un bug reportado y solucionado hace poco que afectan a las versiones tanto de java 5 (fixeado en update 12), como java 6 (hasta el update 1). Curiosamente en los repositorios de ubuntu tenemos las versiones justo anteriores a éstas, por lo tanto existe el bug. Este bug consiste en que es imposible imprimir desde aplicaciones Java a impresoras que usen CUPS. Todas tus impresoras te saldrán como “Not accepting jobs” (No se aceptan trabajos). Vaya putada, ¿no?.
 
¿La solución? Muy simple, puedes optar por descargar la última versión de Java de la web de Sun, o usar esta simple solución:

  • Crear enlace simbólico, en ubuntu no existe, en otras distros puede que tampoco

    $ sudo ln -s /usr/lib/libcups.so.2 /usr/lib/libcups.so

  • declarar CUPS_SERVER como localhost

Es decir, si queremos ejecutar una supuesta aplicación Java llamada, por ejemplo, AlAtunTunTun, desde la cual queremos imprimirnos El Quijote, hacemos algo tal que así para iniciarla:

$ export CUPS_SERVER=localhost
$ /ruta/alProgramita/AlAtunTunTun

Y problema resuelto :).