Qualcuno sta tentando di implementare C # per la JVM? Come sviluppatore Java, ho guardato C # con invidia, ma non sono disposto a rinunciare alla portabilità e alla maturità della JVM, per non parlare della vasta gamma di strumenti per esso.
So che ci sono alcune differenze importanti tra JVM e CLR, ma c'è qualcosa che è uno spettacolo?
Risposte:
Esistono differenze molto significative tra CLR e JVM.
Alcuni esempi:
Probabilmente potresti portare un sacco di C #, ma rimarrai con un'esperienza piuttosto insoddisfacente, IMO.
Andando dall'altra parte, conosci IKVM ? Ti consente di eseguire codice Java in .NET.
Visita http://code.google.com/p/stab-language
Il codice seguente se un codice lingua Stab per 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);
}
}
}Grasshopper può prendere un bytecode CLR e trasferirlo per JVM. Destinato principalmente alle app Web, non fornisce, ad esempio, l'implementazione JVM delle classi Windows Forms. Sembra un po 'datato, però. Il web parla di ASP.NET 2.0, Visual Studio 2008 e così via. Menzionato per la prima volta da @alex
XMLVM può prendere il bytecode CLR o JVM come input e produrlo come output. Inoltre può generare Javascript o Objective-C. Nessun rilascio ancora, solo Subversion. "Versione di sviluppo sperimentale che non deve essere utilizzata in un ambiente di produzione."
IKVM va nella direzione opposta rispetto a quanto vuole OP. Fornisce un'implementazione JVM in esecuzione su CLR, un transpiler bytecode da JVM a CLR e un generatore di stub del metodo della libreria CLR per Java. http://www.ikvm.net/uses.html Menzionato da @Jon Skeet
Perché non far funzionare CLR e JVM insieme e rendere la comunicazione il più semplice possibile? Questo non è ciò che vuole l'OP, ma alcune altre risposte sono già abbastanza fuori tema in modi diversi, quindi copriamolo.
RabbitMQ , ha un'opzione gratuita, è un server RPC scritto in Erlang con librerie API per C #, Java e altro.
jnBridge , la licenza potrebbe essere troppo costosa per alcuni potenziali utenti.
gRPC e librerie RPC moderne simili offrono ampio supporto linguistico, generazione di codice per librerie client in questi linguaggi, formato wire indipendente dalla lingua per i dati, funzionalità avanzate come l'annullamento delle chiamate a cascata e così via.
Scrivi una volta, corri ovunque;)
Haxe , compila in C # / CLR, Java / JVM, Javascript, Flash, Python, ... Fornisce meccanismi di interoperabilità per ciascuno dei linguaggi di destinazione. Può essere considerato in una certa misura un successore di ActionScript3. Sembra roba abbastanza solida, con almeno un'azienda che dipende da essa. Molto più affidabile di Stab, menzionato dopo.
Stab offre alcune funzionalità C # e l'interoperabilità di Java. Non molto utile, ottieni alcune funzionalità C #, ma ciò con cui interagisci è il codice Java che non le utilizza. https://softwareengineering.stackexchange.com/a/132080/45826 Il linguaggio è relativamente oscuro, forse abbandonato, con poche promesse di miglioramento. Menzionato per la prima volta qui da @Vns.
Raffica di aria fresca per la piattaforma JVM;)
Scala , Kotlin , altri, sono linguaggi abbastanza carini in esecuzione su JVM che offrono funzionalità che un programmatore C # potrebbe perdere in Java. Soprattutto Kotlin sembra una ragionevole alternativa a C # nel mondo JVM. Scala potrebbe essere un linguaggio un po 'troppo vasto per un programmatore con cui sentirsi a proprio agio in breve tempo.
Anche questa è certamente un'opzione. Perché transpile in JVM se Mono può eseguirlo così com'è. Menzionato per la prima volta da @ferhrosa
NEW YORK - 12 novembre 2014 - Mercoledì, Microsoft Corp. ha rafforzato il proprio impegno a favore di esperienze di sviluppo multipiattaforma rendendo open source l'intero stack .NET lato server e espandendo .NET per l'esecuzione su piattaforme Linux e Mac OS.
Secondo questo comunicato stampa da cui proviene la citazione, Visual Studio 2015 aggiungerà Linux / Mono come piattaforma supportata.
Questo è un blog scritto dalle persone del progetto Mono sull'argomento, dall'altra parte: .NET Source Code Integration (novembre 2014).
Una versione multipiattaforma Windows / Linux di (alcuni di) .Net governata da Microsoft. 'nuff ha detto https://github.com/dotnet/core .
Sarebbe ora necessario provare questi strumenti / framework e vedere quanto attrito c'è. L'OP vuole scrivere in C # per la JVM, che potrebbe effettivamente funzionare abbastanza bene usando Grasshopper.
Fare questo con l'obiettivo di combinare le librerie del mondo C # e Java in una singola base di codice potrebbe non funzionare così bene.
Fonti
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
Potrebbe essere più semplice scrivere un convertitore da IL a bytecode. In questo modo otterrai automaticamente il supporto per qualsiasi linguaggio .NET sulla JVM.
Tuttavia, questa è un'idea così ovvia che se ciò non è già stato fatto, probabilmente è estremamente difficile, o difficile da fare bene / utilmente.
Guarda Grasshopper . È un SDK basato su Visual Studio e un convertitore brevettato da .NET a Java che consente di eseguire applicazioni Web e server .NET su Linux® e altre piattaforme abilitate per Java.
Un'opzione per lo sviluppo multipiattaforma in C # potrebbe essere mono: http://www.mono-project.com/
È possibile utilizzare un compilatore da sorgente a sorgente per tradurre C # in un linguaggio che viene eseguito sulla JVM. Ad esempio, esistono diversi convertitori da C # a Java che consentono alle applicazioni C # di essere eseguite sulla JVM dopo essere state tradotte in Java.
Posso vedere due ragioni per cui questo non sta ottenendo molto entusiasmo.
La prima cosa da capire è che, quando si tratta delle effettive caratteristiche del linguaggio, C # e Java sono molto simili. Non solo C # e Java sono vicini, ma si muovono anche in direzioni simili. Ci sono alcune funzionalità che la JVM attualmente non supporta immediatamente, ma non è questo il vero problema. Puoi sempre fingere ciò che manca. Penso che le persone preferiscano aspettare che Java ottenga un po 'più di zucchero, piuttosto che creare un Almost-Java da zero. Quando il port è pronto, Java potrebbe aver deciso di mettersi al passo.
In secondo luogo, il motivo per cui gli sviluppatori preferiscono C # non è tanto il linguaggio stesso, ma gli strumenti che lo circondano, la loro relazione bidirezionale con C # e il modo in cui Microsoft supporta l'intera cosa. Ad esempio, la combinazione C # -XAML è più amichevole di JavaFX, perché C # e XAML sono stati hackerati l'uno per l'altro (ad esempio, classi parziali in C #, associazioni in XAML e altro). L'uso di C # su JavaFX non migliora molto. Per ottenere l'esperienza C # sulla JVM, è necessario portare anche gli strumenti, e questo è un progetto molto più grande. Nemmeno Mono si preoccuperà.
Quindi, il mio consiglio a uno sviluppatore Java, che desidera utilizzare un linguaggio più elaborato in cima a strumenti familiari, è di controllare i linguaggi JVM esistenti .
Anche il mono è un'opzione, ma sono sempre stato scettico al riguardo. Anche se è C # -. NET e multipiattaforma, le cose create con gli strumenti di Microsoft generalmente non funzionano su Mono. È essenzialmente una cosa sua. Vedremo cosa succederà ora che Microsoft ha detto che collaboreranno.