Barrapunto

Hace poco, en otra barrahistoria sobre .NET, publique un comentario en el que opinaba que si el gcc pudiera generar codigo jvm, esto permitiria que todos los lenguajes compilables con gcc fueran multiplataforma y pudieran comunicarse a traves de las librerias de java. Tendrian tambien la capacidad de migracion y serializacion que estas ofrecen y soporte nativo CORBA y RMI. Con un poco de trabajo supongo que hasta el recolector de basura de java seria usable a traves de diversos lenguajes, sin perder la capacidad de manejar la memoria dinamica manualmente cuando a uno le apetezca. Todo esto se parece mucho a .NET pero no es un clon creado para competir, sino una extension natural de lo que ya tenemos. Ademas, muchas aplicaciones que ya existen serian directamente portables.

Hace poco hice una busqueda en el google y encontre esto:

http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html

Un pavo ya lo ha hecho (el port a jvm), y ha discutido con Stallman el tema. A RMS no le gusta, transcribo:

> If it is possible to compile languages such as
> C into Java byte codes, I see a great danger. > The danger is that people will use Java byte
> codes to hook GCC up to proprietary back ends > and proprietary front ends. They could also
> generate Java byte codes, run a proprietary
> optimizer, and feed the result back into GCC. > In effect, the support for Java byte codes
> would undermine the goals of the GPL.

No tengo mucho tiempo para traducir ahora, pero viene a decir que el port hace peligrar los motivos de la GPL, por eso seguramente no esta incluido ni previsto en el gcc. No lo acabo de ver, alguien puede desmenuzar mas el tema?. Mereceria la pena un fork viendo las ventajas de un port a la jvm?

Es bastante problematico hacer un compilador de C a jmv bytecodes. Por lo visto las instruciones de la jmv estan pensadas para que cietas operaciones tipicas con pilas y punteros no sean posibles. Digamos que se quieren evitar los "punteros locos" ya desde la propia jvm.

De todas formas, si que conozco compliadores de otros lenguajes (prolog?, eiffel?) que tienen como un destino posible instrucciones jmv.

Pero que se compile C a jmv no significa que se disponga de todas las ventajas de Java ni que pueda acceder a las funciones de la libreria de Java. Son cosas muy distintas.

En cuanto a la opinion de RMS, no me ha quedado clara para nada. Por mas que leo y releo no se que quiere decir.

Si se diseña bien el interfaz, y dependiendo del tipo de lenguaje, es posible reutilizar mucho código de las librerías Java y tal...

En otro artículo ( no tengo el enlace a mano ) que puse en BP conté la historia del colega mio que hizo un traductor de Object Pascal a bytecode, que podía utilizar todas las clases Java, llegando a hacer applets en Pascal..

En principio, si te dispones a hacer un traductor de C++ a bytecode, sabes que tendrás que atenerte a las consecuencias... sobre todo a las restricciones impuestas por la filosofía del entorno Java. ¿Posible? Yo creo que si. Pero no va a ser un C++ corriente... será una especie de hermano bastardo adaptado a las circunstancias... con sus ventajas y sus inconvenientes...

>Desde luego es distinto, eso es tarea del enlazador

Bueno, ahi ya vamos mal, en Java no hay enlazador, hay cargador de clases.

Desde luego una interaccion C++-libreria Java no tiene que ser imposible, pero seguramente solo sea facil en casos triviales. Por ejemplo, un objeto C++ no deriva de Object, no tiene el mismo tipo de RTTI que Java, no existe el concepto de interfaz. La libreria java suele esperar objetos "tipo java" como parametro, no tipos elementales.

Por supuesto todo esto se puede implementar o apañar de alguna forma en C++, pero me temo que al final tendriamos un C++ sospechosamente parecido a Java, no portable.

En cuanto el articulo que citas, no aporta muchas novedades. Java se diseño con la seguridad y estabilidad en mente (otra cosa es que lueo falle), y una de las posibilidades es que aunque Java (lenguaje) no permita hacer "cosas feas", un programa escrito en otro lenguaje sobre JVM si podria hacerla. Por ello se evitaron a proposito ciertas instrucciones tipicas de codigo maquina.

Esto no obliga a usar Java (lenguaje) sobre Java (plataforma). Seguramente la mayor parte de lenguajes de alto nivel pueda sobrevivir sin estas instrucciones. Pero C y C++ emplea manipulaciones directas en memoria que hora estan prohibidas.

Por ello me temo que Sun ve el no soporte a C (y similares) como una "feature" (caracteristica positiva) y no un bug. La comunicacion con C y compañia se hara con CORBA y mecanismos similares, si no me equivoco.

Es logico, por otra parte,que microsoft tenga soporte a C++ en NET, ya que la mayor parte de los programas de M$ estan hechos en C++. Lo contrario seria un suicidio.

Por cierto, el hombre este del articulo no distingue entre freeware y free source.

La idea de poder utilizar RMI, el recolector de basura y demás desde programas en C/C++ es atractiva (para CORBA me quedo con los ORBs nativos, el de Sun no es ninguna maravilla). Sin embargo creo que el camino más útil es el emprendido por gcj, que forma parte de gcc 3.0.

La idea es la contraria, compila java y bytecodes a código nativo. Implementa el recolector de basura y buena parte de la librería estándar de Java. Lamentablemente RMI es una de las partes que aún no está portada.

Con gcj puedes mezclar código de Java con C++, internamente las clases de Java se implementan como las de C++ y está documentado como hacer llamadas de uno a otro, pasarse datos y manejar temas como las excepciones.

La máquina virtual supone una sobrecarga potente, la única ventaja que la veo insustituible sobre el código compilado son los administradores de seguridad para implementar una sandbox.

Las objeciones de Stallman me parecen muy razonables. Las implementaciones libres de máquinas virtuales y sobre todo de la biblioteca de clases van muy por detrás de la de Sun. Estaríamos desarrollando no para GNU/Linux, sino para una plataforma propietaria de Sun que funciona sobre varias plataformas, entre ellas GNU/Linux.

Además si escribo código para que se ejecute en una máquina virtual con la biblioteca de clases de Java, no veo útil utilizar como lenguaje C en lugar de Java, si no voy a obtener sus ventajas de rendimiento: es más natural usar Java. Con gcj en cambio programas en Java la parte que use la biblioteca de clases de Java y en C la que utilice bibliotecas de C.

Por lo que he visto, C# es tecnologicamente el antiguo J++, se parece muchisimo a Java, mas que a C++.

La idea de poder utilizar RMI, el recolector de basura y demás desde programas en C/C++ es atractiva (para CORBA me quedo con los ORBs nativos, el de Sun no es ninguna maravilla).

La de Sun es una implementacion minima,pero hay buenos ORB libres para C++ y Java. Tambien hay recolectores de basura para C++, y la STL es una buena coleccion de objetos.

Lo unico que no tiene C++ es una biblioteca grafica standard, tipo Swing.

En cuanto a gcj, no es el unico compilador de java a codigo nativo. Existen varios compiladores comerciales con la misma idea. Eso si, todos fallan a la hora de hacer aplicaciones graficas, estan orientados a servidores y sistemas empotrados.

En realidad, hacer gcj es sencillo, ya que java se parece bastante al Objetive C, que es soportado desde hace tiempo por gcc.

Lo que es una labor de chinos es clonar la libreria standard de Java soft libre, entre otras cosas por que Sun esta sacando nuevas API y extensiones constantemente.

Las objeciones de Stallman me parecen muy razonables. Las implementaciones libres de máquinas virtuales y sobre todo de la biblioteca de clases van muy por detrás de la de Sun. Estaríamos desarrollando no para GNU/Linux, sino para una plataforma propietaria de Sun que funciona sobre varias plataformas, entre ellas GNU/Linux.

Por la misma regla de tres, estariamos desarrollando para la plataforma Intel, o la plataforma Sun Sparc, o en la plataforma PA Risc, ninguna de las cuales es libre ni por asomo.

Me hacen gracia ciertas cosas. Se "puede" desarrollar un program GPL para Windows en Visual Basic, propietario por entero, pero no en Java, ya que de momento falta alguna libreria. Curioso, curioso...

si que conozco compliadores de otros lenguajes (prolog?, eiffel?) que tienen como un destino posible instrucciones jmv.

La última vez que hablamos de .NET ya enlacé a una página con 130 lenguajes que compilaban más o menos para la JVM.

Lo que he vist hoy es que en 1997 hubo un proyecto para compilar Eiffel en la JVM hecho por gente del Microsoft Research Institute de una universidad australiana.

Tambien hay recolectores de basura para C++,

De estos, sé que existen pero no sé de ningún programa conocido que los use. ¿Algún ejemplo? ¿No se usa porque no viene de fábrica o hay otras razones?

Ximian hace el mono respecto a .NET
Aunque la mona se vista de seda,...

Más que C#, está describiendo Managed Extensions to C++: C++ con recogida de basura, atributos, compilado a IL y con acceso a las clases .NET.

A mi me parece una idea excelente, y técnicamente posible -el Bytecode es código máquina de un procesador basado en pila, que no es tan dificil de emular-.

Otro problema es que al Ajatolah no le guste el projecto, y solo los proyectos más fuertes -como KDE o el fork del gcc- consiguen sobrevivir a la ira del Ajatolah.

Hay soluciones (aunque no open source) para migrar servidores Exchange en forma transparante. En la empresa han puesto una solucion de bynari (www.bynari.net) que funciona perfectamente. Hay que pagar licencias pero por lo que tengo entendido es muy barato.

> no existe el concepto de interfaz

Bueno... Esto es discutible. Una de las "features" que destacan los defensores de Java con respecto a la herencia del lenguaje es que lo han simplificado (respecto a, por ejemplo, C++), en que no hay herencia múltiple.

Sin embargo, la funcionalidad de una interfaz es sospechosamente la misma que aporta una clase abstracta (con métodos virtuales puros), de manera que se puede reproducir un modelo de jerarquía tipo Java (se hereda de una clase normal, y 0 o más interfaces), en C++ sin gran problema.

A ver si cogéis el chiste:

¿Algo más útil? Java es lo mejor para programar que tenemos hoy en día. Con diferencia.

Java es lo peor para programar que tenemos hoy en día. Con diferencia.

Hacer eso disponible sería lo mejor que Ximian, Red Hat, IBM o cualquiera podría hacer por Linux.

Hacer eso disponible sería lo peor que Ximian, Red Hat, IBM o cualquiera podría hacer por Linux.

>Por la misma regla de tres, estariamos desarrollando para la plataforma Intel, o la plataforma Sun Sparc, o en la plataforma PA Risc, ninguna de las cuales es libre ni por asomo.

Hombre, no es lo mismo, en un caso hablamos de software y en el otro de hardware. El problema con la JVM es que es en sí misma una plataforma y que controla un sólo fabricante, con todos los riesgos que conlleva. Ahora Sun da muy buen soporte a GNU/Linux (aunque sólo para plataformas Intel), de hecho creo (aunque no estoy seguro) que uno de los últimos SDK salió antes para Linux que para Solaris/Sparc, pero no siempre ha sido así de guay ni tiene por qué serlo en el futuro. Puede que Sun un día vuelva a ser la empresa que se negó a dejar publicar una foto de unas Sparc en la Linux Journal porque "Linux es un rival de Solaris".

>Me hacen gracia ciertas cosas. Se "puede" desarrollar un program GPL para Windows en Visual Basic, propietario por entero, pero no en Java, ya que de momento falta alguna libreria. Curioso, curioso...

Yo no he dicho nada de eso y que yo sepa tampoco Stallman ni nadie de la Free Software Foundation. De hecho en www.gnu.org hay una sección de Java y en lo que se refiere a mí he escrito varios programas en Java bajo licencia GPL. Eso no impide que muchos pensemos que el que Java no sea libre es un problema. Y que mientras está bien que GNU/Linux tenga un muy buen soporte para Java, pues tiene muchos usos interesantes y un papel importante en las empresas, no es buena idea orientar el futuro de los desarrollos libres hacia la JVM. Aparte que Java tampoco es la solución para todo: sería estúpido implementar todos los programas de un escritorio sobre Java o código de bytes.

> If it is possible to compile languages such as > C into Java byte codes, I see a great danger. > The danger is that people will use Java byte > codes to hook GCC up to proprietary back ends > and proprietary front ends. They could also > generate Java byte codes, run a proprietary > optimizer, and feed the result back into GCC. > In effect, the support for Java byte codes > would undermine the goals of the GPL.

No veo mucho sentido en eso que dice Stallman. Creo que puede hacerse ya sin necesidad de usar jvm. El gcc tienen una representación interna en un lenguaje de transferencia de registro (RTL). Nada impide usar un volcado de ese RTL contra un programa que llame desde el gcc y que sea propietario (es un ejecutable distinto). Haces modificaciones al gcc para que en el punto que te interese llames a ese optimizador propietario sobre el RTL y asunto concluido. Las modificaciones GPL y lo otro es "programa aparte".

Además que una cosa no esté incluida en el gcc no significa que no se pueda hacer, porque cualquiera puede iniciar su propia rama con estas cosas.

Pero si realmente lo de portar a jvm es una ventaja tecnológica, creo que se puede hacer, ya te digo, la excusa de la GPL no me parece muy válidad: se puede hacer ya de por sí, sin necesidad de ella