¿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?

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.

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);
        }
    }
}

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

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.

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.

Una opción para el desarrollo multiplataforma en C # podría ser mono: http://www.mono-project.com/

Puede utilizar un compilador de fuente a fuente para traducir C # a un lenguaje que se ejecuta en la JVM. Por ejemplo, hay varios convertidores de C # a Java que permitirían que las aplicaciones de C # se ejecuten en la JVM después de ser traducidas a Java.

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 .

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.