Oracle compra Sun (y MySQL)

El índice Nasdaq ha temblado, digo se ha tambaleado, hoy más que nunca, y no precisamente por culpa de la crisis. Gracias a un tweet de Kirai, al mediodía me enteraba de la rápida y sigilosa maniobra empresarial consumada con "alevosía y nocturnidad" hoy mismo por el gigante Oracle. En lo que se ha convertido probablemente en la noticia tecnológica del día y del mes, Oracle ha anunciado públicamente (puede que la web esté caída) haber llegado a un acuerdo para la compra de Sun Microsystems por un valor aproximado de 7400 milloncejos de dólares, vamos, calderilla para tipos como yo ;-).

Si bien ya se habían hecho públicos ciertos movimientos y reuniones entre sheriffs de IBM y Sun durante las últimas semanas, este repentino anuncio de adquisición por parte de Oracle creo que ha pillado totalmente desprevenid@ a mucha más gente de la que podíamos llegar a imaginar.

La duda que asola Internet a esta hora reside en las implicaciones que tendrá esta vertiginosa pero inteligente maniobra en dos de los "productos estrella" de Sun, hablo, como no, de Java y de MySQL. Personalmente no espero demasiados cambios ni licencias más restrictivas en la tecnología Java que Sun "liberó" hace algún tiempo, el enfado de la community podría ser de los que hacen época e historia.

Respecto a MySQL, cuya adquisición por parte de Sun anuncié en este blog hace poco más de un año, por el momento todo el mundo dice que MySQL va incluída en el intercambio de cromos. Creo que ésta es sin duda la parte más inteligente de la operación realizada por Oracle, donde se me empiezan a ocurrir múltiples combinaciones y jugadas.

A día de hoy puede que MySQL no sea competencia directa de Oracle, pero doy por descontado que una de las grandes razones para que Oracle haya comprado Sun es precisamente MySQL y su excelente rendimiento y progresión en los últimos años. Si bien todo el mundo está hablando del jugoso pastel llamado "Java" del que Oracle acaba de apoderarse, yo me arriesgo y apuesto por MySQL como principal activo de la compra, tecnología en la que a buen seguro Oracle ha visto cosas que le pueden interesar sobremanera de cara al futuro.

¿Y ahora qué? ¿Tendremos un mix denominado MyOracle o apostarán por Oracle como sistema de base de datos comercial y seguirán ofreciendo MySQL como base de datos opensource? Sun tampoco lo hizo, con lo que no creo que Oracle se atreva ahora a quitar el rasgo opensource que ha caracterizado a MySQL desde sus inicios. Yo desde luego espero seguir viendo por mucho tiempo el adjetivo Community Edition al lado de la marca MySQL. Como siempre, lo veremos, o en su defecto, lo leeremos ;-). Señoras y señores, hagan sus apuestas...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Ja.NET SE: Java 5 JDK para .NET

IKVM, bridge entre Java y .NET del que ya hablé en su día, ya tiene rival. ¿Duro? Lo veremos, de momento sólo puedo decir que hoy me he topado con otro de estos famosos puentes que intentan de alguna manera enlazar las dos plataformas de desarrollo software más conocidas y utilizadas.

El proyecto en cuestión se denomina Ja.NET y deriva del proyecto Apache Harmony, proyecto que aboga desde hace tiempo por un Java SE totalmente opensource, en otra palabras, un Java SE no tan made in Sun Microsystems ;-). Los creadores de Ja.NET pretenden ofrecer una implementación opensource del entorno Java 5 SE JDK para .NET, incluyendo librerías, herramientas, y por supuesto, un entorno de ejecución basado en .NET, es decir, una especie de Java Virtual Machine "a lo .NET".

Aparentemente, este nuevo JDK, en vez de generar el famoso e interoperable Java Byte Code a ejecutar por las típicas JVMs, tiene toda la magia para poder compilar código Java a código CIL (antes conocido como MSIL), código que podría ser directamente invocado desde una aplicación C# por ejemplo. Parece que esta conversión utiliza Cecil, una potente librería de Mono para inspección y modificación de assemblies.

¿Qué os parece el remix? Yo mismo no soy muy partidario de estos bridges o pegamentos de segunda clase, sobre todo por el overhead que suponen en su mayoría. Ahora bien, hay casuísticas un tanto extrañas en las que estas utilidades pueden tener su hueco. Por ejemplo, cuando tenemos una lógica de negocio o ciertos algoritmos muy complejos implementados en Java desde hace un porrón de tiempo, puede pasar que al jefe de proyecto de turno, se le ocurra la brillante idea de desarrollar una aplicación .NET para darle a la aplicación una interfaz de usuario más atractiva para los usuarios. ¿A que suele pasar? Está claro que lo que vende es el mariconeo de pantalla ;-).

Pues bien, ahí es donde yo creo que pueden entrar este tipo de frameworks; sería cuestión de compilar el código Java con Ja.NET para generar código que pueda ser utilizado desde una aplicación desarrollada en C# ó VB.NET por ejemplo. La verdad es que el enfoque se me hace muy similar, por no decir igual, que el de IKVM.

A ver si saco algo de tiempo para hacer unas pequeñas pruebas comparativas entre IKVM y Ja.NET, y de paso monitorizo el avance de estos dos interesantes proyectos. Por el momento, IKVM Vs. Ja.NET, pronto en sus PCs de desarrollo ;-).

Vía: InfoQ

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

MaxPermSize reserva memoria permanente

El lunes os hablaba de un intercambio de mails curioso gracias a la inmediatez e importancia de Twitter, anécdota que venía precedida por la mediocre impresión que me causó la live demo de JBoss Portal. Esto no podía quedar así, por ello, para quitarme el mal sabor de boca tecla, tal y como le prometí al amigo Tomás, hoy he sacado un ratín para hacer mis primeros pinitos con JBoss Portal. Las de hoy no han sido pruebas exhaustivas, pero la impresión a decir verdad sigue siendo mala no muy buena. Ahora explico por qué...

El primer paso ha sido bajarme un bundle o paquete que ya contiene una instancia preconfigurada de JBoss Portal 2.7.0 GA "desplegada" (I mean deployed...) bajo un servidor de aplicaciones JBoss 4.2.3, otro producto cañerito del fructífero matrimonio JBoss-RedHat. Como ya he aprendido la lección, ahora soy de los que empiezan por leerse el típico quickstart o manual de referencia con las acciones básicas para saber por dónde agarrar el embolao. Por lo que dice en el documentillo, tan sencillo como descomprimir el archivo descargado, acceder a la carpeta "bin" y ejecutar el típico run.bat si estamos en Windows (es el caso) o run.sh si estamos enel lado oscuro ;-), es decir, lo de siempre. Ésta es una de las cosas buenas que tienen los proyectos opensource, más concretamente, los proyectos relacionados con Java: la forma de arrancar un servidor de aplicaciones, el proceso de deploy de las aplicaciones, e incluso la estructura de directorios y el nombre de los archivos, es muy parecido casi siempre, con lo que en poco tiempo te quedas con la idea general. Lo dicho, que la idea está asumidisima hace tiempo, en cambio...

Como se aprecia en la imagen, en el log del servidor de aplicaciones JBoss, la flecha roja indica que JBoss AS ha arrancado sin problemas. Normalmente, ver un mensaje de este tipo en la consola suele indicar que el servidor está listo para que le den cañita brava. Precisamente eso es lo que he hecho, ya que siguiendo el manual, he accedido directamente a la URL inicial de JBoss Portal, http://localhost:8080/portal, con toda la ilusión del mundo por ver mi tesoro, digo, mi portal, en acción. Para mi desesperación, tanto Firefox como Explorer no son capaces de mostrarme nada, con lo que vuelvo a la consola para comprobar que los errores de tipo OutOfMemory campan a sus anchas por JBoss AS. En serio, no acabo de entender eso de que te bajes una demo preconfigurada de Internet, sigas las instrucciones de pé a pá, la arranques como Dios manda, y no veas nada, sólo las típicas y feas excepciones lanzadas por Java; I can't believe my eyes...

Menos mal que el texto OutOfMemory lo dice todo, con lo que en seguida he ido a inspeccionar el contenido del fichero run.bat, que es donde se le indica a JBoss qué JDK utilizar, qué variables de entorno configurar, y lo más importante, con cuánta memoria arrancar y el  máximo a reservar. Claro, en seguida veo la línea que puede estar dando guerra:

Traduciendo esto a lenguaje pseudo-natural: JBoss AS inicia (-Xms) el heap o cantidad de memoria reservada para la Java Virtual Machine a 128 Mbytes de RAM, permitiendo que este tamaño de pila o heap crezca hasta un tamaño máximo (-Xmx) de 512 Mbytes. ¡Pues parece que el niño no tiene suficiente!

Siguiendo los sabios consejos del compi situado a mi izquierda, el primer intento es equiparar el mínimo de memoria necesaria con el máximo permitido, es decir, poner los dos parámetros a 512. Reinicio de JBoss AS...,¡qué va, tampoco carbura! Entra entonces en liza desde el lejano Oeste, un nuevo consejo que acepto de muy buen grado: mantener equiparados los parámetros inicial y máximo, y probar fortuna con el parámetro MaxPermSize, un parámetro que sin saber a ciencia cierta a qué hace referencia exactamente, sabemos que ha dado buen resultado en otras ocasiones digamos que problemáticas ;-). Por tanto, la línea relativa a asignación de memoria de JBoss AS del fichero run.bat queda de la siguiente manera:

set JAVA_OPTS=%JAVA_OPTS% -Xms512m -XX:MaxPermSize=256m -Xmx512m

Se arranca de nuevo correctamente JBoss AS, accedo a la URL inicial..., ¡y por fin veo la luz! 

Qué bonito, ¿eh? Por fin tengo JBoss Portal up and running para exprimirlo y evaluarlo hasta límites insospechados, en otras palabras, listo para hacerle mil y una putadas ;-). 

Le debo una a mi compi, y otra a MaxPermSize, que según lo que explican claramente en esta página, indica el tamaño máximo de la memoria non-heap (también conocida como PermGen), en definitiva, el tamaño máximo de "memoria permanente" asignada a la JVM. 

Esperad, que ahora que tengo a JBoss Portal vivito y coleando, llega la prueba de las pruebas, una pequeña maldad que sólo se le ocurre a usuarios cabrones y enrrevesados como yo: Paro JBoss AS, mato el  proceso java.exe que anda dando vueltas por ahí, vuelvo a editar el fichero run.bat para dejarlo tal y como venía "de fábrica"(set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m), arranco de nuevo JBoss AS con esta nueva configuración y..., ¿qué creeís que ha pasado? Lo que me temía, aunque no me explico por qué, JBoss Portal ahora funciona de perlas, cuando la primera puesta en marcha tras la descarga inicial ha sido un auténtico desastre.

¿Explicación? Lo único que se me ocurre es la NO volatilidad del parámetro MaxPermSize, es decir, visto lo visto, entiendo que MaxPermSize modifica la memoria permanente asignada a la JVM, y JVM guarda (en este caso) esta configuración entre distintas sesiones o arranques, dándole igual que el parámetro desaparezca del run.bat y que se termine el proceso java.exe por las bravas. En otras palabras, un parámetro muy a tener en cuenta a la hora de lidiar con problemas de memoria muy típicos de las aplicaciones Java.

¿Conclusión? Aparte de la lección del parámetro MaxPermSize, y aunque al amigo Tomás no le haga gracia, he de decir que JBoss Portal se está cubriendo de gloria conmigo; no es normal que te bajes una demo configurada y que eso no funcione ni a tiros. Es más, diría que JBoss Portal está a puntito de ingresar en la "lista negra de Lonifasiko", de la que, aviso para aplicaciones navegantes, es realmente difícil salir ;-).

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Eclipse diferencia plugins de dropins

Si hay una cosa que me fascina de los proyectos opensource es la gran capacidad que tienen para admitir "cambios en caliente" así como las facilidades que ofrecen para mejorar la experiencia del usuario gracias a los plugins y extensiones. Normalmente es tan sencillo como descomprimir un archivo bajo cierto directorio, como mucho tocar un fichero de configuración XML, y ¡voilá! Plugin funcionando perfectamente a las mil maravillas. Como digo, me encanta esa filosofía de intentar hacerlo todo más fácil y configurable para el usuario.

Este modo de funcionamiento, o mejor dicho, esta filosofía de desarollo, se personifica claramente en proyectos de la talla de Mozilla Firefox o Eclipse. Sin ir más lejos, en este último proyecto, ¿qué desarrollador no conoce la subcarpeta "plugins"?

Esta mítica y mística carpeta es el máximo exponente de lo que puede llegar a ser un auténtico repositorio de extensiones super útiles que nos permiten desarrollar todo tipo de aplicaciones software bajo este excelente IDE. Además de poder desarrollar en el sempiterno Java, estos addins nos permiten programar en C++, Python, crear aplicaciones para la plataforma J2ME, para la tan de moda Android, Pentaho BI, etc. Eclipse se ha convertido en los últimos años en el IDE opensource más versátil, plural y configurable en la historia del desarrollo del software. Que conste que yo soy de la "escuela Visual Studio", que dicho sea de paso, es una maravilla, pero he de admitir que Eclipse está muy pero que muy bien.

Total, que andaba yo la semana pasada con ganas de trastear con Google Web Toolkit, un web framework del que había oído hablar que permitía desarrollar de forma muy sencilla, en Java, aplicaciones AJAX visualmente muy ricas. Como neanderthal que soy y porque me gusta ver las tripas de todo, primero probé los ejemplos sencillos "por fuerza bruta", invocando el runtime de GWT a machete, por línea de comandos; sin embargo, como supondréis, en los tiempos que corren, lo lógico es desarrollar aplicaciones GWT de forma algo más visual, por ejemplo, con el plugin actualmente disponible para Eclipse, denominado Cypal Studio for GWT.

Haciendo de nuevo el cavernícola y sin leerme el correspondiente manual de instalación, me bajo el plugin del invento y lo descomprimo bajo el directorio "plugins" que tanto adoro. "¡Pues vaya mierda, esto no funciona!" pienso al arrancar Eclipse y ver que no hay rastro del Cypal Studio éste. Empiezo a leer la documentación (como debía haber hecho desde el principio...) y en seguida me me topo con el requirement de que se ha de utilizar la versión Eclipse IDE for JEE Developers y como versión base mínima, Eclipse 3.3, requisitos que no cumplo ni de lejos con mi ya anticuado y clásico Eclipse 3.2.2. Toca actualizarse por tanto a la versión 3.4 de la plataforma, conjunto de releases denominadas con el codename de Ganymede.

Más de lo mismo, queda confirmado que Lonifasiko es el único animal que tropieza más de dos veces con la misma piedra: instalo la versión de Eclipse requerida, copio los tres ficheros .jar que componen el plugin bajo "Eclipse\plugins\", arranco de nuevo el entorno con "eclipse -clean" y... nueva decepción, no tengo plantillas GWT ni posibilidad de configurar en "Preferences" el flamante kit de desarrollo web de Google. ¿Lo siguiente? Lo típico, repetir los pasos anteriormente realizados con más cautela y prestando más atención a lo que estamos haciendo: cerrar Eclipse por si las moscas, borrar los .jar, volver a bajarme el .zip, descomprimir bajo el directorio "plugins" por sexta vez, y otro arranque en limpio del IDE. ¡Qué va, no hay manera!

Resignado (y de muy mala leche), acudo de nuevo a las instrucciones, aguanto como un titán párrafo tras párrafo, hasta que hacia el final de la página leo una nota relativa a las versiones Ganymede de Eclipse; esto seguro que me interesa...¡vaya que sí me interesa! La primera línea lo dice bien clarito: a partir de las versiones Ganymede, es decir, 3.4 y superiores, la forma de instalar los plugins se ha cambiado. Leo por ahí que ahora, el directorio plugins sólo va a admitir plugins en los que confía, es decir, de fabricantes más o menos fiables, seguros, "coleguitas". Esto implica que "los otros plugins", los plugins no oficiales, irán obligatoriamente bajo la carpeta dropins, teniendo que crear a mano incluso su propia estructura de directorios.

¡Manos a la obra! Siguiendo las instrucciones, creo bajo "Eclipse\dropins" una carpeta denominada "Cypal", y dentro de ésta, otra carpeta denominada "plugins" (lo sé, ¡menudo lío!). donde planto los tres .jars que tanta guerra me están dando:

Vuelta a arrancar por enésima vez Eclipse "a ras" y ya tenemos, por fin, el plugin de Cypal Studio ready para perrear con el super entorno de Google Web Toolkit:

Así que ya sabéis, con versiones de Eclipse 3.4 o superiores (cualquier release de Ganymede o superior), si el plugin a utilizar es "no oficial", olvídate del directorio "plugins" de toda la vida y pásate a "dropins", que la cosa se ha puesto seria y Eclipse ya no se fía ;-).

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Interoperando con Ikvm

Interoperabilidad. Qué palabra tan bonita, y ¡que bien suena! Es una de las múltiples palabras que utilizan los comerciales informáticos (podríamos escribir una enciclopedia) a la hora de "vender proyectos". En el mundo de la programación casi siempre se relaciona interoperabilidad con una batalla campal entre Microsoft .NET y Java, las dos plataformas reinas del mundo de la programación informática. Se han escrito ríos (más bien océanos) de tinta con estudios comparativos entre estos dos poderosos frameworks, siempre intentando desestabilizar o buscar puntos débiles en uno u otro bando.

Este contencioso internacional de la programación tiene pinta de seguir abierto "per secula seculorum" (es como Irak, Palestina, Afganistán y estos países...), complicando enormemente la vida a los programadores, generando desconfianza en las empresas cliente, y emborronando el ya de por sí maltrecho mundo de la informática en general. Siempre se oye hablar de herramientas bridge o cross-platform que a cambio de un buen puñado de dólares prometen el oro y el moro en cuanto a interoperabilidad se refiere. Para el caso concreto de limar asperezas entre .NET y Java, acabo de descubrir el proyecto opensource Ikvm. Una vez más, me quito el sombrero ante proyectos desinteresados de este tipo que alumbran el oscuro mundo de la interoperabilidad. A grandes rasgos, el proyecto Ikvm:

• incluye una implementación .NET de una Java Virtual Machine
• permite utilizar librerías java desde aplicaciones .NET
• facilita el desarrollo de aplicaciones .NET en Java

Sobre todo me llamó la atención el segundo punto, el poder "jugar" con una librería de Java desde una aplicación .NET. Hay muchas librerías potentes de Java que no tienen su implementación en .NET; es en estos casos donde Ikvm puede echarnos una mano (¡y no al cuello!). Así que nada, me he bajado la conocida librería de data mining Weka, en formato .jar y aquí os detallo la experiencia religiosa que he tenido con Ikvm:

• Lo primero de todo es convertir con el comando ikvmc la librería weka.jar a weka.dll, libreria directamente accesible desde .NET:

En la siguiente imagen se puede apreciar que la nueva librería weka.dll ocupa casi el doble que la original weka.jar, pero bueno, estamos en versión beta, ¿verdad? ;-)

• El siguiente paso es abrir un proyecto con Visual Studio o MonoDevelop (si utilizamos MONO), y añadir una referencia a la recien creada weka.dll y otra a la librería propia de Ikvm denominada IKVM.OpenJDK.ClassLibrary.

• Una vez aquí, el límite lo pone vuestra imaginación. Toda la funcionalidad de una compleja librería Java fácilmente accesible desde el entorno .NET. Como si queréis empezar a probar redes bayesianas de Weka...¡todo vuestro!
  

Os puedo asegurar que un colega del curro ha utilizado satisfactoriamente Weka desde una aplicación .NET. ¿Rendimiento? No he realizado ningún test, pero todo sabemos que esta clase de "puentes" siempre conllevan cierta penalización; no va a ser todo gratis ;-)

SaludoX.