Alguém está tentando implementar C # para o JVM? Como desenvolvedor Java, estou de olho no C # com inveja, mas não estou disposto a desistir da portabilidade e maturidade da JVM, sem mencionar a diversidade de ferramentas para ela.

Eu sei que existem algumas diferenças importantes entre o JVM e o CLR, mas há algo que seja um empecilho?

Existem diferenças muito significativas entre o CLR e a JVM.

Alguns exemplos:

• Java não tem tipos de valor definidos pelo usuário
• Genéricos Java são completamente diferentes dos genéricos .NET
• Muitos aspectos do C # dependem de elementos da estrutura - delegados etc. Você também precisaria portar a biblioteca, mesmo para aspectos de linguagem .
• Java não oferece suporte a coisas como propriedades e eventos em um nível de JVM. Você poderia fingir um pouco disso, mas não seria o mesmo.
• Não acredito que Java tenha qualquer equivalente a parâmetros de passagem por referência, mesmo no nível de JVM
• As sutilezas relacionadas aos diferentes modelos de memória possivelmente afetariam, embora eu não tenha certeza de quanto está nas especificações do C #.
• Código inseguro em geral provavelmente não é possível em Java
• A interoperabilidade com o código nativo é muito diferente entre JNI e P / Invoke. Isso provavelmente não é um grande problema para você.
• Você teria que fingir sobrecarga do operador e conversões definidas pelo usuário

Você provavelmente poderia portar muito C # - mas ficaria com uma experiência bastante insatisfatória, IMO.

Por outro lado, você conhece o IKVM ? Ele permite que você execute código Java em .NET.

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

O código abaixo é um código de linguagem 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 bytecode

O Grasshopper pode pegar um bytecode CLR e transpilá-lo para JVM. Destinado principalmente a aplicativos da web, ele não fornece, por exemplo, implementação JVM de classes do Windows Forms. Parece um pouco datado, no entanto. A web fala sobre ASP.NET 2.0, Visual Studio 2008 e assim por diante. Mencionado pela primeira vez por @alex

XMLVM pode receber bytecode CLR ou JVM como entrada e produzir como saída. Além disso, pode produzir Javascript ou Objective-C. Ainda não há lançamentos, apenas Subversion. "Versão de desenvolvimento experimental que não deve ser usada em um ambiente de produção."

O IKVM vai na direção oposta à que OP deseja. Ele fornece uma implementação de JVM em execução no CLR, um transpiler de bytecode de JVM para CLR e um gerador de stub de método de biblioteca CLR para Java. http://www.ikvm.net/uses.html Mencionado por @Jon Skeet

RPC

Por que não ter CLR e JVM rodando lado a lado e tornar a comunicação o mais simples possível? Não é isso que o OP deseja, mas algumas outras respostas já estão bastante fora do assunto de maneiras diferentes, então vamos abordá-las.

RabbitMQ , tem uma opção gratuita, é um servidor RPC escrito em Erlang com bibliotecas API para C #, Java e muito mais.

jnBridge , a licença pode ser muito cara para alguns usuários em potencial.

gRPC e bibliotecas RPC modernas semelhantes oferecem amplo suporte de linguagem, geração de código para bibliotecas de cliente nessas linguagens, formato de conexão independente de linguagem para dados, recursos avançados como cancelamento de chamada em cascata e assim por diante.

Linguagens de programação

Escreva uma vez, execute em qualquer lugar;)

Haxe , compila para C # / CLR, Java / JVM, Javascript, Flash, Python,… Fornece mecanismos de interoperabilidade para cada uma das linguagens de destino. Pode ser considerado um sucessor do ActionScript3 até certo ponto. Parece material bastante sólido, com pelo menos uma empresa realmente dependendo disso. Muito mais confiável do que Stab, mencionado a seguir.

Stab traz alguns recursos C # e interoperabilidade Java. Não é muito útil, você obtém alguns recursos C #, mas o que interage é o código Java que não os usa. https://softwareengineering.stackexchange.com/a/132080/45826 A linguagem é relativamente obscura, possivelmente abandonada, com poucas chances de se tornar melhor. Mencionado aqui pela primeira vez por @Vns.

Rajada de ar fresco para a plataforma JVM;)

Scala , Kotlin e outras são linguagens razoavelmente boas rodando em cima da JVM que trazem recursos que um programador C # pode perder em Java. Especialmente o Kotlin parece uma alternativa razoável ao C # no mundo da JVM. Scala pode ser uma linguagem um pouco extensa para um programador se sentir confortável em um curto espaço de tempo.

Mono

Essa é certamente uma opção também. Por que transpilar para JVM se o Mono pode executá-lo como está. Mencionado pela primeira vez por @ferhrosa

NOVA YORK - 12 de novembro de 2014 - Na quarta-feira, a Microsoft Corp. reforçou seu compromisso com as experiências de desenvolvedor de plataforma cruzada abrindo o código-fonte da pilha .NET completa do lado do servidor e expandindo o .NET para rodar nas plataformas Linux e Mac OS.

De acordo com este comunicado de imprensa do qual vem a citação, o Visual Studio 2015 adicionará Linux / Mono como uma plataforma compatível.

Este é um blog escrito pelo pessoal do projeto Mono sobre ele, do outro lado: .NET Source Code Integration (novembro de 2014).

.NET Core

Uma versão multiplataforma Windows / Linux de (alguns de) .Net administrada pela Microsoft. 'nuff disse https://github.com/dotnet/core .

Conclusão

Agora seria necessário dar uma chance a essas ferramentas / estruturas e ver quanta fricção existe. O OP deseja escrever em C # para a JVM, o que pode funcionar muito bem usando o Grasshopper.

Fazer isso com o objetivo de misturar bibliotecas C # e Java world em uma única base de código pode não funcionar tão bem.

Fontes

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

Pode ser mais simples escrever um conversor de IL para bytecode. Dessa forma, você obterá suporte automaticamente para qualquer linguagem .NET na JVM.

No entanto, essa é uma ideia tão óbvia que, se ainda não tiver sido feito, é provavelmente extremamente difícil ou difícil de fazer bem / utilmente.

Veja o Grasshopper . É um SDK baseado em Visual Studio e um conversor patenteado de .NET para Java que permite que você execute aplicativos .NET Web e de servidor em Linux® e outras plataformas habilitadas para Java.

Uma opção para desenvolvimento de plataforma cruzada em C # pode ser mono: http://www.mono-project.com/

Você pode usar um compilador de origem para origem para traduzir C # em uma linguagem que é executada na JVM. Por exemplo, existem vários conversores de C # para Java que permitiriam que aplicativos C # rodassem na JVM após serem traduzidos para Java.

Esta resposta pode demorar para você, mas esta é apenas nova. Você pode querer verificar a linguagem de programação Kotlin . Ele oferece os açúcares sintáticos que o C # tem e é o mais próximo da sintaxe C # também, exceto qualquer linguagem JVM não Java. É da JetBrains .

Posso ver duas razões pelas quais isso não está gerando tanto entusiasmo.

A primeira coisa a perceber é que, no que diz respeito aos recursos reais da linguagem, C # e Java estão muito próximos. Não apenas C # e Java estão próximos, eles também estão se movendo em direções semelhantes. Existem alguns recursos que a JVM não suporta atualmente, mas esse não é o problema real. Você sempre pode fingir o que está faltando. Acho que as pessoas preferem esperar que o Java obtenha um pouco mais de açúcar, do que criar um Quase-Java do zero. Quando a porta estiver pronta, Java pode ter decidido alcançá-la.

Em segundo lugar, a razão pela qual os desenvolvedores preferem C # não é tanto a linguagem em si, mas as ferramentas em torno dela, seu relacionamento bidirecional com C # e como a Microsoft oferece suporte a tudo isso. Por exemplo, a combinação C # -XAML é mais amigável do que JavaFX, porque C # e XAML foram hackeados um para o outro (por exemplo, classes parciais em C #, ligações em XAML e mais). Usar C # no JavaFX não melhora muito. Para obter a experiência C # na JVM, você também precisa portar as ferramentas, e esse é um projeto muito maior. Nem mesmo Mono vai incomodar.

Portanto, meu conselho para um desenvolvedor Java, que deseja usar uma linguagem sofisticada em cima de ferramentas familiares, é verificar as linguagens JVM existentes .

Mono também é uma opção, mas sempre fui cético quanto a isso. Embora seja C # - .net e multiplataforma, as coisas criadas com as ferramentas da Microsoft geralmente não funcionam no Mono. É essencialmente sua própria coisa. Veremos o que acontece agora que a Microsoft anunciou que vai colaborar.