Post Nro 13 - Java NO genera ejecutables (.EXE)

Bienvenidos al post nro. 13. En realidad el número no me provoca ningún tipo de sentimiento en especial, lo que me preocupaba es que ya pasó una semana desde el último post y no estaba para nada creativo.

Este tema no lo daba en ningún curso hasta que un alumno me lo hizo notar (gracias Fede, alias Kal-El) y comprendí la importancia que tiene, especialmente en los cursos iniciales. El objetivo era saber si se podía correr una aplicación Java en un pendrive.
Bien, todo parte de que Java no genera ejecutables de ningún tipo, recuerden que lo único generado es código intermedio (bytecode), es decir, archivo con extensión .class.
Existen 2 formas de hacer correr una aplicación Java en una máquina distinta en la que se desarrolló, pero antes, sea cual sea la forma en que la despliegue, necesito:

1. Tener acceso al JRE: hago hincapié en que no dije "instalar", basta con tener acceso a un directorio que contenga el JRE, más precisamente, al archivo java.exe (en windows) o java (en linux).
2. Empaquetar mi aplicación en uno o varios JAR (Java ARchive, más detalles en próximos posts). Si bien este punto no es necesario, es muy recomendable.
   

Forma 1 - Chapada a la antigua

Esta primer forma consiste en correr la aplicación por medio de la línea de comandos (antiguo DOS). Esta forma es más habitual para los usuarios Linux. Consiste en lo siguiente:
Si nuestra aplicación se llama MiPrograma.jar y quiero correrla desde la línea de comandos, necesitaré escribir lo siguiente:
C:>\\java -jar MiPrograma.jar
Esto hará que se ejecute la aplicación (si está bien empaquetada). Este comando se puede escribir en un archivo con extensión .bat/.sh para poder tener un acceso directo y hacerlo un poco más visual.

Forma 2 - Creación a mano de un archivo .exe

Podríamos hacer uso de otro lenguaje que sí genere código ejecutable (VB, C, C++, Pascal, etc.) para que se invoque automáticamente a la línea de comandos y se ejecute la aplicación, o, podríamos utilizar un programa que lo haga por nosotros.
De este tipo de programas hay varios, pero me interesa uno en especial, aunque todavía es beta, tiene muy buen funcionamiento y me ha servido mucho, se llama JSmooth y pueden descargarlo del siguiente link.

El primer proyecto que se arma con este programa suele ser un poco complicado, por eso voy a dejar un pequeño tutorial de cómo usarlo.
Lo que tiene de bueno este programa es que se puede generar un ejecutable que contenga a la aplicación o que utilice un jar serparado, además, se puede configurar ampliamente la máquina virtual de Java, incluso se puede añadir mensajes específicos al usuario para que la instale.
Como si eso fuera poco, es posible incorporar todo el JRE de Java para que la aplicación la utilice accediendo a un directorio específico. Eso está muy bueno, ya que pueden prescindir de obligar al usuario que instale el JRE, directamente lo podemos distribuir con nuestra aplicación.

De esta manera, podemos crear un .exe (entorno Windows) sin muchos problemas, incluso podemos correr la aplicación directamente desde un CD o un pendrive. Muy recomendable.

Links:

Tutorial: (PDF)
JSmooth: http://jsmooth.sourceforge.net/
Launch4j: http://launch4j.sourceforge.net/

Saludos PF

Internationalization

Para explicarlo concisamente, creo que lo mejor es responder una serie de preguntas, después, les dejo el ejemplo para que lo bajen y analicen.

¿Qué es internationalization?

Cuando desarrollamos, aunque sea el sistema para el videoclub de la esquina, siempre es más conveniente que tratemos de hacerlo lo más prolijo posible, de manera de que no debamos gastar demasiado tiempo en "mantenimiento" del código (por no decir arreglar lo que hicimos mal). La característica de internacionalización de Java nos ayuda bastante a la hora de mostrar y de recibir datos en nuestras pantallas (J2SE - J2EE indistintamente).

¿Por qué y cuándo debería usarlo?

En la documentación oficial y en la mayoría de los tutoriales, vamos a encontrar que deberíamos utilizar internationalization cuando nuestra aplicación va a ser utilizada por personas de diferentes países o culturas (monedas y forma de representar métricas por ejemplo).
Lo cierto es que va mucho más lejos la cosa. Pienso que deberíamos utilizarla por el simple hecho de que nos va a ser más simple en un futuro agregar esta condición (por más de que no esté planteado desde el principio del desarrollo), además, recuerden esta regla:

LOS REQUERIMIENTOS VAN A CAMBIAR!!!

Se los aseguro, por experiencia propia, lo que hoy llaman "Representante", mañana lo van a llamar "Agente", ¿por qué? van a preguntar Uds., la respuesta será: "Porqué nuestro nuevo consultor de imagen dijo que será cool...".

¿Dónde debería usarlo?

Esta pregunta es de más fácil respuesta. Como regla general, nunca deberíamos tener una salida (ya sea por consola, por objeto swing o por navegador) que no sea "internacionalizada". Tratar de no dar mensajes al usuario del estilo System.out.println("Cantidad de dinero en la cuenta: $"+dinero);

¿Cómo se usa?

En el siguiente gráfico se los muestro:


Resulta que por cada idioma que queramos incorporar a nuestra aplicación, necesitaremos un archivo .properties donde definiremos las etiquetas y mensajes en el idioma adecuado. Ahora, deben tener en cuenta el nombre de los archivos. Donde dice "MessageBoundle" puede ir lo que Uds. quieran, pero por cada definición de lengua y país, deberá especificar en el nombre del archivo estas características (por ejemplo "es" de español en "AR" por Argentina).
De esta manera, cuando quieran incorporar otra lengua a la aplicación, lo único que deberemos definir será un nuevo archivo de propiedades.

¿Qué son los Resource Bundles y Locales?

Básicamente, tenemos en Java 2 Clases: ResourceBundle y Locale. La primera clase representa un recurso externo, es decir, un archivo de propiedades.
La segunda, identifica un lenguaje y un país en particular, su constructor recibe 2 parámetros: el primero es un String que indica el lenguaje, y el segundo, es otro string que indica el país.

La idea es crear un objeto del tipo Locale para representar el país y lengua a utilizar, y con este objeto, instanciar un ResourceBundle, que nos servirá para obtener del archivo de propiedades, cada una de las etiquetas respectivas.

Su uso es bastante sencillo, les dejo el código fuente para que lo prueben, allí encontrarán un poco más de detalle.

Links:

Fuentes: download

Algunos artículos de utilidad:

Artículo: "Using imput methods on the Java Platform"
Artículo: "Java Internationalization: Localization with ResourceBundles"

Saludos PF

Experimentando con Java Annotations

Metadatos, (¿no lo hacíamos con XDoclet?) . Si, es cierto, pero ahora, con la última versión de Java (Tiger), tenemos la posibilidad de darle más flexibilidad a nuestro código, y con un soporte directo de la máquina virtual, sin necesidad de toda una librería externa (esta parte no es del todo cierta).

Básicamente, Java da soporte directo para muy pocas annotations, pero también da la posibilidad de crear nuestras propias anotaciones. Es esto lo que voy a hacer para demostrar como funciona.

Como el objetivo de este blog no es hacer tutoriales interminables, y además, estamos limitados en espacio, me tome la libertad de hacer un pequeñísimo ultra mini tutorial para que vean en detalle cómo desarrollar una aplicación orientados a los atributos.

El tutorial es muy corto, así que no tienen razón para no leerlo. Además, les dejo los fuentes de la aplicación (desarrollada con Eclipse).

Espero que les sirva
Puedes bajar el tutorial aquí (PDF)
Puedes bajar los fuentes aquí (RAR)

Saludos PF

Finalmente Java es Open Source

Si, es cierto, ya nada de rumores ni de noticias sin fundamento. Finalmente, después de tanto tiempo y de tantas idas y vueltas, Java es Open-Source. ¿Que más tenemos para decir? Ah, si los detalles:

• Por ahora, sólo se libera la VM Hotspot y javac. Todo java 6 (Mustang), a esperar hasta el 2007.
  
• Sun está apostando mucho a su proyecto GlassFish, un servidor de aplicaciones gratuito (¿Tendrá miedo JBoss?).
• El "gobierno" de las especificaciones sigue bajo el mando de la JCP (Java Community Process). Este punto es importante por las implicancias que trae y la obvia pregunta (¿es libre?)
• El código de Java se libera utilizando la licencia GPL v2 con una pequeña excepción: El código generado con Java no necesita ser GPL.
  

En la página principal de java se pueden ver más detalles y las opiniones de todos los personajes de siempre, Richard Satllman, Tim O'Reilly y por supuesto, (Todo el mundo a hacer una reverencia):

James Gosling.

Saludos PF

Algunas herramientas para comenzar un proyecto

Bien, quiero dar una lista de herramientas que me han sido de utilidad para iniciar proyectos y mantenerlos. Por supuesto que siempre depende de los gustos y comodidad de cada profesional. Y además es recomendable, que no sigamos el listado como una receta de cocina ni como una obligación, mucho menos seguirlo como una lista exhaustiva.

CVS / Subversion: Son muy parecidos y cumplen con el mismo objetivo. Su concepto es tan simple que hace dudar acerca de su funcionalidad final. Esto pensaba yo hasta que comencé a utilizarlo. Ya sea en un pequeño proyecto de un sólo programador, o en un entorno de múltiples desarrolladores trabajando en el mismo proyecto, una herramienta que nos permita "versionar" nuestro código, es algo impagable. Generalmente CVS es una herramienta de consola (un poco complicado de configurar al principio), por eso les recomiendo una versión para Windows (CVSNT). Personalmente los he probado a los dos y me quedo con Subversion (aunque la página muestra un warning para Windows, nunca me dio ningún problema). Por supuesto, además del servidor de versiones, necesitaremos algún plugin para poder acceder, como eclipse es mi IDE favorito hasta el momento, les recomiendo el plugin Subclipse.

Log4J / Jakarta Commons Logging: Los System.out.println("..."); son útiles pero únicamente en el instante. Necesitamos algo un poco más poderoso para poder monitorear (=instrumentar) nuestra aplicación, especialmente cuando ya está en producción. Popularizada por la mayoría de las librerías y herramientas open-source, Log4J se ha convertido en una de las mejores herramientas para hacerlo, aún más utilizada que las librerías del propio JDK. Inclusive, ha trascendido los límites de Java y existen versiones para PHP, .NET, C, etc.

Control de Normas: alguna herramienta que pueda analizar nuestro código según estándares y que además pueda sugerirnos mejoras, es bastante útil para no cometer demasiados errores que perjudiquen la performance de nuestra aplicación (ver el último post).

XDoclet: definido como "attribute oriented programming", nos permite incorporar dentro de nuestro código, metadatos (dentro de líneas de comentario), con la finalidad de que, utilizando Ant, podamos generar nuevos artefactos. Yo lo he utilizado para generar los archivos de configuración de Hibernate, y funciona bastante bien. Aquí pueden ver la página principal.

Apache JMeter: esta herramienta nos permite realizar pruebas funcionales y mediciones de performance. Pueden ver su página haciendo click aquí.

Herramienta de modelado y documentación: básicamente, alguna herramienta que nos permita modelar en UML. Hay muchas alternativas, yo he probado el clásico de clásicos Rational y varios con versiones comunitarias. De estos últimos me ha gustado mucho el VisualParadigm y debo decir que el Poseidón me ha hecho perder varias semanas de trabajo (no sé como estará en la última versión).

No considero cada una de estas herramientas imprescindibles, pero debo decir que nuestro objetivo debe ser el de "optimizar el tiempo". Por ejemplo, si consideran que son más rápidos en escribir el xml de hibernate antes de aprender XDoclet, escriban xml. Pero analicen un poco antes de comenzar el proyecto, ¿cómo puedo optimizar el tiempo de desarrollo?, ¿existirá alguna herramienta que lo haga por mí?, etc..

Saludos PF

[OFF Topic] Gracias Cordoba.net

Quiero agradecer a uno de los sitios líderes de mi ciudad, Córdoba (Argentina) por recomendar este humilde blog.

Muchas Gracias Cordoba.net !!

¿Quién dijo que yo escribía buen código?

En realidad, esa no fue la primera pregunta, sino ¿estaré escribiendo buen código?. Sin tratar de apelar a la humildad sino al conocimiento de uno mismo, la respuesta fue un rotundo "no creo...". Ahora bien, sé que he leído sobre nomenclatura en articulos, pdf, blogs y siempre he tratado de atenerme a las reglas, pero aún así sé que se puede mejorar.

Bien, existen varias herramientas de análisis de código, pero detallaré sobre una en especial, llamada "PMD". Esta herramienta se encarga de analizar el código fuente y tratar de encontrar problemas no sólo de nomenclatura, sino además de optimización, como por ejemplo, las clásicas variables declaradas y nunca usadas, líneas de debug del tipo "System.out" sin borrar, parámetros de sólo lectura que podrían ser declarados finales, buen uso del StringBuffer y hasta puede identificar código duplicado mediante el clásico "Cut & Paste".

Esta herramienta, que se distribuye bajo licencia "BSD", es bastante completa, configurable (podemos crear nuestras propias reglas), brinda hasta ejemplos de cómo mejorar nuestro código y cómo si fuera poco, se integra completamente con varios IDEs, entre ellos Eclipse, IntelliJ IDEA, JBuilder, Netbeans, JDeveloper, y varios más.

En el siguiente link, se pueden apreciar los resultados de analizar con este programa varios proyectos de SourceForge, ordenados por eficiencia, por ejemplo:

• Hibernate: está casi en la mitad de la lista, con un porcentaje de %0.25 de código no usado.
• XDoclet: marcado en un rojo furioso, un %1.07 de código no usado y 30 problemas encontrados.
• JUnit: con un cómodo color verde, apenas tiene un %0.07 de código no usado.
• JasperRepots: cerca de Spring, se posicionan casi al frente, con muy pocos problemas.

También podrán encontrar en la misma página de PMD, links a proyectos similares.

Y si se están preguntando cómo me fué a mí....
Mi lema es "Todos los días se aprende algo nuevo".



Saludos PF

Transfiriendo objetos con Sockets

Lo cierto es que me podrías cuestionar ¿para qué? , teniendo RMI, CORBA, Web Services, XML-RPC.

Si, es verdad, pero soy curioso, los JavaDocs dicen que puedo usar la clase ObjectOutputStream y la ObjectInputStream para enviar y recibir un objeto a través de un Socket. Eso me lleva a pensar ¿será cierto?, ¿será fácil?, ¿lo podré hacer?, y justo cuando voy a decir "bahh, ni lo intento", una voz interna me dice y me reta a un duelo: "a que no podés...". Entonces, en vez de tomar la pastilla recetada para callar las voces, me pongo a programar y a demostrarme que puedo hacerlo.

Finalmente funcionó, utilicé tres objetos distintos, un servidor, un DTO y un cliente. Lo único que tenemos que tener en cuenta es que deberemos marcar al DTO como Serializable.

Lo bueno de todo esto es que es tan fácil como escribir un

out.writeObject(miDTO);

y del lado del Cliente:

DTO dto = (DTO) in.readObject();

Aquí tienen un modelo general del funcionamiento, y les dejo los fuentes

Saludos PF