Excelente artículo sobre las excepciones en Java

Se trata de un artículo que pretende explicar al lector cómo emplear adecuadamente las excepciones en Java, sobre todo cuándo hacerlas "cheked" y "uncheked". Las excepciones que se correspondan con casos de uso excepcionales pero esperados (por ejemplo, el nombre que indica un usuario que se quiere registrar en nuestra aplicación web ya existe) deberían ser cheked ya que el código cliente que llama al código que lanza la excepción debe y puede gestionarla.



Cuando las excepciones se corresponden a bugs o fallos de infraestructura (disco duro lleno, no hay red, la base de datos lanza una excepción...) las excepciones deberían ser uncheked porque el código cliente no va a poder hacer nada para gestionar la excepción. Si no hay red, por ejemplo, no hay nada que hacer. Estas excepciones deberían capturarse muy cerca de la interfaz de usuario, probablemente en algún tipo de bucle que gestione todos los eventos. El resto del código no debería ocuparse de ellas, ni capturarlas ni lanzarlas. Capturar o lazar este tipo de excepciones lo único que consigue es escribir un montón de código inútil.



Según el autor del artículo, las excepciones en Java sí están bien pensadas (cosa en la que no está de acuerdo todo el mundo) pero algunas partes de la librería estándar hacen un uso incorrectas de ellas lo cual lleva a pensar que hay algún problema con las excepciones, cuando el problema está en la librería.



Yo estoy totalmente de acuerdo con el lector y definitivamente recomiendo que leáis el artículo. ¿Cuál vuestra opinión respecto a este tema?

Bittyrant, un nuevo cliente java de BitTorrent

Aunque, realmente, sólo es nuevo a medias. Bittyrant es nuevo cliente java de BitTorrent que está basado en Azureus 2.5. Lo que aporta respecto a Azureus son los algoritmos para gestionar qué otros clientes se descargan el material, y digo mejores algoritmos porque (al menos según sus creadores) este cliente respeta las reglas de juego de BitTorrent (cuanto más permitas a los demás descargar más podrás descargar tú).


Según sus creadores, "jugando limpio" consiguen hasta un 70% de incremento en el rendimiento respecto a Azureus 2.5. Los creadores de Bittyrant no comparan su velocidad con el cliente Zudeo que puede considerarse "Azureus 3".


Además de ser otro excelente ejemplo de una aplicación Java de escritorio de éxito (o al menos eso esperamos) al igual que Azureus, Bittyrant probablemente va a contribuir a que haya más máquinas virtuales instaladas de equipos clientes, lo cual es bueno para la plataforma Java.

Diseño Por Contrato

Buenos días.



El tema de esta noticia y reflexión es el Diseño Por Contrato (abreviado DPC), aprovechando la noticia de SpringContracts recientemente publicada por un compañero nuestro.



Recuerdo haber pasado casi un año en la facultad estudiando la verificación y derivación de algoritmos recursivos e iterativos sobre el papel, amén de la especificación algebraica de tipos abstractos de datos. Cierto es que me permitió adquirir un conocimiento más profundo de qué es y cómo funciona realmente un algoritmo, pero siempre me planteé, al igual que mis compañeros, dónde se encontraba la utilidad práctica de esos conocimientos cuando en ningún proyecto de laboratorio se hacía uso de ellos. Hasta que leyendo por mi cuenta me topé con el libro Construcción de Software Orientado a Objetos, escrito por Bertrand Meyer. Este caballero es el padre del lenguaje Eiffel, el cual lleva incorporado nativamente el DPC -en inglés Design By Contract, abreviado DBC-.



El DPC es una herramienta que ayuda a producir software libre de errores determinando para cada módulo de la aplicación cuál es el contrato que debe cumplir. Se entiende por contrato qué estado debe verificar el sistema para poder ejecutar ese módulo, lo que se llama precondición, y qué estado, llamado postcondición, debe alcanzar el sistema cuando se termina de ejecutar correctamente el módulo habiéndose cumplido previamente la precondición. Si no se cumple la precondición, como es lógico, no se puede garantizar que el módulo satisfaga la postcondición. Además de precondiciones y postcondiciones, existen otros tipos de asercioens: invariantes de clase, invariantes de bucle y variantes de bucle.



El DPC es complementario a las pruebas, en ningún caso son incompatibles ni excluyentes. Es una herramienta que aprovecha todos esos conocimientos teóricos que se estudian en los libros de corrección de algoritmos para lograr por fin darles un enfoque útil. Obviamente no es fácil. Supone, utilizando un lenguaje de programación, escribir aserciones en lógica de primer orden, lo que no es sencillo. También requiere un esfuerzo para tratar de entender de forma precisa qué hace realmente nuestro módulo, para ello acotando y delimitando responsabilidades que han de ser descritas de forma lógica.



La comprobación de las aserciones supone un coste en tiempo de ejecución, como es lógico, por lo que en desarrollo se suelen dejar activos todos los controles, y una vez que se está en producción se suelen quitar los controles o, lo que es más seguro y supone un compromiso razonable, se deja activa sólo la comprobación de que se verifican las precondiciones.



Un libro muy interesante es Design by Contract, by Example, de Richard Mitchell y Jim McKim, en el que se explica con detalle esta herramienta, empleando Eiffel en todos los capítulos, excepto en el último, donde muestra cómo usarla con Java utilizando un preprocesador llamado iContract. Desde que apareció el DPC han surgido varias herramientas que pretenden soportar el DPC en Java, algunas no actualizadas y otras con gran actividad.



Como realmente no las he probado, no puede decir mucho sobre ellas salvo breves indicaciones.



JMSAssert (http://www.mmsindia.com/JMSAssert.html) lleva algún tiempo parado. JContract (http://www.parasoft.com/jsp/products/home.jsp?product=Jcontract) es de pago. JContractor también lleva tiempo parado. A Barter (http://barter.sourceforge.net/) le pasa algo parecido.



La herramienta iContract estuvo algún tiempo abandonada, pero hace poco ha sido resucitada en iContract2 (http://www.icontract2.org/) y parece estar activa. Jass (http://csd.informatik.uni-oldenburg.de/~jass/index.html) sigue un proceso lento pero parece que sin detenerse. En la próxima versión utilizará para las aserciones el JML -o Java Modeling Language- (http://www.cs.iastate.edu/~leavens/JML/), que es un lenguaje de especificación formal de interfaces que mezcla conceptos del DPC, de la familia de lenguajes formales Larch y elementos del cálculo de refinamiento. Se puede emplear el JML de forma aislada para DPC, pero la curva de aprendizaje es demasiado grande debido a que su área de aplicación va más allá del Diseño Por Contrato, por lo que es mucho más práctico utilizar una herramienta aparte.



Otra herramienta interesante es contract4j (http://www.contract4j.org/contract4j) que usa aspectos y anotaciones. Todavía no trata correctamente la herencia al implementar el DPC, aunque parece que pronto estará solucionado. Es compatible con Java SE 5 y 6. El último proyecto que voy a indicar es C4J (http://c4j.sourceforge.net/), también compatible con Java SE 5 y 6. Tiene bastante actividad y parece estar avanzado.



Y ahora las preguntas de rigor... ¿os parece factible usar el DPC en aplicaciones reales? ¿Creeis que la curva de aprendiza es demasiado grande? ¿Lo veis difícil o poco útil? ¿Habéis tenido alguna experiencia al respecto?



Un saludo,

José María

SJSX - Simple JavaScript Xmldatabinding

Recientemente han publicado un proyecto Open Source para generar clases JavaScript que representan la estructura de un XML, a partir de un esquema (XSD). Se llama SJSX (Simple JavaScript Xmldatabinding). Lo podéis bajar desde SourceForge http://sourceforge.net/projects/sjsx



Está bajo licencia Apache 2.0, o sea. Es muy útil para pasar datos de manera asíncrona (AJAX) desde javascript cliente al servidor. Si no os gusta JSON esto es un alternativa más "elegante".

Encuesta sobre el rendimiento de Netbeans 5.5

El equipo de Netbeans ha creado esta encuesta para saber si los desarrolladores están contentos con el rendimiento de la versión 5.5. Si te tomas unos minutos para cubrirla contribuirás a mejorar Netbeans.


Al margen de la encuesta ¿cuál es nuestra opinión sobre el rendimiento de Netbeans? ¿Pensáis que es mejor o peor que el de Eclipse?