Implementación de C # para la JVM


91

¿Alguien está intentando implementar C # para la JVM? Como desarrollador de Java, he estado mirando C # con envidia, pero no estoy dispuesto a renunciar a la portabilidad y madurez de la JVM, sin mencionar la diversa gama de herramientas para ella.

Sé que hay algunas diferencias importantes entre JVM y CLR, pero ¿hay algo que sea sorprendente?


3
También he escrito muchas, muchas aplicaciones totalmente multiplataforma en Java; es algo cotidiano para mí y mi equipo. Por lo general, ejecutamos el plan de prueba en cada plataforma que "calificamos" oficialmente, pero creo que han pasado años desde que un error de prueba se atribuyó a una diferencia de plataforma.
Jared

1
Nuestro producto principal se ejecuta en Windows, OS X y Linux sin cambios. Realmente no es difícil de hacer.
Thorbjørn Ravn Andersen

1
Hago mi Java en Windows, otro tipo hace su parte en OSX, CI procesa todas las pruebas en Linux y hemos implementado el software en una amplia variedad de servidores Windows y Linux e incluso Solaris. Así que supongo que podría decir que he escrito verdaderamente, completamente, programas Java multiplataforma durante un tiempo.
Esko

1
JavaVM implementado en .NET; Implementación .NET de Java LIBS; interoperabilidad de ambos mundos -> IKVM.NET ( ikvm.net )
gsscoder

1
Me parece que si puede convertir .NET a JavaScript (JSIL hace esto, por ejemplo), debería poder convertirlo a Java ...
BrainSlugs83

Respuestas:


93

Existen diferencias muy significativas entre CLR y JVM.

Algunos ejemplos:

  • Java no tiene tipos de valores definidos por el usuario
  • Los genéricos de Java son completamente diferentes a los genéricos de .NET
  • Muchos aspectos de C # dependen de elementos del marco: delegados, etc. También necesitaría portar la biblioteca, incluso para los aspectos del lenguaje .
  • Java no admite cosas como propiedades y eventos a nivel de JVM. Podrías fingir algo de esto, pero no sería lo mismo.
  • No creo que Java tenga ningún equivalente a los parámetros de paso por referencia, incluso a nivel de JVM
  • Es muy posible que las sutilezas relacionadas con los diferentes modelos de memoria muerdan, aunque no estoy seguro de cuánto hay en la especificación de C #.
  • El código inseguro en general probablemente no sea posible en Java
  • La interoperabilidad con código nativo es muy diferente entre JNI y P / Invoke. Probablemente esto no sea un gran problema para ti.
  • Tendría que simular la sobrecarga del operador y las conversiones definidas por el usuario

Probablemente podría portar una gran cantidad de C #, pero se quedaría con una experiencia bastante insatisfactoria, en mi opinión.

Yendo por el otro lado, ¿conoce IKVM ? Le permite ejecutar código Java en .NET.


7
Java tiene finalizadores y la finalización de .NET tampoco es determinista. Puede haber algunas diferencias sutiles entre los dos, pero no puedo pensar en ninguna. Sin embargo, sospecho que las pruebas de accesibilidad de Java son más fuertes que las de .NET: no hay finalización mientras otro hilo todavía está ejecutando un método de instancia
Jon Skeet

3
Creo que podría asignar tipos de valor a tipos de referencia. ¡Solo haz que cada tarea haga una copia superficial!
Daniel Earwicker

3
@Earwicker: ... y cambiar la asignación de matrices, y varios otros lugares donde la semántica marca la diferencia? Sospecho que sería muy difícil hacerlo funcionar, si es posible, y el resultado no sería algo que quisieras usar.
Jon Skeet

4
Creo que los genéricos también podrían resolverse. Tendría que generar una clase java con campos adicionales para contener los objetos Class para los parámetros de tipo, por lo que agregaría algo de sobrecarga, pero luego los nuevos T () y typeof (T) estarían disponibles.
Daniel Earwicker

30
@Jon Skeet: Eso te da lo peor de ambos mundos: el lenguaje algo desactualizado de Java en la plataforma propietaria de Microsoft.
Bart van Heukelom

43

Visite http://code.google.com/p/stab-language

El siguiente código es un código de idioma Stab para JVM

using java.lang;
using stab.query;
public class Test {
   public static void main(String[] args) {
   // Sorts the arguments starting with "-" by length and then using the default   
        // string comparison
        var query = from s in Query.asIterable(args)
                    where s.startsWith("-")
                    orderby s.length(), s
                    select s;
        foreach (var s in query) {
            System.out.println(s);
        }
    }
}

7
Stab ofrece gran parte de la carne del lenguaje C # en JVM, pero lo hace de una manera muy interoperable con Java. Por lo tanto, no es estrictamente compatible con el código fuente con el código C # escrito para .NET CLR, pero permite a un programador Java disfrutar de un lenguaje muy parecido a C # mientras obtiene el mismo código de bytes de calidad generado y tiene interoperabilidad sin impedancia con bibliotecas y marcos de Java. Es el enfoque correcto a seguir para obtener C # en la JVM.
RogerV

El buen lenguaje, en la buena plataforma ... Ojalá hubiera tropezado con esto hace años.
Cueva Jefferey

14

Transpiladores de códigos de bytes

Grasshopper puede tomar un código de bytes CLR y transpilarlo para JVM. Destinado principalmente a aplicaciones web, no proporciona, por ejemplo, implementación JVM de clases de Windows Forms. Sin embargo, parece algo anticuado. La web habla de ASP.NET 2.0, Visual Studio 2008, etc. Primero mencionado por @alex

XMLVM puede tomar el código de bytes CLR o JVM como entrada y producirlo como salida. Además, puede generar JavaScript u Objective-C. Aún no hay lanzamientos, solo Subversion. "Versión de desarrollo experimental que no se utilizará en un entorno de producción".

IKVM va en la otra dirección que OP quiere. Proporciona una implementación de JVM que se ejecuta en CLR, un transpilador de código de bytes de JVM a CLR y un generador de código auxiliar de método de biblioteca CLR para Java. http://www.ikvm.net/uses.html Mencionado por @Jon Skeet

RPC

¿Por qué no tener CLR y JVM en paralelo y hacer que la comunicación sea lo más fluida posible? Esto no es lo que quiere el OP, pero algunas otras respuestas ya están bastante fuera de tema de diferentes maneras, así que cubrámoslo.

RabbitMQ , tiene una opción gratuita, es un servidor RPC escrito en Erlang con bibliotecas API para C #, Java y más.

jnBridge , la licencia puede resultar demasiado cara para algunos posibles usuarios.

gRPC y las bibliotecas RPC modernas similares ofrecen un amplio soporte de idiomas, generación de código para bibliotecas cliente en estos idiomas, formato de cable independiente del idioma para datos, funciones avanzadas como cancelación de llamadas en cascada, etc.

Lenguajes de programación

Escribe una vez, corre por todas partes;)

Haxe , compila en C # / CLR, Java / JVM, Javascript, Flash, Python,… Proporciona mecanismos de interoperabilidad para cada uno de los lenguajes de destino. Puede considerarse como un sucesor de ActionScript3 hasta cierto punto. Parece algo bastante sólido, con al menos una empresa dependiendo de ello. Mucho más confiable que Stab, mencionado a continuación.

Stab trae algunas características de C # e interoperabilidad de Java. No es muy útil, obtienes algunas características de C #, pero con lo que interactúas es el código Java que no las usa. https://softwareengineering.stackexchange.com/a/132080/45826 El lenguaje es relativamente oscuro, posiblemente abandonado, con pocas promesas de mejorar. Primero mencionado aquí por @Vns.

Ráfaga de aire fresco para la plataforma JVM;)

Scala , Kotlin , y otros, son lenguajes bastante agradables que se ejecutan sobre JVM y ofrecen características que un programador de C # puede perder en Java. Especialmente Kotlin se siente como una alternativa razonable a C # en el mundo de JVM. Scala puede ser un lenguaje demasiado extenso para que un programador se sienta cómodo en poco tiempo.

Mononucleosis infecciosa

Sin duda, esa también es una opción. ¿Por qué transpilar a JVM si Mono puede ejecutarlo como está? Primero mencionado por @ferhrosa

NUEVA YORK - 12 de noviembre de 2014 - El miércoles, Microsoft Corp. reforzó su compromiso con las experiencias de desarrolladores multiplataforma mediante el código abierto de la pila .NET completa del lado del servidor y la expansión de .NET para que se ejecute en las plataformas Linux y Mac OS.

Según este comunicado de prensa del que proviene la cita, Visual Studio 2015 agregará Linux / Mono como plataforma compatible.

Este es un blog escrito por la gente del proyecto Mono sobre él, desde el otro lado: .NET Source Code Integration (noviembre de 2014).

.NET Core

Una versión multiplataforma de Windows / Linux de (parte de) .Net gobernada por Microsoft. 'nuff dijo https://github.com/dotnet/core .

Conclusión

Ahora sería necesario probar estas herramientas / marcos y ver cuánta fricción hay. El OP quiere escribir en C # para la JVM, que en realidad puede funcionar bastante bien con Grasshopper.

Hacer esto con el objetivo de mezclar las bibliotecas mundiales de C # y Java en una única base de código puede no funcionar tan bien.

Fuentes

http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop


¡Gran respuesta! Como desarrollador de C # que no está contento con tener que hacer la transición a Java (¡¿cómo se puede vivir sin propiedades?!), Y tiene dudas sobre Scala, esto realmente presenta bien las opciones.
Gilthans

9

Podría ser más sencillo escribir un convertidor de IL a bytecode. De esa manera, automáticamente obtendría soporte para cualquier lenguaje .NET en la JVM.

Sin embargo, esta es una idea tan obvia que si aún no se ha hecho, probablemente sea extremadamente difícil o difícil de hacer bien / útilmente.


6
Se encontraría con la mayoría de los problemas que enumeré (diferentes genéricos, etc.
Jon Skeet

8
Esto es exactamente lo que hace Grasshopper (vea la respuesta de @ alex arriba), de hecho es extremadamente difícil hacerlo bien (solía trabajar en Grasshopper).
Motti

7

Mira a Grasshopper . Es un SDK basado en Visual Studio y un conversor de .NET a Java patentado que le permite ejecutar aplicaciones web y de servidor .NET en Linux® y otras plataformas habilitadas para Java.


2
¿Tiene experiencia práctica con él? También tenga en cuenta que la licencia es draconiana para la versión gratuita.
Thorbjørn Ravn Andersen

13
Perdiste mi interés en el momento en que dijiste la palabra "patentado". Suspiro.
Stephen C

2
Solo algunas noticias: Grasshopper ahora es gratis , sin soporte ni garantía (como la mayoría de los productos de código abierto).
fernacolo

1
Mainsoft parece estar completamente muerto y los enlaces de Grasshopper ya no funcionan.
David dado el

1
Obvio, entonces, solo un wibble neto. Ambos enlaces funcionan ahora. Desafortunadamente, ahora no puedo recordar por qué lo quería ...
David dado el



0

Esta respuesta puede llegar tarde, pero esta es nueva. Es posible que desee consultar el lenguaje de programación Kotlin . Ofrece los azúcares sintácticos que tiene C # y también es el más cercano a la sintaxis de C #, además de cualquier lenguaje JVM que no sea Java. Es de JetBrains .


0

Puedo ver dos razones por las que esto no genera mucho entusiasmo.

Lo primero que hay que tener en cuenta es que, cuando se trata de las características reales del lenguaje, C # y Java están muy cerca. C # y Java no solo están cerca, sino que también se mueven en direcciones similares. Hay algunas características que la JVM no admite actualmente de forma inmediata, pero ese no es el problema real. Siempre puedes fingir lo que falta. Creo que la gente prefiere esperar a que Java obtenga más azúcar que crear un Almost-Java desde cero. Para cuando el puerto esté listo, es posible que Java haya decidido ponerse al día.

En segundo lugar, la razón por la que los desarrolladores prefieren C # no es tanto el lenguaje en sí, sino las herramientas que lo rodean, su relación bidireccional con C # y cómo Microsoft admite todo. Por ejemplo, el combo C # -XAML es más amigable que JavaFX, porque C # y XAML fueron pirateados entre sí (por ejemplo, clases parciales en C #, enlaces en XAML y más). El uso de C # en JavaFX no mejora mucho. Para obtener la experiencia C # en la JVM, también necesita portar las herramientas, y ese es un proyecto mucho más grande. Ni siquiera Mono se molestará.

Entonces, mi consejo para un desarrollador de Java, que quiere usar un lenguaje más elegante además de herramientas familiares, es que revise los lenguajes JVM existentes .

Mono también es una opción, pero siempre he sido escéptico al respecto. Aunque es C # - .NET y multiplataforma, las cosas creadas con las herramientas de Microsoft generalmente no funcionan en Mono. Es esencialmente lo suyo. Veremos qué sucede ahora que Microsoft dijo que colaborarán.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.