c# java clr jvm

Implementando C#para la JVM



java clr (9)

Transcriptores de bytecode

Grasshopper puede tomar un bytecode CLR y transpilarlo para JVM. Destinado principalmente para aplicaciones web, no proporciona, por ejemplo, la implementación de JVM de las clases de Windows Forms. Parece un poco anticuado, sin embargo. La web habla de ASP.NET 2.0, Visual Studio 2008, etc. Primero mencionado por @alex

XMLVM puede tomar CLR o JVM bytecode como entrada y producir como salida. Además, puede generar Javascript o Objective-C. Todavía no hay lanzamientos, solo Subversion. "Versión de desarrollo experimental que no se debe usar en un entorno de producción".

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

RPC

¿Por qué no tener CLR y JVM corriendo al costado y hacer que la comunicación sea lo más libre de fricción 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 vamos a cubrirlo.

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 ser demasiado costosa para algunos usuarios potenciales.

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

Lenguajes de programación

Escribe una vez, corre por todos lados;)

Haxe , compila para C # / CLR, Java / JVM, Javascript, Flash, Python, ... Proporciona mecanismos de interoperabilidad para cada uno de los idiomas de destino. Se puede considerar como un sucesor de ActionScript3 hasta cierto punto. Parece bastante sólido, con al menos una compañía que realmente depende de él. Mucho más confiable que Stab, mencionado a continuación.

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

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

Scala , Kotlin , otros, son lenguajes bastante agradables que se ejecutan en la parte superior de JVM, que traen 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 grande para que un programador se sienta cómodo en poco tiempo.

Mono

Esa es ciertamente una opción también. Por qué transpile a JVM si Mono puede ejecutarlo tal como es. Primera mención por @ferhrosa

NUEVA YORK - 12 de noviembre de 2014 - El miércoles, Microsoft Corp. reforzó su compromiso con las experiencias de desarrolladores multiplataforma mediante la creación abierta del stack .NET completo del lado del servidor y la expansión .NET para ejecutar 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 una 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 (algunos) .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 C # y Java World Libraries 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

¿Alguien intenta 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, por no mencionar la amplia gama de herramientas para ello.

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

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

Hay diferencias muy significativas entre el CLR y la 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 los elementos del marco: delegados, etc. También deberá portar la biblioteca, incluso para los aspectos del lenguaje .
  • Java no admite cosas como propiedades y eventos en un nivel 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
  • Las sutilezas que tienen que ver con los diferentes modelos de memoria podrían morder, aunque no estoy seguro de cuánto hay en la especificación de C #.
  • Código inseguro en general, probablemente no es posible en Java
  • La interoperabilidad con el código nativo es muy diferente entre JNI y P / Invoke. Esto probablemente no es un gran problema para ti.
  • Tendría que falsificar la sobrecarga del operador y las conversiones definidas por el usuario

Probablemente puedas portar mucho C # - pero te quedaría con una experiencia bastante insatisfactoria, IMO.

Yendo por el otro lado, ¿conoces ikvm.net ? Le permite ejecutar código Java en .NET.

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

Puede ser más simple escribir un convertidor desde IL a bytecode. De esta forma, obtendría soporte automáticamente para cualquier lenguaje .NET en la JVM.

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

Puedo ver dos razones por las cuales esto no está recibiendo mucho entusiasmo.

Lo primero es darse cuenta de que, cuando se trata de las características reales del lenguaje, C # y Java son muy cercanos. No solo se cierran C # y Java, sino que también se mueven en direcciones similares. Hay algunas características que la JVM no admitirá actualmente, pero ese no es el problema real. Siempre puedes simular lo que falta. Creo que la gente prefiere esperar a que Java obtenga más azúcar, que crear casi Java desde cero. Para cuando el puerto esté listo, Java puede haber 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í mismo, sino las herramientas que lo rodean, su relación bidireccional con C # y cómo Microsoft lo soporta 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). Usar C # en JavaFX no mejora mucho. Para obtener la experiencia de C # en JVM, también debe portar las herramientas, y ese es un proyecto mucho más grande. Ni siquiera http://www.mono-project.com/ se molestará.

Por lo tanto, mi consejo para un desarrollador de Java, que quiere usar un lenguaje más elegante en la cima de las herramientas familiares, es verificar 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 funcionarán en Mono. Es esencialmente lo suyo. Veremos qué sucede ahora que Microsoft dijo que colaborarán.

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

El código a continuación si es un código de lenguaje 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); } } }