Oracle Toplink se vuelve opensource: EclipseLink 1.0

El primer ORM Java se ha vuelto opensource. Se ha anunciado la versión 1.0 del proyecto Eclipse Persistence Services, también llamado EclipseLink. Este proyecto se volverá la implementación de referencia del estándar JPA 2.0, reemplazando a TopLink Essentials e inició cuando Oracle donó todo el código de TopLink para ello.

Como es de suponer, EclipseLink implementa JPA 1.0 (el soporte a la 2.0 será añadido más tarde), pero también soporta Service Data Objects 2.1  (SDO), MOXy (Binding a XML usando JAXB) y está listo para ser usado como un bundle de OSGi.

Al ser la implementación de referencia de JPA 2.0, EclipseLink se distribuirá junto con GHlassfish v3, los productos Oracle WebLogic e incluso con el SpringFramework.

Sun publica VisualVM: herramienta visual para rastrear problemas en la JVM

Sun -junto con el jdk 6 update 7- , ha publicado la Java VisualVM una herramienta que fue anunciada en el pasado JavaOne y que permite detectar y rastrear problemas directamente analizando la Java Virtual Machine. VisualVM incorpora herramientas de otros proyectos como jstack, JMX y el profiler de Netbeans. Sus creadores se refieren a la herramienta como a un GUI para los comandos de java 6 que permiten analizar la JVM más un profiler y un monitor de memoria y CPU.Estos monitores son muy ligeros y añaden poco overhead al sistema, por lo que se pueden usar en ambientes de producción.

VisualVM intenta ser la herramienta todo-en-uno para analizar tu JVM, para ello permite analizar el consumo de memoria, de cpu, mostrar información sobre las aplicaciones ejecutándose, analizar thread dumps, head dumps y core dumps, etcétera. Puedes revisar toda la lista de las características en el sitio de la herramienta. 

Además de eso, es extensible mediante plugins. Por ahora ya existen algunos como un  navegador de MBeans y uno específico para Glassfish. 

VisualVM es opensource bajo la licencia GPL v2 con la excepción classpath, puedes ver el demo que se hizo en el JavaOne con esta herramienta aquí. 

Adobe va a desarrollar una implementación de SWT sobre Cocoa

Hasta ahora nadie se había mostrado dispuesto a crear un porte de SWT sobre la nueva librería gráfica de Mac OS, Cocoa. SWT es una librería gráfica para Java que, a diferencia de swing, no recurre a la emulación de componentes a no ser que sea estrictamente necesario, sino que trata de usar siempre que sea posible componentes nativos de la plataforma. Esto lo hace dependiente del sistema operativo, a diferencia de swing, y obliga a que para cada plataforma haya que crear un implementación de SWT.

Hasta ahora nadie se había apuntado a la ardua tarea de crear un porte de SWT para Cocoa. Parece que Adobe, impulsado por la necesidad de ofrecer un buen soporte para su herramienta Flex builder (herramienta construida sobre la plataforma de Eclipse) en Mac OS va a liderar este porte. Indudablemente, esto va a beneficiar a todos los que uséis Eclipse en este sistema operativo.

Aprovecho la noticia para hacer una pequeña encuesta ¿cuántos de vosotros usáis swing y cuanto usáis SWT?

NetBeans 6.5 Milestone 1

Está disponible la Milestone 1 de NetBeans 6.5. En esta nueva versión el principal énfasis parece estar en cosas no- Java: soporte para PHP, soporte para Groovy y Grails, soporte para Spring e Hibernate, y mejoras en soporte de Ruby, C y C++ son las principales novedades. Esta versión también traerá mejoras en los asistentes para conexión y exploración de bases de datos, mejoras en el debugger, en especial cuando se trabaja con aplicaciones con varios thread, y mejoras en el soporte de UML.

Si hay dos cosas que me han sorprendido son, indudablemente, el soporte para Spring e Hibernate. Desde mi punto de vista, hasta ahora Sun ha empleado NetBeans como un ariete para impulsar y promocionar las tecnologías estándar (en el sentido de estar bendecidas por el Java Community Process) de la plataforma Java. Esto sucede hasta tal extremo que uno de mis consejos a la hora de responder a la pregunta ¿qué uso, NetBeans o Eclipse? es "si sólo vas a usar cosas estándar (Java EE, JPA, JSF, EJB...), NetBeans, si vas a usar soluciones no estandarizadas bajo un JSR (Hibernate, Spring, Velocity, Wiket...) Eclipse.

¿Supone el soporte de Spring e Hibernate un cambio en esta política?. Espero que sí, y por mi parte el cambio es bienvenido. Sin él seguirá habiendo campos en los que NetBeans no puede competir con Eclipse (por ejemplo, desarrollos de aplicaciones Spring en el caso de NetBeans 6.1 vs Eclipse 3.4).

Implementación de Smalltalk en Java

Si hay por aquí algún apasionado de lenguaje de programación que puede considerarse el padre (bueno, quizás el abuelo) de todos los lenguajes de programación orientados a objetos y uno de los lenguajes de programación que, hasta la fecha, se mantiene como uno de los más influyentes en la evolución de la ingeniería de software (por supuesto, estoy hablando de Smalltalk ) tengo buenas noticias para él: existe un intérprete de Smalltalk (bueno, realmente su versión opensource squeak) implementada completamente en Java: Jsqueak.

Está desarrollada por los laboratorios de investigación de Sun y en su web hay documentación sobre cómo usar este lenguaje desde NetBeans. Aunque no creo que a nadie se le dé por desarrollar su próxima aplicación web con él, puede ser un divertido pasatiempo para este verano echarle un vistazo a este proyecto.