Temas etiquetados como: ‘Java’

Por qué usar StringBuilder en lugar de concatenar Strings

2 marzo, 2011

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.

Publicada la version 0.1.1 de puntoengine

26 septiembre, 2010

Ayer publiqué la versión 0.1.1 de puntoengine. Puntoengine o Punto Engine PHP acortado PEP, es un framework en fase alfa para PHP del tipo MVC o Modelo Vista Controlador. Este framework basa su funcionalidad en una mezcla de diferentes frameworks web como son ASP.Net, Java Servlets y PHP en un antiguo framework propio llamado RLM Engine. Actualmente, pese a estar en una fase de desarrollo muy verde, pero ya es completamente operativo y se pueden construir webs con un sistema de Servlets como se haría una web en Java. La versión 0.1.1 en su revisión 7 de puntoengine se trata de la versión ya publicada 0.1.1 de puntoengine pero con la documentación completa del código, lo que facilita a quien quiera ver y estudiar el código y su funcionamiento, que sea mas fácil de seguir. Para la versión 0.2 de puntoengine se espera la creación de un administrador, actualmente en fase de desarrollo para poder gestionar entre otras cosas los Servlets instalados y la preparación para futuros plugins como puede ser el sistema de CMS.

Este es un proyecto a largo plazo y muy ambicioso que espero llegue lejos y pueda utilizarlo para construir diversas webs que tengo en mente. Según un calculo realizado siguiendo el sistema COCOMO, actualmente el proyecto con casi 1500 lineas de código, tendría un coste privado de unos 6.000€. Para el que quiera echar un vistazo e incluso colaborar con el desarrollo, documentación o aportando incidencias, puede hacerlo en la web del proyecto puntoengine.

No se puede viajar al pasado con Java

11 septiembre, 2007

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.