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.
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.
2 comentarios:
¡Buenas!
Aunque a mí tampoco me gustan demasiado esos refritos, la verdad, lo cierto es que pueden tener su interés en situaciones similares a la que planteas. ¿Para qué rehacer todo el código Java a .NET para darle una interfaz gráfica al usuario? ¿O si el rendimiento no es una prioridad (vamos sobrados de máquina o el algoritmo es tan costoso de traducir que no llegaría a merecer la pena (económicamente hablando, claro)) traducirlo? En esas situaciones pienso que sí puede ser interesante contar con estos puentes entre plataformas, aunque no sean, a mi parecer, la mejor solución en ningún caso. Pero hay ocasiones en las que el tiempo apremia, y no nos queda más remedio que "tirar de lo que hay". Con IKVM ya tuve que hacer algo similar en una ocasión, y a Ja.Net habrá que echarle un vistazo.
¡Salud!
La verdad es que IKVM parece que tiene más background y lo conoce y utiliza más gente, sobre todo, en ocasiones en las que no merece la pena migrar funcionalidad "requeteprobada" de Java a .NET. No sé si tiene mucho sentido otra alternativa como Ja.NET, recién salida, aunque si la han sacado, seguro que es porque este nuevo bridge aporta algo diferente. Me comprometo a escribir algún día un post comparando estos dos puentes.
SaludoX.
Publicar un comentario