EclipseGavab 2.0

EclipseGavab es una distribución de Eclipse que desarrollamos en Sidelab y venimos usando desde hace más de 5 años en la Universidad Rey Juan Carlos como el IDE de referencia en asignaturas de paradigmas y programación. El principal valor de EclipseGavab es que integra soporte para diferentes de lenguajes de programación permitiendo que los alumnos se familiaricen con un único entorno y se puedan centrar en el lenguaje concreto. En aquellos casos en que ha sido posible, incluye también los correspondientes compiladores/intérpretes/máquinas virtuales de dichos lenguajes.

Lenguajes soportados:

  • Java
  • C/C++ (en Windows incluye compilador basado en cygwin)
  • Pascal y ObjectPascal (en Windows incluye el compilador FreePascal)
  • PascalFC (incluye compilador e intérprete en Windows y Linux)
  • Ruby (en Windows incluye intérprete Ruby)
  • Haskell (en Windows incluye ghc)

Puedes descargar EclipseGavab de los siguientes enlaces:

  • EclipseGavab 2.0 Windows Installer (300Mb). Windows XP and Windows Vista installer. Requires 660 Mb.
  • EclipseGavab 2.0 tar.gz for Linux. A tar.gz Linux distribution. It requires the installation of the following tools: Java SE 6 for executing EclipseGavab and Java programming; gcc for C/C++ programming; FreePascal for Pascal programming; ghc for Haskell programming; and Ruby for Ruby programming.

En Ubuntu, los paquetes necesarios son: build-essential, fp-compiler, fp-units-base, fp-units-rtl, ghc6, ruby, sun-java6-jre, y se pueden instalar con el siguiente comando:

sudo apt-get install build-essential fp-compiler fp-units-base fp-units-rtl ghc6 ruby sun-java6-jre

[Editado el 7/2/2014]

En Ubuntu 64 bits es necesario usar una versión Java de 32 bits. En Windows esto no es necesario porque EclipseGavab lleva una versión de java de 32 bits embebida. Se puede descargar el jdk 7 de 32 bits de esta url, pulsando en «Java Download» y seleccionando después la versión «linux x86» de extensión tar.gz.

Una vez descargado Java, se descomprime (tar -xvzf jdk-7-xx.tar.gz) en el home del usuario y se edita el fichero eclipse.ini para que utilice esta versión de Java. Supongamos que la ruta es «/home/user/jdk-7-u51», el fichero eclipse.ini debe incluir las siguientes líneas inmediatamente antes de la opción «-vmargs»:

-vm
/home/user/jdk-7-u51/bin/java

Enjoy programming!

Sidelab Commons

SidelabCode tiene un nuevo proyecto, liberado bajo una licencia de código abierto. Se trata de Sidelab Commons. El objetivo de Sidelab Commons es exportar pequeñas librerías de utilidad para que puedan ser utilizadas desde otros proyectos.

Para explicar en más detalle el objetivo del proyecto, aunque muchos ya habrán realizado una asociación con el proyecto Apache Commons, nos centraremos en un caso particular. En varias ocasiones nos hemos encontrado con la necesidad de invocar comandos, a través de la API Runtime (más concretamente Runtime.exec), desde java. Además, esta funcionalidad la hemos requerido desde proyectos muy diferentes:

  • En Optsicom Remote Experiment System (Optsicom RES) se utiliza para ejecutar en una máquina remota un programa Java arrancando una nueva VM.
  • En Optsicom Framework se utiliza para ejecutar un experimento en una VM diferente.
  • En Pascaline, un plugin de Eclipse para Pascal, se utiliza para invocar el compilador de FreePascal.
  • SidelabCode Stack, el instalador de la forja de SidelabCode, se utiliza para invocar apt-gets y todo tipo de comandos que permiten configurar adecuadamente los servicios de la forja.
  • En proyectos que hemos desarrollado para empresas también hemos necesitado invocar comandos externos a menudo.

El uso de Runtime.exec no es trivial. Además de las diferentes versiones disponibles, hay que tener en cuenta la captura de la salida estándar y la salida de error del proceso que se está lanzando. Normalmente, para cerciorarnos de que el proceso ha terminado correctamente es necesario:

  • Al terminar el proceso comprobar el código de salida
  • Recuperar la salida estándar
  • Recuperar la salida de error

La recuperación de las salidas del proceso requiere la creación de un hilo para la salida estándar y otro para la salida de error que consumen los datos de los respectivos InputStreams hasta que el proceso los cierra. Básicamente, el código tiene este aspecto:

new Runnable() {
  public void run() {
    try {
      byte[] buffer = new byte[1024];
      int leidos = 0;
      while ((leidos = System.in.read(buffer)) != 0) {
        out.write(buffer, 0, leidos);
      }
    } catch (Exception e) {
      throw new RuntimeException(e);
    }
  }
}

Como esto es tedioso de hacer cada vez, en su día lo factorizamos en una pequeña librería que llamamos commandline. Ahora, hemos abierto el proyecto Sidelab Commons para alojar este tipo de recursos. Actualmente, cualquier proyecto puede hacer uso de commandline, y obtener de forma sencilla la salida de un proceso:

CommandLine cl = new CommandLine(); // Opcionalmente podríamos especificar el dir de trabajo en el constructor.
CommandOutput co = cl.syncExec("tail /etc/apache2/sites-enabled/default");
System.out.println(co.getStandardOutput());
System.out.println(co.getErrorOutput());

Puedes descargar commandline o añadirlo como dependencia a tu pom. Echa un vistazo a nuestro archiva.

Por cierto, recuerda que cuando invocas comandos desde Java, no estás ejecutando el comando dentro de una shell, y por tanto no funcionan los wildcards (cosas como ls *.java). Si necesitas realmente ejecutar tu comando desde una shell para que te interprete adecuadamente este tipo de comodines usa bash -c ‘ls *.java’ o mira la documentación de la shell que soporte tu sistema. Nosotros, por ejemplo, hemos tenido problemas ejecutando un proceso en Windows y tuvimos que utilizar «cmd /c» para correrlo dentro de la shell de Windows en modo no interactivo. Puedes echar un vistazo a esto en el proyecto Pascaline.

Programación (segura) en Java

A no ser que estés programando una prueba de concepto, deberías programar pensando en la seguridad del código. Incluso aunque estés programando una prueba de concepto, deberías programar pensando en la seguridad del código. ¿Por qué? Porque no nos engañemos… hay una alta probabilidad de que las pruebas de concepto acaben en producción tarde o temprano.

Acaba de publicarse The CERT Oracle Secure Coding Standard for Java, un libro con buenas prácticas de programación segura en Java. Ahora mismo estoy haciendo la petición a la biblioteca de la URJC.

 

 

Las aplicaciones Java y el logging

Vía The Server Side, me he encontrado con el artículo cuyo enlace copio debajo. Se trata de un repaso histórico por las diferentes tecnologías de logging en Java. Aclara muchas zonas grises y permite tomar una decisión razonada sobre cuál de todas ellas nos puede interesar.

Al parecer hay un desarrollador que se ha implementado nada menos que tres apis: log4j, slf4j y logback. En cada nueva implementación ha tratado de solucionar los problemas de apis anteriores. Merece la pena leerlo y no es muy largo.

Java Code Geeks: The Java Logging Mess: http://www.javacodegeeks.com/2011/09/java-logging-mess.html?m=1

Entrevista a Joshua Bloch en InfoQ

En InfoQ publican una entrevista a Joshua Bloch, uno de los grandes artífices de lo que es hoy en día Java, que actualmente trabaja para Google. Parece que Bloch es uno de los que están en contra de modificar el lenguaje Java si esto añade más complejidad al mismo, y prefiere limitarse a modificaciones que «limen»  ciertos aspectos mejorables, como la verbosidad de los generics o las clases anónimas, pero sin introducir nuevas características que pueden suponer un quebradero de cabeza (y un peligro) para los programadores.

En este sentido, se muestra partidario del Project Coin, que simplemente hace más sencilla la utilización de generics (con el operador diamante) y la gestión de recursos en los bloques try, entre otros.

Sin embargo se muestra en contra del Lambda Project. Según Bloch, este es uno de los proyectos que introducirían una complejidad dañina, en este caso las closures o typed functions. Y pone un ejemplo muy concreto: una closure que tenga acceso a las variables locales del método donde es definida obliga a que el ciclo de vida de estas variables se prolonge más allá del final de la invocación del método. El recolector de basura no puede recolectar los objetos referenciados por estas variables mientras puedan ser accedidos por la closure.

Por otro lado, al ser preguntado sobre el futuro de la programación (en general), Bloch no se corta al prever un nuevo «gran lenguaje» al estilo de C y Java. Y basa su afirmación en que hay problemas aún no resueltos de manera completamente satisfactoria por los lenguajes actuales como la programación multi-core y el desarrollo de aplicaciones web.

La entrevista es muy interesante, y una de las recomendaciones que hace es aprender múltiples lenguajes y paradigmas. La entrevista completa aquí: Interview:Josh Bloch on Java and Programming.

¿Cuál es el rendimiento real de nuestro código Java?

En la parte de nuestro trabajo relacionada con la investigación nos dedicamos a resolver problemas de optimización y es crítico que la implementación de la solución a un determinado problema sea lo más eficiente posible. La eficiencia se puede medir de muchas maneras, pero a día de hoy nos preocupa sobre todo la velocidad. En general los métodos de resolución que implementamos realizan varias tareas y cuanto menos tiempo emplees en una de ellas, más tiempo tendrás para dedicar a las demás.

Por eso me ha parecido muy interesante el artículo de James Sutherland: What is faster? JVM Performance. En él se analiza la eficiencia de varias estructuras de datos (Map y List), así como el tiempo empleado en recorrerlas utilizando los diferentes mecanismos proporcionados por Java (for con índices, iteradores, for mejorado) y por último la eficiencia de diferentes mecanismos de invocación de métodos (invocación normal, método final, invocación por reflexión, …) Merece la pena echarle un vistazo.

Google propone dos proyectos a la plataforma Eclipse

Google va a donar dos proyectos a la fundación Eclipse. El primero de ellos es WindowBuilder, una herramienta de diseño de interfaces de usuario que soporta SWT y Swing, al estilo del proyecto Visual Editor (VE) que se había quedado algo atrás. El segundo es CodePro Profiler, un profiler de aplicaciones Java.  Ambos proyectos pasaron a manos de Google cuando ésta adquirió Instantiations.

La forma de donar el código es un poco esotérica, dado que deben seguir la norma de cualquier otro proyecto, el denominado Eclipse Development Process: han hecho dos propuestas de proyectos a la Fundación Eclipse (ambas bajo el paraguas del Eclipse Tools Project): WindowBuilder y Runtime Analysis Tools. Estas dos propuestas tienen que ser aprobadas y después el código tiene que pasar el estricto IP process. Este es el proceso por el cual la Fundación Eclipse acepta contenido, lo redistribuye y en general gestiona todo lo referente a la propiedad intelectual de la Fundación.

Lo interesante es que han dicho que van a tratar de alcanzar el Release Train de Indigo, la siguiente versión de Eclipse (de la que ya hablamos aquí) que verá la luz en Junio de 2011. Un Release Train en Eclipse es una «macro» release, dado que múltiples proyectos acuerdan sacar conjuntamente una nueva versión en la fecha señalada. En el caso de Eclipse esto se hace cada año en junio. Si tenemos en cuenta que el proyecto debe aprobarse todavía, después entra en fase de incubación y finalmente pasa a la fase de madurez, no sé si realmente les va a dar tiempo.

Lo que está claro es que, salvo que sorprendentemente decidieran algo en otro sentido, el código será aceptado por la Fundación con licencia EPL. Es una buena noticia saber que Eclipse contará en breve con un profiler integrado (algunos usamos VisualVM, que tiene muy buena integración con Eclipse) y con una herramienta de diseño de interfaces que, además, promete integrar también GWT.

La noticia original la vimos de la mano de Mike Milinkovich: Christmas Comes Early for Java Developers. Otros miembros de la Fundación también lo han comentado. Y algunos no han querido que nos olvidemos de aquellos que donan año tras año miles de líneas de código a Eclipse a través de sus committers:

@: News:Google donates $5m worth code to Eclipse. Not-In-News:IBM donating >$5m worth code *every* year via its committers

Kudos to IBM and every Eclipse committer out there!