Compila tu propio JDK 6

En el weblog de Kelly O'Hair se detallan de un modo simple y esquemático los pasos a seguir para compilar desde el código fuente el JDK 6. Hay instrucciones para realizarlo tanto en Windows como en Linux y Unix. Parece que a partir de ahora no sólo podemos compilar nuestro propio kernel de Linux sino que también podemos compilar nuestro propio JDK.



¿Hay alguien por aquí que haya intentado compilar el JDK o alguna de su partes? ¿nos cuentas tu experiencia?

Documentación preferida para APIs: artículos cortos (encuesta del mes)

Según los resultados actuales de la encuesta parece que los artículos cortos son la forma preferida de aprender una nueva API, seguida de los comentarios de Javadoc. También parece haber consenso en que nombres de clases y métodos significativos no son suficientes para comprender el API. Y un porcentaje de gente significativo (más del 10%) está votando a "otra" (¿qué otros tipos de documentación preferís utilizar?).



Hubo un tiempo en el que los artículos cortos también eran mi forma preferida de aprender una API. Pero mi voto ha sido para el manual de referencia. Si voy a emplear para un tema muy puntual una API probablemente me conforme con buscar algún artículo en Google. Pero si voy a trabajar en serio con ella quiero conocerla en profundidad y eso no se consigue con artículos cortos (o al menos no lo consigo yo). Para mí el manual de referencia o, si hay, el libro son la mejor fuente.



¿Cuál es tu tipo de documentación preferido y por qué?

Liberado Java Plug-in Framework 1.0

Java Plug-in Framework (JPF) es un framework que permite descubrir, instalar y desinstalar plugins en caliente (con la aplicacrión funcionando) en una aplicación Java. Los plugins se definen mediante un documento XML que debe de seguir una DTD creada para tal propósito por los desarrolladores de JPF. En ella se define de modo preciso las distintas interfaces que debe implementar un plugin así como sus puntos de extensión. La arquitectura del framework permite que los plugins instalados en el entorno no causen una penalizacrión en consumo de memoria hasta que el usuario accede a su funcionalidad.



Su modelo de plugins no se basa en el de Eclipse ni tampoco sigue el estándar OSGI. Esto, probablemente, sea la principal crítica que se les puede hacer: han ido por libre con su propio modelo de plugins sin adherirse a los estándares existentes. El framework se distribuye bajo licencia LGPL.



¿Cuántos habéis desarrollado un mecanismo de plugins propio para una de vuestras aplicaciones? ¿Os habéis basado en alguna de las soluciones ya existentes (por ejemplo, las que tienen las plataformas de Eclipse o Netbeans) o lo habéis desarrollado vosotros mismos ?

Release de SpringContracts 0.3

En theserverside anuncian la publicación de la release 0.3 de SpringContracts. Este framework permite introducir diseño por contrato (design by contract) en aplicaciones basadas en spring mediante el uso de AOP y anotaciones.



Principales caracteristicas:



- Permite especificar precondiciones, postcondiciones e invariantes. Las condiciones se especifican mediante anotaciones y se ejecutan mediante el soporte para AOP de spring.

- Se configura a tavés del Application Context de spring.

- Dispone de una arquitectura que mediante el uso de pluggins permite modificar el lenguaje en el que se expresan las condiciones.

- Soporte para diferentes lenguajes a la hora de expresar las condiciones (EL, OGNL, Groovy, java/beanshell añadido en esta realease).



El diseño por contrato es una tecnica que permite comprobar que una clase determinada cumple con el contrato especificado. De este modo cuando alguna clase se salte el contrato inmediatamente se genera un error que nos permite detectar el origen del problema de manera sencilla. Los errores que no se detectan de forma temprana suelen derivar en comportamientos erraticos de la aplicación en ocasiones muy dificiles de determinar.



El diseño por contrato se puede implementar manualmente mediante el uso de sentencias assert, sin embargo si vamos sumando cosas: código para DBC, código para trazas, código de manejo de expcepciones... al final esto da como resultado que la lógica de negocio de los métodos queda difuminada entre tanto código de control/gestión.



El problema es que este código es necesario si queremos realizar aplicaciones robustas. Mediante el uso de AOP y anotaciones podemos evitar el problema de convertir nuestro código en una maraña sin perder la robustez que aportan tecnicas como el DBC.



Lo bueno de este framework: el uso de AOP y anotaciones para la defición de contratos.



Lo malo: Que sólo funciona con spring. Además sólo se puede utilizar sobre beans definidos en el application context. Esta limitación puede ser importante ya que no podemos aplicar DBC sobre clases de dominio no definidas dentro de spring.



¿habeis usado alguna DBC?, ¿os parece importante/necesario?, ¿cual creeis que es la mejor forma de implementarlo?



PD: mi primera noticia en javahispano!

Propuestas para mejorar el soporte de las propiedades en Java

Si hay dos temas candentes respecto a las posibles modificaciones de lenguaje en Java 7 son las closures y las propiedades. El soporte que actualmente proporciona Java para las propiedades es bastante simple (convenios de nomenclatura, básicamente los típicos setX y getX).



Este soporte tan simple obliga a escribir código repetitivo y común a casi todos los casos de uso, pero propenso a fallos si, aunque sólo sea por aburrimiento, nos olvidamos de él. Ejemplos de este código son chequear las restricciones que debe cumplir una nueva propiedad que se modifica mediante el método setX (¿cuántas veces habéis mirado si esa propiedad era o no null?), lanzar un evento cuando se modifica una propiedad, realizar alguna acción (como repintar el componentes si es un componente gráfico), etc.



Danny Coward, un empleado de Sun, ha presentado una propuesta para las propiedades que añadiría una palabra reservada al lenguaje:

public property String name;

El añadir esta palabra reservada haría que se generasen de modo automático los métodos geters y seters. Además, se podría acceder a las propiedades mediante el operador -> por ejemplo:

bean.setName("Joe")

String name = bean.getName()

Se podría escribir como:

bean->name = "Joe"

String name = bean->name

Mikael Grev, autor de una entrada de Javalobby donde se discute en profundidad este tema propone emplear anotaciones:

@Property(bound = true, notnull = true, onChange = "repaint();")

public property Color color = Color.BLACK;

Este ejemplo define una propiedad que no puede ser null, que genera un evento al cambiar su valor (sólo si éste realmente cambia) y que cuando cambia su valor invoca al método repaint().



Ambas propuestas pueden considerarse en cierto modo complementarias. No obstante, la de Danny Coward es más agresiva en el sentido de que supone cambiar el lenguaje, el compilador y las herramientas de desarrollo como los IDEs. La de Mikael Grev supondría muchos menos cambios y soluciona problemas (código repetitivo) que la otra no.



¿Cuál os gusta más? ¿creéis que es necesario mejorar el soporte de propiedades que haya java actualmente ?