que - ¿Por qué Sun no hace un compilador de código de bytes C#para Java?

lenguaje de programacion c# caracteristicas (18)

"Entonces, nos gustaría construir una versión Java de nuestro motor central, idealmente sin mantener una base de código fuente Java separada".

Básicamente, desea compilar su código C # sin modificar, y hacer que se ejecute en un entorno de solo Java.

IKVM no es lo que quieres. IKVM es tres cosas principales .

a. ikvm: implementación CLI de una máquina virtual Java (tenga en cuenta que esto utiliza ~~Classpath~~ (ahora OpenJDK) para la biblioteca de clases Java).

segundo. ikvmc - Compila bytecode de java en bytecode CLI.

do. ikvmstub - Genera clases de stubs java que llaman al código CLI.

Tenga en cuenta que todas estas herramientas dependen de CLI en tiempo de ejecución. Lo que quieres es exactamente lo opuesto a IKVM, que es, por supuesto, MVKI (el intermediario más venerable de Kompiler) :):

a. mvki - Implementación de Java de una máquina virtual CLI (presumiblemente esto usaría Mono o DotGNU para la biblioteca de clases).

segundo. mvkic: compila el bytecode de la CLI con el bytecode de Java.

do. mvkistub - Genera clases de stub CLI que llaman a Java

Tenga en cuenta que ninguno de estos requeriría una implementación existente de .NET Framework en tiempo de ejecución, por lo que deberían ser satisfactorios para sus clientes solo con Java.

Lamentablemente, hasta donde sé, MVKI no existe, por lo que es mejor hacer un puerto manual (que inevitablemente sería más limpio, aunque más trabajo).

Editar: Según la descripción de Mainsoft, parece ser similar a MVKI, aunque no estoy seguro de qué hacen para la biblioteca de clases, ya diferencia de IKVM no es FOSS.

Queremos ejecutar nuestro código C # en la JVM

Mi empresa tiene una gran base de código C #. Más de la mitad de este código es nuestro motor central para crear, leer, modificar, calcular y escribir libros de trabajo de Excel. Frecuentemente recibimos preguntas de clientes y clientes potenciales que nos preguntan si vamos a construir una versión de Java de nuestro motor; a muchos de ellos no les interesa en absoluto la interfaz de usuario. Incluso tenemos algunos clientes que se han tomado la molestia de utilizar nuestra biblioteca .NET desde sus aplicaciones Java.

Por lo tanto, nos gustaría construir una versión Java de nuestro motor central, idealmente sin mantener una base de código fuente Java separada.

Eric Sink describió este problema muy bien. Estoy en una posición similar, excepto por el hecho de que nuestra licencia de software incluye el despliegue libre de regalías, por lo que la elección de Eric de Mainsoft no es un comienzo para nosotros.

He estado buscando en Google los gustos de "c # a jvm" cada varios meses durante varios años sin alegría. Después de haber pasado ~ 7 años desarrollando software similar para Java, estoy seguro de que las API de .NET que utilizamos en nuestro motor central podrían encapsularse fácilmente y podríamos lograr todo lo que necesitamos utilizando las bibliotecas de Java. Entonces, si solo tuviéramos un compilador C # -> JVM, podríamos construir nuestro motor central para Java y ya no tendríamos que rechazar a los desarrolladores de Java que quisieran usarlo.

No estoy preguntando por las razones técnicas por las cuales Sun no hace un compilador de C #. Reconozco que Java no tiene propiedades o una longitud de 64 bits sin signo, etc. Por razones de razonamiento, suponga que todos estos problemas técnicos podrían resolverse extendiendo la JVM y / u otros medios.

Y no estoy pidiendo otro debate sobre por qué un idioma / pila podría ser mejor que el otro. La realidad en nuestro negocio es que hay muchos clientes potenciales que usan cada uno.

¿Por qué Sun debe hacer un compilador de C #? (IMO por supuesto)

Facilitar la ejecución del código C # en la plataforma Java significa más desarrolladores y más software para la plataforma. ¿Hay algo más importante para el éxito de una plataforma? Jonathan Schwartz es un tipo de software. Dejaré que otros más inteligentes que yo decidan si asumió o no un trabajo imposible como presidente y CEO de Sun, pero al haberme encontrado con Jonathan poco después de unirse a Sun, mi impresión es que él entiende el software y la necesidad de un gran base de desarrolladores.

Entonces, ¿por qué Sun no hace un compilador de C #?

Síndrome NIH ?
¿El fantasma de Scott McNealy ?
¿A muchos desarrolladores de Java no les gusta o desconfían de todo lo relacionado con Microsoft?
¿Acordaron no hacerlo como parte de tomar grandes cantidades de dinero ?
???

Debe haber una buena razón. No puedo por mi vida descubrir qué es ...

Joe Erickson escribió:
Facilitar la ejecución del código C # en la plataforma Java significa más desarrolladores y más software para la plataforma.

Esta es una declaración falsa. La ejecución del código C # en la JVM no crea programadores Java, sino que crea programadores C # que pueden ejecutar en una JVM. Solo amplía el alcance de C #, suponiendo que la JVM también traduce cualquier llamada específica de microsoft (es decir, win32) a algo que es neutral en la plataforma. Entonces, si Sun traduce IL a Java Bytecode, el único grupo al que ayuda es: Microsoft. Y, dada la historia de Sun con Microsoft durante las demandas originales C # -Java schism / Visual J ++ ...

Además, tiene que enfrentar la inviabilidad técnica, ya sea que quiera o no. Existen diferencias fundamentales en la forma en que se ejecutan los códigos de bytes que son cuestiones mucho más importantes que si existe o no un tipo de datos largos sin firmar.

Si debe tener C # en una plataforma que no sea de Microsoft, use Mono

¡ Puede ejecutar su código .NET y su código Java en el mismo intérprete! Consulte la JVM basada en IKVM .NET y la página wiki de Boo y Java para ver un ejemplo de caso de uso (utilizando el lenguaje Boo basado en .NET para escribir aplicaciones que usan bibliotecas Java).

¿Por qué Microsoft no hace un compilador de código de bytes C # a Java? ¿Por qué no lo haces? Hay especificaciones abiertas en cada lado ...

Exponga su API de .NET como servicios web ASMX y debería estar listo.

EDITAR: Para escenarios más pesados, valdría la pena buscar en Windows Communication Foundation (WCF). Esto tiene soporte integrado y configurable para seguridad, transmisión, diferentes escenarios de transporte (HTTP, TCP / IP, tuberías con nombre local). No está restringido a la codificación de mensajes SOAP, pero probablemente sea la forma más fácil de interoperar con Java.

No estoy muy seguro de su situación exacta, pero si está tratando con archivos de gran tamaño y el código .NET y el código Java se ejecutan localmente, puede guardar el archivo en el disco duro del usuario usando .NET y luego buscarlo desde tu aplicación Java.

Joe, te sugiero que investigue IKVM . Es posible que encuentres algo allí que te rasque la comezón

Que te diviertas.

Debe romper las excepciones marcadas.
Debe encontrar una forma de implementar delegados (que son como las interfaces de método único agregadas no antes del tiempo de carga).

Debe haber una buena razón. No puedo por mi vida descubrir qué es ...

Es fácil creer que las compañías son organizaciones sin fines de lucro que tienen sus intereses en el corazón. Es fácil olvidar que el único propósito de una empresa cotizada es ganar dinero para los titulares de acciones. Esta es una obligación legal y los directores / ejecutivos han sido despedidos / demandados si los accionistas no creen que no lo hayan hecho.

Sun libera Java porque ayuda a vender su hardware, que es la forma en que gana dinero con Java. IBM libera Java porque les ayuda a ganar más dinero con su consultoría.

Si Sun gastara dinero en un convertidor C #, ¿cómo recuperaría ese dinero y obtendría ganancias? Imagine que tiene que convencer a los accionistas de Sun. Si puedes, Sun hará un convertidor de C #.

Sencillo. Porque Sun prefiere no ser demandado por Microsoft. Y aunque nosotros, como programadores, tal vez no veamos una razón viable para un juicio, tenga en cuenta que Microsoft es una compañía bastante más grande que Sun y que tiene el poder de controlarlos.

Sin embargo, afortunadamente, Sun se encuentra en la posición de ser bastante más abierto que Microsoft. Si tal demanda existe, ya sea de código abierto o un tercero podría hacer que este compilador para Java y Sun no tenga que tomar el calor.

Si estuviese haciendo algo así como el soporte de lenguaje cruzado multiplataforma, crearía una ''API común'' ya que los lenguajes son similares en sintaxis, podría hacer que un traductor sea lo suficientemente fácil. Luego, en lugar de llamar a las API java o .net directamente desde el núcleo, llamarías a tu ''API común'' que implementaría las API java y .net que necesitarías. De esta forma, puedes crear un recinto de pruebas de idiomas cruzados si quieres. Dado que las diferencias principales en java y c # son definiciones de objeto, las obtendría reflejando los dlls de C # y luego reconstruir las construcciones, entonces sería fácil tener un intérprete que ejecutar e implementar los cuerpos de función y convertir propiedades en getters setters ya sabiendo la estructura de los archivos. Esto, por supuesto, está asumiendo .NET 2.0, algunas de las características en 3.0 y 3.5 se vuelven muy difíciles de ''interpretar''

Sería complejo, pero probablemente no tan complejo como reconstruir un núcleo en Java a mano, y tener que tener 2 equipos trabajando en ellos por separado. Si esta idea genera algo de inspiración, podría crear una. Realmente preferiría ver una instalación mono estable más simple para mac.

Básicamente, creo que un intérprete de nivel de código basado en un conjunto de clases de API comunes es algo muy posible de escribir con un equipo en una semana o dos.

http://jsc.sourceforge.net/ es un compilador cross # que puede convertir código .NET a Java (entre otras cosas).

Supongo que la mejor pregunta es por qué no escribes un compilador de código de bytes C # si quieres que exista uno. Esperar que los jefes supremos corporativos hagan algo es una mala idea.

Una sugerencia para crear una implementación de este tipo: tome el extremo frontal C # de Mono o .GNU. No te molestes en escribir el tuyo.

JACIL es un proyecto aparentemente muerto que intenta hacer el reverso de IKVM. Quizás algunas personas motivadas podrían usarlo como punto de partida para un compilador .Net a JVM viable.

Me pregunto si el proyecto Mono podría haber hecho menos trabajo por sí mismos al apuntar a la JVM en lugar de desarrollar y mantener su propia máquina virtual desde cero. El esfuerzo de desarrollo podría haberse centrado en un compilador cruzado de C # y en portar las implementaciones de sala limpia de las bibliotecas .NET a la JVM. Algo así como una versión de código abierto de lo que Mainsoft ha hecho. A continuación, puede habilitar las llamadas entre idiomas entre Java y el código C # en la misma JVM, y desplegar aplicaciones Applets y Java Web Start escritas en C #.

Hice un comentario que realmente debería haber sido una respuesta:

Simplemente no es técnicamente posible en este punto implementar la especificación C # en la JVM. C # admite punteros, tipos sin signo, tipos de valores definidos por el usuario, verdaderos genéricos, paso por referencia y muchas otras cosas. Para un lenguaje JVM muy similar a C #, revisa Stab .

Mainsoft lo falsifica. Estoy seguro de que requiere un gran esfuerzo de su parte.

Creo que encontrará que la herramienta Mainsoft, Enterprise Edition le permite ejecutar la mayoría / quizás todo su código .NET bajo Java JVM ... Parece enfocarse más en ASP.NET pero permitirá C #. Ha estado disponible por algún tiempo, ¡lástima que no lo publiquen mejor!

Advertencia blurb sigue ....

Mainsoft® es un software de interoperabilidad Java-.NET que permite a las organizaciones de TI moverse a plataformas habilitadas para Java, como Linux, al tiempo que conserva las inversiones existentes en el código y las habilidades de .NET. El software se integra perfectamente en el entorno de desarrollo Visual Studio®, permitiendo a los desarrolladores de C # y Visual Basic desarrollar y mantener rápidamente aplicaciones web y servidores que se ejecutan en plataformas Windows, Java EE o ambas, reduciendo así los costos de mantenimiento y desarrollo de aplicaciones, tiempo para producción y costo total de propiedad.

En primer lugar, Sun no tiene ningún incentivo para implementar un compilador de C # en la JVM porque tienen algo muy similar llamado lenguaje de programación Java.

Tampoco es tan simple como simplemente implementar un compilador, ya que las bibliotecas de clase estándar de Java no son las mismas que las bibliotecas de clase base de .net. Tendría que cambiar todas las llamadas de la API .NET a las llamadas a la API de Java.

Micrsoft tenía un producto llamado J # que debía ser para la conversión de Java a .NET, pero al final nadie lo usó ya que la API estaba limitada a la API pre Java 2, por lo que era prácticamente inútil. Sería lo mismo si Sun implementara partes del .NET BCL, ya que solo las porciones principales de este están estandarizadas y libres de regalías. Las partes como ASP.NET y WPF, WCF, etc. no forman parte de los estándares de ECMA, por lo que Sun necesitaría permiso de Microsoft para implementar esas API.

Si hay suficientes clientes que desean una versión java que tenga sentido desde el punto de vista comercial para portar su aplicación a Java, hágalo, simplemente nunca recibirá ayuda de Sun a través de un compilador C # a JVM.

Sé que esto podría no ser lo que estás buscando, pero aquí hay algunas alternativas posibles que (si no fuera por ti) podrían ser útiles para otros.

C: Puede transferir tanto como sea posible a C. Ahora puede crear un contenedor en C # y Java (y cualquier otro idioma que pueda comunicarse con C) que lo haga sentir como nativo de su idioma mientras programa. El problema ahora es que usted (o ellos, dependiendo de su licencia) tiene que construir la parte C para cada plataforma.
Fantom * : un lenguaje de programación que según su página de inicio es:
- Portátil: escriba el código portátil en Java VM, .NET CLR y JavaScript en el navegador.
- Familiar: los programadores de Syntax Java y C # se sentirán como en casa con la sintaxis evolutiva de Fantom.
- Orientado a objetos: todas las subclases de Obj. Tipos de valores cuando necesita el rendimiento.
- Funcional: las funciones y los cierres se hornean.
- Estático y de tipo dinámico: no te gustan los extremos: toma la mitad del camino.
Haxe *: (hexadecimal pronunciado) es un lenguaje multiplataforma que se compila en otros idiomas. Pronto C # y Java serán compatibles. Actualmente es compatible con:
- Javascript: Puede compilar un programa Haxe en un solo archivo .js. Puede acceder a las API DOM del navegador tipeado con soporte de autocompletado, y todas las dependencias se resolverán en el momento de la compilación.
- Flash: puedes compilar un programa Haxe en un archivo .swf. Haxe es compatible con los reproductores Flash de 6 a 10, ya sea con la "antigua" API Flash 8 o con la última API AS3 / Flash9 +. Haxe ofrece muy buenas características de rendimiento y lenguaje para desarrollar contenido Flash.
- NekoVM: Puedes compilar un programa Haxe para el bytecode de NekoVM. Esto se puede usar para la programación del lado del servidor, como páginas web dinámicas (usando mod_neko para Apache) y también para aplicaciones de línea de comandos o de escritorio, ya que NekoVM se puede incrustar y extender con alguna otra DLL.
- PHP: Puedes compilar un programa Haxe para archivos .php. Esto le permitirá utilizar un lenguaje estrictamente tipado de alto nivel, como haXe, mientras mantiene compatibilidad total con su plataforma de servidor y bibliotecas existentes.
- C ++: Ahora puede generar código C ++ desde su código fuente de Haxe, con los Makefiles necesarios. Esto es muy útil para crear aplicaciones nativas, por ejemplo en el desarrollo de iPhone.
Haxe Comunidad. (2011, 11 de marzo). Haxe Introducción. Obtenido el 29 de enero de 2011, en http://old.haxe.org/doc/intro
Puede obtener más información sobre por qué Haxe es útil aquí .

* Nunca he usado este lenguaje y no sé qué tan bien funcionaría.