Ando un poco liado y llevo una temporada sin escribir. Hay un apunte, que es común para varios lenguajes que son Java y por ejemplo .Net, tanto Visual Basic .Net y C#, así como el resto de lenguajes de la plataforma .Net que es la clase StringBuilder. Hay gente que no sabe por que o cuando utilizar la clase StringBuilder y realmente es uno de esos pequeños detalles de buenas prácticas, que a simple vista en un proyecto pequeño no se aprecian, pero cuando entre manos tenemos un gran proyecto que recibe millones de peticiones diarias, estas pequeñas nuevas practicas pueden suponer un gran referente de ahorro en el consumo de memoria y procesador de un servidor.

Tanto en Java como en .Net, cuando creamos un nuevo String, instanciamos un objeto String en una variable, cuando con la sentencia "+=" vamos concatenando mas texto, lo que hacen estas plataformas es crear una nueva instancia del objeto con la concatenación de las dos variables de texto. Por otro lado, cuando tenemos un StringBuilder instanciamos una clase StrringBuilder, llamando al método "append" en Java y "Append" en .Net, lo que hacemos es realizar una concatenación real de texto en el buffer de texto para luego instanciar un nuevo objeto String cuando llamemos al método "toString" en Java y "ToString" en .Net. A simple vista parece una tontería, cuando tenemos un texto que concatenamos 2 o 3 veces, realmente no merece la pena generar un StringBuilder, pero cuando concatenamos repetidamente texto varias veces el rendimiento es mayor si utilizamos StringBuilder, ya que si tenemos 20 concatenaciones seguidas, utilizando Strings normales concatenados, tendríamos 20 instancias de objetos, mientras que con StringBuilder solo 2. Como he dicho antes, en un pequeño proyecto, esto es prácticamente inapreciable, pero cuando tenemos un proyecto que recibe millones de peticiones diarias, algo tan tonto como utilizar concatenaciones de texto o StringBuilder puede suponer tener que añadir mas memoria al servidor para soportar tantas instancias de objetos e incluso un procesador mas potente para soportar el paso del recolector de basura para tantos objetos instanciados, esto en el mejor de los casos, si no llegamos al caso de tener que añadir un servidor al cluster para soportar todo esto.

Un cumulo de buenas practicas pueden suponer un gran ahorro de recursos, que se traducen en ahorro de dinero, cuando se trata de grandes proyectos.

No hace mucho descubrí JOGL, es una librería de Java para poder acceder directamente a , gracias a los plugins de NetBeans. Con JOGL podemos crear desde juegos tridimensionales, en 3D, hasta aplicaciones con una mayor funcionalidad y mayor vistosidad en cuanto a gráficos se refiere.OpenGL

JOGL es una libreria que utiliza el JNI de Java para acceder a las funcionalides de C, por lo que el acceso a las funciones implementadas de OpenGL en JOGL, son realmente rápidas. Además de ofrecer todas las funciones de OpenGL, tiene una perfecta implementación con las librerías gráficas de Java AWT y Swing, por lo que podemos llegar a embeber OpenGL no solo dentro de la ventana, sino en controles, como por ejemplo crear efectos tridimensionales en botones.

Desde la página de plugins para NetBeans, podremos instalar el plugin de JOGL para NetBeans que nos ofrece ademas de una plantilla de aplicaciones JOGL, multitud de ejemplos para poder empezar a desarrollar. El sistema para instalar el plugin es descargar dicho plugin desde la página de NetBeans y luego en paquetes disponibles dentro de la sección de actualizaciónes (plugins) de NetBeans, encontramos una nueva categoría de JOGL desde la que podemos instalar todo lo que necesitamos. Si queremos instalar las librerías de JOGL independientemente de NetBeans o queremos ver algunos ejemplos o descargas como el JavaDoc de JOGL, que viene muy bien, podemos buscarlo en la página oficial del proyecto JOGL.

A partir de aquí, ya podemos empezar a realizar nuestras primeras pruebas y el resto ya depende de nosotros. Yo personalmente, tengo un libro de OpenGL para C y puedo decir que el 95% de las sentencias que aparecen en dicho libro, pueden implementarse sin dificultad en JOGL.

Como hace poco he reinstalado todo el sistema operativo y he sustituido mi Ubuntu 7.10 por PCLinuxOS que me va mucho mejor, estoy todavía instalando aplicaciones. Ya instalé como escribi en una entrada anterior juntando Eclipse con Aptana, pero ahora le toca el turno a NetBeans que me gusta más como editor de Java y como no, para probar los nuevos juguetes que tiene como el plugin de OpenGL de NetBeans 6 que promete mucho.

El caso es que cuando me bajo el instalador y lo ejecuto, sorprendentemente la ventana del instalador esta vacia. Todo esta en blanco, sin nada. Me daba algunos errores de ClearLook, pero el problema no era ese. Buscando y probando muchas cosas al final doy con la clave. El problema es que tengo Beryl corriendo (al parecer tambien ocurre con Compiz-Fusion) y parece ser que he ahí el problema, ya que tenemos que declarar la siguiente variable en el sistema:

AWT_TOOLKIT="MToolkit"

Esto lo haremos añadiendo la linea anterior en el archivo /etc/environment. Con esto ya podemos instalar NetBeans 6 Beta 2 con normalidad y usarla.

Por esas casualidades de la vida y probando un sistema de funcionamiento en una aplicación de Java a partir de la hora del servidor, hicimos pruebas cambiando la hora del sistema para probar que todo funcionaba correctamente. Mientras modificábamos la hora del sistema para comprobar el buen funcionamiento, encontrábamos algún que otro bug, que corregíamos recompilando sobre la marcha.

Después de 30 minutos de constantes pruebas, y cuando nos disponíamos a realizar la compilación definitiva para realizar un pequeño parche en el sistema nos encontramos con un problema, ¡No podemos compilar! Tenemos un problema, Java nos dice al intentar compilar que tenemos una versión más reciente ya compilada. Con las prisas y las pruebas y arreglos sobre la marcha, compilamos sin querer en el año 2008 y claro, ahora en el año 2007, Java no nos permite compilar ya que una compilación posterior ya se encuentra en el sistema.

La solución aunque un poco drástica, se nos ocurrió en cuanto se nos paso la cara de tontos, ya que realizamos un backup y borramos todas las clases compiladas para volver a generarlas.

Es un poco curioso que Java no nos permita compilar, o mejor dicho, recompilar una clase que ya se compilo en el futuro. Si alguien os dice que sois vosotros mismos que viene del futuro para daros una versión superior de alguna clase vuestra, no se la toméis, porque no os dejara compilarla.