Si, lo sé, soy un pesado con mí Nokia N95, pero bueno, aquí van varias cositas por si le interesan a alguien.

• Viewranger se me antoja como la aplicación ideal para sacar el máximo rendimiento al Nokia N95 para las rutas de senderismo que hago. Es una aplicación para móviles S60 que te permite trazar rutas, verlas en mapas topográficos, mientras te indica puntos de interes que puedes visitar en el trazado. La idea es que son mapas detallados de zonas no urbanas, que es lo que suelen traer aplicaciones como Smart2go o TomTom. La única pega es que por el momento solamente tienen mapas de el Reino Unidos, aunque después de preguntarles por correo si iban a sacar mapas de otras regiones, me han dicho que sí, habrá que ver cuanto tiempo tardan, dado que supongo que no será una tarea sencilla. (Vía: Nokia N95 Blog).
• El texto predictivo te permite introducir textos en tu ordenador con gran rapidez, pero algunas veces, para correos o para editar tú página web, no hay nada mejor como un teclado. All About Symbian os explica como conectar un teclado bluetooth al Nokia N95.
• Siempre que compro un dispositivo nuevo, siempre me digo que tengo que aprender a programarlo, aunque muchas veces no pasa de un propósito. Todo esto para decir que acaba de salir una nueva versión de Python para Symbian S60.
• Y ya que hablamos de programación móvil, aquí tenéis una faq sobre AJAX en dispositivos móviles.
• Y volviendo al tema del GPS, un un vídeo comparando el sistema de guía de un Nokia N95, un Nokia N800 y un TomTom 510.
• ¿Quieres sacar fotos de gran angular con tu N95? aquí te explican como, aunque a mí no me convence de todo el sistema…
• Otro uso curioso para tu N95.
• Versión móvil de Technorati.
• Almacena tus tarjetas de visita de forma automática. A mi personalmente no me interesa mucho, pero puede ser interesante para el futuro. Gracias a Farfanilla por avisarme.

La mejor definición que he visto de este lenguaje de programación.

—–

Esta es la forma ideal de presentar una oferta de trabajo para cualquier persona que programe.

Vía: reddit.

—–

Y ya que estamos de poesía, mi amigo Alex me envía esto por correo electrónico:

Empty your memory,

with a free()…

like a pointer!

If you cast a pointer to an integer,

it becomes the integer,

if you cast a pointer to a struct,

it becomes the struct…

The pointer can crash…,

and can Overflow…

Be a pointer my friend…

—–

Teniendo que programar todos los días obviamente me ha hecho gracia la página: The Daily WTF

The Daily WTF es un blog donde aparecen fragmentos de código que envían otros programadores a través de su foro. ¿Y qué es lo divertido? Que estos fragmentos de código son lo más increíble, absurdo, abstracto, inútil y divertido que hayas podido ver. [Yo Programador].

Me reiré cuando vea errores estúpidos publicados en el blog y me callaré vergonzosamente cuando vea un error que también cometa yo a diario ;-)

Vía: Microsiervos.

—–

Atención: Esta noticia es sobre el lenguaje de programación Java, y un auténtico coñazo para aquellos que no programan, así que si ese es tu caso, se te recomienda que te muevas a otro post que aquí no hay nada que ver.

En mi trabajo habitualmente programa en Java, y como todo programador de Java sabe, nuestra vida sería muy difícil sin el trabajo de la gente del grupo Apache, utilidades como Ant, Tomcat, Jakarta Commons se han convertido en imprescindibles… y yo he descubierto estos días una pequeña joya que aun no tiene versión definitiva: Apache Jakarta Commons Betwixt.

El viernes necesita guardar una gran cantidad de información en una aplicación para pasarlas a otra aplicación desarrollada por mi. Había trabajado un poco con Digester para leer ficheros XML pero me dí cuenta que este proyecto solamente “digiere” XML, no lo crea, así que decidí ver si había otra solución fácil de usar dentro del gran abanico que ofrece Jakarta Commons, y allí estaba Betwixt.

Betwixt es capaz de generar automática con unas pocas líneas de código un fichero de Java a partir de POJOS y/o JavaBeans. Con solamente estas líneas de código, ya podía guardar cualquier tipo de objeto a disco:

             Writer outputWriter = new FileWriter(filename);             BeanWriter bWriter = new BeanWriter(outputWriter);             bWriter.setEndOfLine("\r\n");             bWriter.setIndent("\t");             bWriter.enablePrettyPrint();             bWriter.write(graphToStore);             outputWriter.close(); 

Y todo un Grafo, con sus Vértices y Ejes, representados por sus sendas clases, dentro de un bonito fichero XML.

Ahora estaba el problema de volver a leer eso en la otra aplicación, iba a mirar Digester cuando vi, que Betwixt además de almacenar lee, y con otras pocas líneas de código ya tenía mi fichero XML convertido a objetos Java.

             InputStream inputStream = new FileInputStream(filename);             BeanReader beanReader = new BeanReader();             beanReader.getXMLIntrospector().setWrapCollectionsInElement(false);             beanReader.registerBeanClass(Graph.class);             return (Graph) beanReader.parse(inputStream); 

Y de esta forma tan simple podía mover todo un mapa de objetos de una aplicación a otra, sin tener que usar librerías complejas de XML o serializar a fichero en un formato que solamente Java podría leerlo de nuevo.

—–

El año pasado compré el libro Hibernate in Action escrito por los propios creadores de Hibernate. El libro me ha encantado, es ameno y conciso, fácilmente te explica como Hibernate resuelve el problema de mapear objetos Java a bases de datos relaciones, y por que optaron por ciertas implementaciones en vez de otras.

Pero el mundo de la informática no para, y desde que se edito el libro se ha publicado la versión Hibernate 3.0 con la 3.1 a punto de caer, y la especificación de EJB 3 también esta más cerca. Por ello los autores han decido preparar una segunda edición del libro que tenga en cuenta estos cambios. Por otro lado también van incluir cambios en la estructura del mismo para corregir detalles que vieron cuando hicieron un curso sobre Hibernate donde seguían la estructura del libro.

We’ll update the book for Hibernate3 and EJB3, and based on the feedback we got from readers and during training (our first Hibernate training last year was following the books structure) we’ll make some major changes:

* the “Toolset” chapter will be removed and integrated into a new beginners tutorial that also shows the new Eclipse-based and Ant tools, with a hands-on basic project setup

* a new chapter will be added with best practices, patterns, and general tips & tricks - this will include a lot of FAQs from the forum and our customers, such as caching tricks, metadata-driven applications, dealing with large values, complex deployment scenarios, etc.

* more illustrations will be included with many mapping examples

So, you can expect quite a lot of new content, especially wrt EJB3 API usage for all of you who want to learn the new interfaces and lifecycle (it’s easy if you know Hibernate…) and more best practices.

Vía: In Relation To…

—–

Wolfram Rösler ha realizado una compilación de como crear un programa Hello World! en 190 lenguajes distintos: C, Basic, Java, Perl, Python…

Vía: Microsiervos.

—–

Usualmente en mi trabajo uso Eclipse para programar en Java. En estos días se esta celebrando la EcliseCon2005 y han puesto en su página web las traspas de las conferencias y tutoriales, a primera vista parecen bastante interesantes:

Tutoriales.

Presentaciones.

Vía: Java Hispano.

—–

Me he encontrado con este interesante artículo, publicado en On Java, “The Hidden Gems of Jakarta Commons, Part 1″ que nos introduce y recomienda el uso de Jakarta Commons. Jakarta Commons son una serie de librerías de Java desarrolladas por los chicos de Apache para resolver problemas comunes que se encuentran a la hora de desarrollar aplicaciones Java, tales como manejo de ficheros XML, manejo de colecciones, entrada/salida de datos y un largo etc… por mi parte, si hace un par de años tuviese disponible Jakarta Commons Math me habría resuelto unos cuantos problemas. Hablando de Jakarta Commons Math, en la página web de O’Reilly tenéis un capítulo de muestra del libro Jakarta Commons CookBook, ese capítulo es el dedicado a Jakarta Commons Math, con una serie de recetas para el uso diario de esta librería.

—–

Bueno, como prometí la semana pasada, continuo con mis posts sobre el segundo congreso de JavaHispano, que al paso que voy los terminaré para cuando ya empiece la décimo quinta edición de este congreso. El segundo y último día del congreso decidí sacar alguna que otra foto para amenizar un poco mis posts en el blog. Aquí tenéis las fotos que saque ese día

Dos fotos de la “pequeña” pancarta que señalaba el edificio donde se celebraba el congreso de entre todos los edificios del campus del la Universidad Rey Juan Carlos.

También tenían carteles pegados por la paredes…

Y aquí el lugar donde se celebró la inscripción, el proceso era bastante rápido si ya estabas preinscrito, puesto que consistía únicamente en mostrar tu código de barras para que te diesen todos los regalitos que tenían preparados: mochila, camiseta, tarjeta del congreso, varias revistas, actas del congreso en cd y diversos artículos de propaganda de las empresas patrocinadoras.

Aquí esta el escáner de códigos de barras por el que te hacían pasar cada vez que entrabas en una conferencia, supongo que para mantener algún tipo de control de asistencia. También se pueden observar los equipos de radio para escuchar la versión traducida de las conferencias impartidas en inglés.

Una vista de una de las salas de conferencias, la más grande de las dos que había, eso sin contar la sala demos, a la cual nunca fui en todo el congreso, por lo tanto no sé decir si era más grande o pequeña que esta sala.

Aquí tenéis dos fotos de Alexandre Vasseur durante su conferencia titulada “Annotation driven AOP”. Alexandre Vasseur es una de las personas involucrada durante los últimos años en el desarrollo del concepto de Aspect Oriented Programing. A parte de esto, es coautor del famoso AspectWerkz, una de las alternativas que existen para Java a la hora de realizar programación orientada a aspectos.

Por último también le saque otra foto durante la conferencia de uno de los empleados de CompuWare, Ruud Grotens. Realmente la conferencia no me interesó mucho puesto que nos habló de una nueva herramienta de CompuWare para el desarrollo de aplicaciones J2EE a base de patrones. Yo realmente tengo la intención de no aprender nada de EJB2 a no ser que me haga falta para ganarme el pan.

También hay más fotos en un post que hice hace tiempo y que se llama: Taming the Tiger, que tiene fotos de la última conferencia del congreso.

—–

Chequeando los distintos feeds rss a los que estoy subscrito me he encontrado con esta API de Java que probablemente me venga bien para mi futuro trabajo con grafos: Java Universal Network/Graph Framework.

—–

Después de levantarme el miércoles 15 de Diciembre a las 5 de la mañana para poder coger el vuelo a Madrid desde Santiago de Compostela, llegué a la capital a eso de las 8:30 de la mañana. Después de hablar con Abraham, uno de los organizadores del evento, por teléfono, me comenta que la mejor forma de llegar a Móstoles es a través de Metro, bajando desde Barajas hasta Móstoles, un trayecto que dependiendo de como se cojan los enlaces de líneas de metro lleva una hora y unos 15 minutos. Una vez en Móstoles me dirijo a la Universidad Rey Juan Carlos, donde se celebraba el segundo congreso de JavaHispano. El campus universitario de la Universidad Rey Juan Carlos daba la impresión de que se había construido hace poco, todo parecía bastante nuevo, sin que los alumnos tuviesen mucho tiempo de destrozarlo un poco. Una vez en el recinto universitario busco el edificio donde se celebra el congreso, el cual estaba marcado con una enorme pancarta.

Lo primero que hago es inscribirme, para ello enseño mi código de barras y me dan una tarjeta de identificación con mi nombre más código de barras junto con una cinta para llevarla colgada del cuello y el programa del evento, al mismo tiempo la gente de la organización me comenta que todavía no tienen listas las bolsas de regalo por asistir al congreso, pero que por la tarde ya podría solicitarlas simplemente enseñando mi tarjeta de identificación. Como ya eran las 10:30 y las charlas ya envían empezado, decido meterme en la primera puerta que vea para empezar a ver que se iba a hablar en este congreso. Me sorprendió un poco el control que hacían cada vez que entrabas y salías de una conferencia, puesto que tenías que enseñar tu tarjeta con el código de barras, supongo que sería para hacer estadísticas para ver que conferencias fueron las que realmente interesaban a la gente.

Resulta que me entré en una conferencia que daba uno de los empleados de la compañía Borland, y que se titulaba: “Auditoría estática y dinámica de código Java”. El empleado de Borland (lo siento, pero no llegue a tiempo para oír su nombre), estaba hablando sobre distintas herramientas de Borland para evaluar el rendimiento de diverso código Java, ya sea en su fase de ejecución, como analizando el propio código. Comentó que dichas herramientas estaban tanto preparadas para ser usadas en su entorno de programación, JBuilder o para el proyecto Eclipse. También habló un poco de una buena política de programación, recomendó el uso de test unitarios para cercioranos desde el comienzo que el código va funcionar y que no hay que andar preocupándose desde el principio en la optimización del código, sino, dejarlo para momentos concretos, lo cual dará lugar a un código mucho más limpio y legible.

Durante la conferencia de Borland revisé el horario de conferencias y me dí cuenta que me perdí la conferencia de mi amigo y compañero de trabajo Abraham Otero Quintana, que estaba dando su charla al mismo tiempo que los de Borland, desde aquí pedirle disculpas por ese despiste mio, realmente tenía intención de ir a su charla. A las 11:00 me cambié de sala, después de pasar por los oportunos chequeos de códigos de barras, para asistir a otra conferencia de una empresa relacionada con el mundo de Java, en este caso Bea, titulada: “Apache Beehive. Desarrollo rápido de aplicaciones J2EE”.

Nada más entrar en la sala de conferencias nos “asaltaron” la gente de marketing de Bea, regalándonos un bolígrafo y un cuestionario, que amablemente nos pidieron que cubriésemos. Uno de sus ingenieros (creo que era ingeniero), Sergio Álvarez, fue el encargado de hablarnos del proyecto open source Apache Beehive. El responsable de Bea nos aclara que Apache Beehive es la respuesta a varias críticas y necesidades que tenía su compañía. Una de las críticas era que Bea no colaboraba con la comunidad Open Source, lo cual hacen ahora con este proyecto. Por otro lado, necesitaban algo que hiciese más fácil la programación de proyectos J2EE, cuya dificultad en algunas ocasiones, hacen que la gente opte por alternativas menos potentes pero más fáciles de implementar, como la plataforma .Net de Microsoft. También, moviendo Apache Beehive a Open Source conseguían evitar tener que esperar al JCP a que optase o no por su propuesta, haciendo así que la comunidad se moviese hacia una alternativa concreta como ha sucedido con el caso de Hibernate (bueno, el no nombró Hibernate, este es un ejemplo mío para ilustrar el problema). Ya centrándonos en Apache Beehive, comentó que esta compuesto de 4 componentes:

• Presentación: La parte de presentación está basada en Struts, todo esto usando anotaciones y metadatos (JSR-175).
• Web Services: Esta hace uso de las anotaciones definidas en el estándar JSR-181.
• Java Controls: Para acceder a APIs y recursos externos de forma sencilla (ej: a una base de datos).
• XML Beans: Esto realmente es un proyecto independiente de Apache, Apache Beehive lo usa para procesar toda la información almacenada en formato XML.

Por otro lado, comenta que Bea considera ahora que Apache Beehive es un proyecto independiente y que progresará según la Apache crea necesario, y, que ellos darán soporte a Apache Beehive en sus servidores de aplicaciones y herramientas de desarrollo, añadiendo aquellas cosas que ellos consideren oportunas para dar más valor a sus productos. Por otro lado, también comentan que para desarrollar con Apache Beehive no hace falta productos de Bea y para ello ponen como ejemplo el proyecto aun no acabado: Eclipse Pollinate. Por otro lado animan a cualquiera a colaborar, ya sea programando, usándolo o reportando bugs. Al final de la charla, a los que cubrimos el formulario se nos regaló una grapadora y un mechero, ambos con el logotipo de Bea, y a las tres personas que hicieron preguntas, se les regalo un kit de evaluación de productos de Bea, que debía pesar lo suyo.

Después de esta segunda charla se produce un descanso, lo cual también fue bastante importante, en esos momentos yo tenía bastante hambre, dado que había desayunado a las 5:00 de la mañana. Al terminar el descanso procedo a ir a mi tercera charla de la mañana: “Integración continua utilizando herramientas open source”, la cual es impartida por Jesús Pérez, miembro del Agile Software Development User Group Spain. El ponente nos introduce en el concepto de desarrollo a través de integración continua y de diversas herramientas open source para lograr dicho objetivo. La integración continua intenta resolver problemas habituales en el desarrollo de un proyecto, tales como: “En mi máquina funciona” (en el momento que se lo enseñas al cliente en su máquina de producción y el programa no actual como era esperado), “Fecha final del proyecto impredecible”, “Imposibilidad de repetir instalaciones”, “Despliegues costosos por la necesidad de incorporación de procesos manuales”, “Constante repetición de las pruebas de forma manual”. La idea de la integración continua es ir desarrollando el software en todo momento dentro de un entorno real, donde dicho software será testeado a través de test unitarios automáticos. El ponente afirma que siguiendo este proceso de desarrollo se mejoran los siguientes procesos de un proyecto: “Identificación de fallos mucho más pronto”, “Minimiza la búsqueda de fallos colaterales” (Usualmente de la integración de distintas partes del proyecto desarrolladas por distintos equipos o del despliegue posterior en la máquina de producción), “Minimiza el ciclo de pasar de desarrollo al entorno de producción” y da más “Confianza en el código desarrollado”.

Para poder conseguir el objetivo de integración continua, Jesús Pérez nos introduce una serie de herramientas que usan ellos en la compañía que trabaja. Los objetivos a conseguir con dichas herramientas son los siguientes: “Control de Versiones”, “Pruebas automatizadas” y “Proceso de construcción automatizado”. Introduce la necesidad de usar un buen programa de Control de Vesiones (CVS), lo cual es imprescindible para proyectos que se ponen continuamente en producción, dado que nos permite ver fácilmente los cambios introducidos en el desarrollo así como la creación de diferentes líneas de desarrollo de un mismo programa. Como servidor CVS nos recomienda Subversión, especialmente por su control de ramas de desarrollo (como nota personal decir que cada vez estoy escuchando buenos comentarios de este programa y lo cual hace que cada vez tenga más ganas de probarlo). Después de el CVS comentó sobre la necesidad de crear pruebas automatizadas, para ello recomienda el uso de Test-Driven Development (TDD). Aplicar TDD no es tan fácil como parece, dado que implica bastantes cambios en la metodología que la gente suele usar para programar, pero los beneficios son obvios. Como utilidades para realizar TDD comentó varias, empezando por JUnit, Easymock, StrutsTestCase, MockObjects, DBUnit, Cactus, HTTPUnit, Canoo WebTest y JUnitPerf. Otro de los aspectos importantes de la integración continua es la automatización de procesos, lo cual añade las ventaja de hacer el sistema portable a distintas plataformas (sin tener que depender de un IDE concreto). Por supuesto, para desarrollar esta tarea se habla de Apache Ant. Para la automatización de tareas también menciona Apache Maven, el ponente comenta que esta última utilidad se construye sobre Apache Ant para ofrecernos implementación de alto nivel sobre los temas de un proyecto. Y como joya de la corona, nos presenta el proyecto: CruiseControl. CruiseControl es un framework para integración continua; a través de un fichero de configuración XML se puede programar a CruiseControl para que utilizando la última versión del programa que existe en el CVS se pasen todos los test de forma periódica, que informe de los resultados a través de una interfaz web, que envíe mensajes (e-mail, mensajería instántanea, semáforos…) de si la actual versión del programa del CVS pasa todos los tests, si alguien introduce un cambio que produce fallos, notificar al programador correspondiente y darle la lata hasta que lo solucione.

El ponente, Jesús Pérez, aporta los siguientes consejos para los equipos que desarrollo que quieran implementar esta politica: obviamente, la introducción de este tipo de sistemas de desarrollo debe hacerse de forma gradual, o la gente no se adapta a ellos. Asumir que nunca va a existir un buen momento para introducirlos, por que cuanto antes se introduzcan mejor. Obviamente la introducción de estas políticas de programación también presenta sus problemas, hay que crear una cultura de pruebas lo cual nunca es fácil y automatizar algunas partes del desarrollo puede que sea complicado. Al mismo tiempo recomienda que si se introduce esta polítca de desarrollo, es recomendable no introducir nada nuevo en el CVS si CruiseControl informa que todavía hay errores sin resolver, especificar un tiempo máximo que se puede seguir desarrollando sin solventar un error. Obviamente tiene que haber un responsable que se encargue de supervisar el proceso de integración continua. Al final concluye que la integración continua permite crear grupos de desarrollo mucho más ágiles.

La última conferencia a la que asistí por la mañana fue: “JVMTI, Creación avanzada de profilers de aplicaciones on la nueva API de Tiger”. La charla fue impartida por el estudiante de ingeniería informática Daniel González. Daniel González forma parte del grupo desarrollador de un programa llamado: Java TraceIt, que es un depurador y optimizador de aplicaciones Java. En su charla nos introdujo al nuevo protocolo introducido en la última versión de Java que nos permite comunicarnos con la máquina virtual. Esto se puede usar para dos cosas, por un lado proporciona un modo común para controlar la máquina virtual (depuradores de código) y por el otro permite la creación de Profilers, los cuales permiten el análisis de cuellos de botella en nuestro código (análisis de memoria y análisis de uso de CPU), esto es usado por soluciones como: OptimizeIT Profiler, Eclipse Profiler Pluging o su propia implementación Java TraceIt. El ponente continua hablandonos de todas las posibilidades de que ofrece los profilers en Java 5.0 para la creación de optimizadores de código.

Bueno, hasta aquí mi segundo informe sobre el segundo congreso de JavaHispano, también existe otro post sobre la conferencia del congreso titulada: Taming the Tiger. Cuando tenga otro rato libre continuo hablando sobre estas conferencias, que aun me quedan 1 mañana y dos tardes por narrar.

—–

Realmente debería empezar mi crónica de mi experiencia en el segundo congreso de JavaHispano por el principio, pero primero voy a hablar de su última conferencia. Esto es debido a que no tuve tiempo de tomar muchas notas, la verdad es que estuve más interesado en prestar atención a los ponentes, y no quiero dejarme nada en el tintero… digo teclado.

Uno de mis principales motivos que realmente me convencieron para ir al congreso de JavaHispano, a parte de que conocía a uno de los organizadores en persona, era poder ver una conferencia de dos de los arquitectos de la arquitectura de Java: Neal Gafter y Joshua Bloch. Para poner unos pocos datos biográficos, Neal Gafter actualmente trabaja para Google, aunque hace poco trabajaba para Sun donde se encargaba del desarrollo y soporte de herramientas de compilación del lenguaje Java (javac, javadoc, javah, javap…). También ha participado en el desarrollo de una de las APIs introducidas en Java 5.0: Generics (JSR14). Probablemente, más famoso sea el nombre de Joshua Bloch, al menos para mí, debido a su famoso libro de Java: Effective Java Programing Lenguage Guide, en el cual se muestran 57 pautas concretas para diseñar y escribir programas en Java. Joshua Bloch fue arquitecto dentro del “Core Java Platform Group” en Sun Microsystems, donde diseño importantes APIs de la plataforma Java, como java.util.Collections y java.math.

Bueno, pues centremonos ahora en la conferencia, realmente ellos habían preparado dos conferencias, una primera titulada: “Taming the Tiger” y otra titulada: “Still More Programing Puzzlers”. En la primera de las conferencias se centraría en explicar las nuevas características de la nueva versión de Java, J2SE 5.0, también conocida como Tiger; en ella explicarían importantes características como: generics, enums, autoboxing, for-each, varargs, static import y annotations (metadatos), al mismo tiempo aclarando cuando es conveniente usarlos y cuando no. La idea de la segunda charla consistía en proponer diferentes rompecabezas de programación al público para que estos comentasen que hacía ese pedazo de código, donde ellos después explicarían lo que realmente hacía y especificarían donde estaban los errores en esa porción de código, básicamente una forma divertida de aprender nuevos detalles sobre Java. Como realmente no tenían tiempo de dar las dos charlas, preguntaron al público cual de ellas preferían, y como el público no dio un voto decisivo, al final se usó el método de la moneda, cara o cruz, y la charla ganadora fue: “Taming the Tiger”, que la gente de JavaHispano tradujo como “Domesticando al Tigre” (aquí me gustaría hacer mención a que ninguno de los ponentes hablaba castellano, pero la organización del congreso, conociendo este problema, contrató un servicio de traducción para poder solventar este pequeño escollo lingüístico para aquellas personas que no tuviesen suficiente conocimientos de inglés).

Como comenté anteriormente, la conferencia se centró en explicar las nuevas características del J2SE 5.0 y en como usarlas. Empezó hablando Joshua Bloch, comentó que la idea principal de la nueva especificación era crear una programación más amistosa, dándole mayor soporte lingüístico a Java y sin sacrificar compatibilidad hacia atrás, es decir, cualquier programa que funcionase en Java 1.4 o 1.3 funcionará en Tiger, con la excepción de si ese programa usa una clase llamada enum, término que se introduce en la nueva especificación del lenguaje a partir de la versión 5.0. Una vez introducido el índice de la charla, Joshua Bloch le dio paso a Neal Gafter para que nos hablase sobre Generics.

Neal Gafter nos comento que Generics facilita la vida a todo el mundo que trabaje con java.util.Collections, destacando sobre todo el nuevo for-each loop como uno de sus añadidos favoritos a la nueva especificación. Nos presenta el nuevo interface de Collections para explicarnos los cambios que se producen por la introducción de Generics. Para recalcar aun más el nuevo concepto, se nos presenta una pequeña porción de código que usa Generics y Autoboxing, Quiero anotar que durante toda la conferencia, tanto Joshua como Neal se hicieron preguntas uno al otro para destacar los puntos más curiosos del ejemplo que estaban mostrando, un detalle que me pareció curioso fue la explicación del significado de los “:” del for-each loop, por ejemplo:

 List<ObjectX> lista = new ArrayList<ObjectX>();  ...  for(ObjectX objectX : lista) { ... }  

Si nos fijamos en la línea del bucle for, esos “:” puntos se traducen como “in”, lo cual quiere decir que es el “objectX” de la colección “lista”. Al final Neal Gafter concluye diciendo que deberíamos usar Generics y el for-each loop siempre que se pudiese en nuestro código, con una excepción, en el caso de que se necesite compatibilidad hacia atrás, hacia una máquina virtual más antigua que la Java 5.0. En el caso de autoboxing, es decir, la automática conversión de tipos primitivos (int, boolean,…) a sus equivalentes como objetos (Interger, Boolean…) sin necesidad de hacer un cast, también se puede usar sin problemas, pero tiene una penalización de rendimiento, aunque si no es en caso de cálculos científicos, se pueden usar por que facilitan bastante la lectura del código.

Después le toco el turno de Joshua Bloch de hablar sobre enums, donde destaco que gracias a ellos programas de cierta complejidad pueden llegar a simplificarse fácilmente, tal como sucede con otros lenguajes de programación. Para ello introdujo dos ejemplos, uno usando enums para la construcción de un programa que baraja cartas y reparte un número “n” de las mismas a distintas personas, consiguiendo la construcción del programa con una pequeñísima porción de código fuente. También para destacar más aspectos, puso otro ejemplo usando un programa para calcular el peso de diferentes personas en diferentes planetas del sistema solar (para ello uso de broma el “sobrepeso” de su compañero Neal, que el estimó en unos 100 kilogramos). A parte también explicaron como añadir funcionalidades a cada uno de los componentes del enum. También hablaron un poco de EnumSet y EnumMap que hacen lo equivalente que Set y Map pero con objetos que extienden del tipo enum. Al final, Joshua Bloch recomienda usar enums siempre que se conozcan todas las posibles cosas que deben ir en esa lista ordenada, por ejemplo, el orden de una baraja de cartas, se sabe desde el momento que se escribe el programa, y es algo que no va a cambiar durante la ejecución del mismo, añadiendo o quitando nuevos elementos.

Las dos últimas características novedosas que añade Java 5.0 fueron introducidas por Neal Gafter, que son varargs y static import. Para VarArgs usó diversos ejemplos, como el printf, que ahora se ha introducido en Java y que da la misma funcionalidad que en C/C++, también puso un ejemplo para un hipotético testeador estilo JUnit usando Varargs, obviamente, con un código muy sencillo. Por otro lado nos comentó el uso de static import con un ejemplo muy típico, hasta el momento cuando en Java querías usar una constante como PI, debías hacer algo así:

 r = Math.cos(2*Math.PI); 

Lo cual hace un poco complicada la escritura y lectura del código. Ahora se puede reescribir como:

 // Es mejor importar solo PI o cos, sin importar todo java.lang.Math import static java.lang.Math.*;   ...  r = cos(2*PI); 

Con lo que no hace falta andar repitiendo Math.PI o Math.cos por todo nuestro código. Tanto para varargs como para static import, nos recomiendan que lo usemos muy cuidadosamente, teniendo muy claro que ese es el momento y lugar correctos para usarlos.

Por último, Joshua Bloch habló de Metadata o annotations como también se le conoce. Comenta que la anotaciones pueden ser leídas a través del código fuente del programa, a través del fichero compilado .class o en tiempo de ejecución a través del API de reflection. Las anotaciones pueden ser usadas por muchas razones y para ello el nos retoma el ejemplo del testeador introducido por Neal, y nos explica que ahora ya no es necesario hacer cosas como en JUnit de empezar todos los métodos por “test” para que JUnit sepa que ese método es un test, si no usar una anotación, lo cual facilita la lectura del código y produce un código mucho más limpio.

Como conclusión, tanto Neal como Joshua nos comentan los siguiente: “Tiger is all about you, the programmer. Better programs with less effort”.

Después hubo un turno de preguntas, algunas de ellas para felicitarles por su trabajo en el desarrollo de JAVA, otras para preguntarles por su nuevo trabajo en Google, a lo cual contestaron que en Google se usan básicamente 3 lenguajes de programación, Java (uno de los sitios donde lo usan es en los banners publicitarios), C/C++ y Python (cada vez tengo más interés por aprender este lenguaje), y que no están haciendo ningún navegador web. Por otro lado, creo que fue Carlos Sanchez (si me equivoco que alguien me corrija) el que le pregunto por que Joshua Bloch, como diseñador del API de collections, escribió un método llamado .size() para recuperar el tamaño de una lista en vez de llamarlo .getSize(); pregunta que yo me he hecho en alguna ocasión. Realmente me gustó la respuesta de Joshua Bloch, comentó que suele haber dos visiones en cuanto a escribir métodos en un lenguaje orientado a objetos: una primera que lo ven todo como un bean, y por lo tanto los métodos para conseguir un valor deberían empezar por get, y otra, como la suya que diferencia las cosas que pueden tener métodos get y set, como puede ser el nombre de una persona dentro de una hipotética clase usuario (.getName() y .setName()), o, como en el caso de size en una lista, que no es una propiedad que pueda tener un setSize(), dado que a la lista se le añaden o quitan objetos, y es eso lo que define su tamaño, por lo tanto el método se llama .size(). También le preguntaron si creían que ahora Java iba detrás de .Net y C#, dado que con la versión 5.0 se le añadieron algunas propiedades que ya existían en C# desde el principio; ellos comentaron que eso no era así, que ya había propuestas de añadir eso a Java desde hace más de 4 años, lo que sucedía, es que todo lo que se añade a Java tiene que ser aprobado por el JCP, y eso llevaba tiempo. Por otro lado, Joshua comentó que llevaba tiempo intentando añadir esas características a Java, pero que nadie parecía tener prisa en ello, hasta que Microsoft se la añadió a C#, con lo cual, gracias a ello, ellos consiguieron implementar esas nuevas y útiles características en Java.

Bueno, antes de acabar con este post, aquí tenéis unas cuantas imágenes de la conferencia:

Aquí tenéis una imagen antes de que empezasen a dar la conferencia, el de la izquierda y de camisa azul es Neal Gafter, y el de la derecha, trabajando en el PowerMac es Joshua Bloch.

Al principio de la charla, ambos destacandonos las mejoras introducidas en Java 5.0.

A mitad de la charla, hablando sobre enums.

Al fina de la charla, componentes de JavaHispano comentaron más información sobre el proyecto JavaHispano y animaron a la gente a colaborar. Neal Gafter y Joshua Bloch escucharon atentamente esos comentarios, el único problema es que no entienden nada de castellano.

Después de la conferencia me tuve que marchar corriendo a pillar mi avión de vuelta a Santiago de Compostela, con lo cual no se si Joshua Bloch y Neal Gafter quedaron explicando al resto de la gente los de los rompecabezas, lo cual sería una pena que me lo hubiese perdido, pero es que los aviones no esperan.

—–

Ya está, ya me he inscrito en el segundo congreso de JavaHispano, si alguien se pasa por allí, pues nos veremos.

—–