JUDE, entorno de desarrollo Java+UML

A través del RSS de JavaToolbox.com (http://www.javatoolbox.com) acabo de descubrir esta herramienta UML: JUDE (Java and UML Developers' Environment). Como otros entornos similares, JUDE permite la creación de los diversos diagramas utilizados en diseño orientado a objetos usando UML.



A través de plantillas facilita la generación de código Java a partir de los diagramas realizados, así como la importación de código Java al entorno.



Dispone de versiones Community (gratuita) y Professional (de pago).



Según javatoolbox.com, la principales características de JUDE son (algunas sólo están disponibles en la versión Professional):

- Soporte para UML 2.0 (parcial) y UML 1.4 (completo)

- Mind maps

- Conversión entre mind maps y UML

- API: desarrollo de aplicaciones usando el modelo de datos de JUDE (diagrama de clases, casos de uso y mindmaps)

- Exporta a RTF y HTML

Información sobre tipos genéricos en tiempo de ejecución

La gran carencia de generics en java es la imposibilidad de obtener información acerca del tipo de una clase genérica; por ejemplo, en tiempo de ejecución yo no puedo saber si un objeto de tipo List es un List <String > o un List<Float>. El motivo es que en java, a diferencia de C++, los tipos genéricos no son más que un edulcorante sintáctico que evita hacer unos cuantos cast y que permite al compilador realizar ciertos chequeos estáticamente. Sin embargo, toda la información acerca del tipo genérico es eliminada al crear el bytecode, de tal forma que un List para la máquina virtual siempre contiene Objects.



En su día se tomó esta decisión para hacer compatible el bytecode de Java 5 con las versiones anteriores, así como para no necesitar añadir una nueva versión de muchas librerías estándar (en especial el framework de colecciones) a la distribución del entorno base de la plataforma donde las clases fueran genéricas. C# en su versión 2.0 optó o por este segundo camino (tener una librería genérica y otra no genérica). Pero en su caso tenía una base de código muy pequeña y las molestias para los usuarios finales no iban a ser excesivas.



Ahora Neal Gafter, ex empleado de Sun, empleado de Google y una de las personas que ha jugado un papel más importante en el diseño de Java 5, reflexiona en su weblog sobre cómo se podría añadir información acerca de los tipos en la plataforma. Propone dos caminos diferentes. Uno, usar anotaciones, lo cual impediría que el código genérico fuese empleado por código no genérico. Este camino no requiere una modificación al lenguaje.



La otra alternativa es modificar el lenguaje incluyendo una nueva sintaxis para definir tipos genéricos cuya información se mantendrá en tiempo de ejecución. El cambio consistiría en escribir <class T> en vez de <T>. El código que usase los tipos generics podría ser código genérico o no genérico. El que usase los nuevos generics tendría que ser código genérico. Esta alternativa requeriría construir una nueva implementación de todo el framework de colecciones.



Cualquiera de los dos cambios requeriría modificaciones muy profundas en la máquina virtual, compiladores y librerías.



¿Crees que merece la pena aplicar una de estas dos propuestas para obtener información en tiempo de ejecución sobre los tipos genéricos? ¿Alguna vez has necesitado hacer esto?

JCite, citar código Java en documentos HTML

JCite (Java Source Code Citation System) es una pequeña utilidad que permite incluir fragmentos de código Java dentro de un documento HTML. Puede ser útil tanto para escribir un tutorial web como para incluir ejemplos dentro de los comentarios de javadoc. El código Java empotrado emplea colores para la sintaxis gracias al uso de la herramienta Java2HTML.



Es una pena que la herramienta se limite sólo a la documentación generada en HTML. ¿Alguien conoce soluciones similares que permitan incluir código Java en otro tipo de documentación?. Yo he usado bastante el paquete listings para LateX, pero probablemente por este barrio pocos empleáis ese formato para vuestra documentación.

Netbeans pretende construir su dream team

El proceso de selección ya comenzado, se busca a las 10 personas más activas dentro de la comunidad de Netbeans, personas que participen en eventos de promoción, en los foros y listas de distribución, etc. Por supuesto, todas ellas deberán de ser gurús de este entorno del desarrollo. Y eso sí, los empleados de Sun no son elegibles: se pretende que esta iniciativa esté conducida por y orientada a la comunidad.



Esas primeras 10 personas serán los componentes iniciales del dream team. Pero una vez haya sido construido el equipo serán ellos mismos los que guíen la evolución y las normas por las cuales se regirá el grupo, inclusive la admisión de nuevos miembros. Hasta el viernes 17 de noviembre se pueden enviar propuestas de posibles candidatos para dicho equipo; Netbeans.org elegirá quienes son los 10 miembros iniciales en base a las propuestas enviadas.



¿Qué os parece esta iniciativa? ¿Existe alguna iniciativa similar para Eclipse?

Liberado plugin de Soapui (desarrollo de servicios Web) para Netbeans

Soapui es una aplicación de escritorio que permite explorar, invocar, desarrollar y realizar tests funcionales y de estrés sobre servicios web. El proyecto se distribuye bajo una licencia libre y podéis lanzar la aplicación mediante Java Web Start a partir de este enlace.



Este fin de semana el equipo de Soapui ha anunciado la disponibilidad de la primera versión (una beta por lo de ahora) de un plugin para Netbeans que permite integrar la funcionalidad de Soapui en este entorno de desarrollo. También existen plugins para IDEA (beta 2) y para Eclipse (por lo de ahora es sólo una versión 0.4).



¿Alguien tiene experiencia trabajando con esta herramienta o alguno de sus plugins?