Cosa sceglieresti per il tuo progetto tra .NET e Java in questo momento? [chiuso]


13

Stai appena iniziando un nuovo progetto e hai queste due tecnologie tra cui scegliere, Java e .NET. Il progetto a cui stai lavorando non prevede di avere funzionalità che semplifichino la scelta tra le due tecnologie (ad es. .NET ha ciò di cui ho bisogno e Java no) ed entrambi dovrebbero funzionare bene per te (anche se solo tu ne ho bisogno ovviamente). Tenere in considerazione:

  • Prestazione
  • Strumenti disponibili (anche strumenti di terze parti)
  • Compatibilità multipiattaforma
  • Librerie (in particolare librerie di terze parti)
  • Costo (Oracle sembra provare a monetizzare Java)
  • Processo di sviluppo (più semplice / più veloce)

Inoltre, tieni presente che Linux non è la tua piattaforma principale, ma desideri trasferire il tuo progetto anche su Linux / MacOs. Dovresti assolutamente tenere presente il problema che ruota attorno a Oracle e la comunità Java e i limiti di Mono e Java. Sarebbe molto apprezzato se le persone con esperienza in entrambi possano dare una visione d'insieme e la propria visione soggettiva su quale sceglierebbero e perché.

java  .net  mono 

Non ci sono abbastanza informazioni sui requisiti per rispondere efficacemente a questa domanda.
terra rossa

3
Mono è un dolore (ad es. Perdita di tempo). Anche un designer di base WinForm non è lì.
Giobbe

@Job in realtà, MonoDevelop ha un designer GUI per GTK #, dal momento che WinForms non è ancora open source.
Mahmoud Hossam,

Sì, ma com'è Mono con le librerie di terze parti? "Funzionano e basta"? E (forse ancora più importante) i fornitori forniscono supporto se li usi con Mono?
TMN

Risposte:


26

La singola decisione più importante (modifica: tecnica) è:

  • A questo punto ti impegnerai al 100% a utilizzare Windows come futura piattaforma di distribuzione?

Se no, allora dovresti andare con Java.


La conclusione di Mono è spesso usata per dire "Sì, .NET è multipiattaforma". Quanto è valido questo reclamo? era che Mono è solo un'opzione IFF che sviluppi contro di essa!

Non puoi aspettarti che le applicazioni .NET funzionino immediatamente.


@Basic ha detto che si trattava più di un commento che di una risposta. Per essere precisi, considero una domanda andare in cima alla lista, perché questa è forse la decisione tecnica più importante che devi fare quando hai a che fare con .NET. Come dice Basic, proverà contro Mono, quindi è fuori mano, e considererei Java e .NET abbastanza adatti. Ho poca esperienza con .NET, ma un po 'in Java.

  • Prestazioni: Java funziona abbastanza bene, ma ha ancora un bel po 'di tempo di avvio. Questo perché una JVM inizia da zero quando viene inizializzata e l'accesso casuale al file jar della libreria di runtime è piuttosto lento quando è necessario leggerlo dal disco. I Java 6 recenti hanno un processo in background per provare a mantenere i file jar della libreria di runtime nella cache del disco in modo che l'accesso sia rapido quando necessario.

  • Strumenti disponibili. Esistono molti strumenti e ce ne sono molti disponibili come Open Source di alta qualità. IBM ha a disposizione alcuni strumenti molto avanzati, ma richiedono anche parecchi soldi per loro. Potresti dare un'occhiata a MyEclipse che si guadagna da vivere mettendo insieme le parti migliori nel mondo Java e rendendole accessibili a basso costo, per vedere cosa è disponibile. Netbeans ha un editor GUI molto carino. JDeveloper ha un bel debugger Swing. Sun 6 JDK ha VisualVM che è un buon profiler entry level in grado di analizzare i programmi già in esecuzione (che è una caratteristica killer).

  • Compatibilità multipiattaforma. Molto buono, tendente all'eccellente. La JVM è molto, molto affidabile e prevedibile. I problemi vengono visualizzati solo quando le differenze del sistema operativo vengono visualizzate, come i separatori di file, la distinzione tra maiuscole e minuscole e il comportamento del menu.

  • Biblioteche. Ce ne sono molti e molti sono liberamente disponibili e utilizzabili, ma scritti principalmente in Java in quanto è piuttosto difficile inserire un codice scritto in linguaggi non JVM.

  • Costo. Java è sostanzialmente disponibile gratuitamente. Ciò che Oracle indica è che gli utensili elettrici - molto probabilmente provenienti da JRocket - avranno un costo. Si noti inoltre che il supporto esteso ("Java for Business") ha anche un prezzo. Le piattaforme non x86 sono una specie in via di estinzione, ma IBM ne ha molte e IBM fornisce un'eccellente implementazione Java per loro. Questo è considerato parte del sistema operativo, molto probabilmente per una migliore adozione.

  • Processo di sviluppo. Molto tempo con Java viene impiegato per la ricerca e la scelta della tecnologia appropriata e l'apprendimento, ma quando ciò viene fatto penso che ci siano molte tecnologie che sono abbastanza veloci da sviluppare. L'ultima versione di Java EE prevede la scrittura di pagine Web molto potenti utilizzando Facelets che possono essere ricaricate almeno quanto le pagine PHP.

Credo che a meno che non siano in grado di non Java o .NET, si sarà risparmiare tempo e denaro scegliendo la tecnologia voi e la vostra organizzazione è la più familiarità.


14
Chi garantisce che il programma Java che scrivi su Windows verrà eseguito altrove? Basta una sola chiamata JNI per rompere quella garanzia. Lo stesso problema riguarda la CLI: se si utilizza un'API non incrociata, si perde la portabilità. Pertanto, l'unica persona che può garantire la portabilità è te stesso - il programmatore, indipendentemente dal framework che stai utilizzando.
Segna H il

3
@ Thorbjørn, ti fideresti di Oracle nel clima attuale?
radekg,

12
+1 perché Thorbjørn ha detto che se non sei impegnato al 100% con Windows che dovresti andare con Java, non che devi andare con Java. E sono d'accordo: sì, Mono è lì come fallback, ma se i tuoi piani attuali non sono impegnati in Windows, risparmia il dolore e vai con la tecnologia che doveva funzionare su altre piattaforme. E lo dico come sviluppatore .NET e appassionato di .NET.
Carson63000,

4
Mi chiedevo se ci fosse uno dei "mono-esiste-su-altro" che ha effettivamente provato a farlo ...

4
"Java è sostanzialmente liberamente disponibile (...) gli utensili elettrici avranno un costo (...) anche il supporto richiesto ha un prezzo" . Esattamente lo stesso per.NET, giusto?
Konamiman,

19

OK, proviamo a scomporlo:

Tenere in considerazione:

Strumenti di prestazione disponibili (anche strumenti di terze parti)

Entrambe le piattaforme Java e .NET dispongono di molti buoni strumenti di test delle prestazioni disponibili, so che nello spazio Java ci sono molti strumenti open source gratuiti che sono adeguati per la maggior parte degli scenari. Non posso parlare per il lato .NET.

Compatibilità multipiattaforma

Qui Java ha un vantaggio: il progetto Mono (o simile) è necessario per far funzionare .NET su alcune piattaforme. Non sono sicuro che Mono sia al 100% a prova di proiettile e performante, qualcosa che si spera che qualcun altro possa avanzare.

Librerie (in particolare librerie di terze parti)

Entrambi hanno un forte supporto qui. Inizialmente l'ecosistema Java apre la strada (c'è letteralmente una libreria open source gratuita per qualsiasi cosa tu possa pensare) ma direi che .NET ha sicuramente raggiunto dove conta (NHiberante per la persistenza, NUnit per i test unitari per citarne due di base + Sono sicuro che ci sia un carico metrico in più).

Costo (Oracle sembra provare a monetizzare Java)

Tutte le aziende cercano di monetizzare in una certa misura, ma nel caso di Java penso che la tua affermazione sia un po 'fuorviante. Java era open source dalla versione 6 (il progetto OpenJDK) e Oracle non ha mostrato alcuna inclinazione a monetizzare Java oltre a ciò che Sun stava facendo. Quindi sì, vendono server app ed estensioni alla JVM (estensioni di gestione in particolare), ma core Java stesso? No e non lo faranno mai (questo è stato dichiarato pubblicamente molte volte).

Penso che sia MS che Oracle traggano enormi benefici a causa delle entrate indirette con le loro piattaforme reattive.

Costo totale di proprietà (TCO)? Non entrerò nemmeno in questo dibattito perché non c'è modo di dimostrarlo (dopo tutto la programmazione è un'attività umana creativa). Personalmente ritengo che i sistemi basati su Java tendano ad avere un costo iniziale inferiore poiché nella maggior parte dei casi è possibile utilizzare uno stack open source gratuito dall'alto verso il basso. Tuttavia, le grandi imprese tendono a preferire contratti di sostegno in modo tale da annullare tale vantaggio particolare.

Processo di sviluppo (più semplice / più veloce)

Dipende da cosa stai cercando di costruire! Personalmente direi che sono praticamente uguali, anche se al momento C # ha alcune funzionalità extra nel linguaggio principale su Java. Tuttavia, con le lingue (interoperabili multiple con Java) su JVM (Groovy, Scala, Clojure ecc.) Puoi avere tutte le funzionalità di lingua che desideri.

.NET ha avuto un netto vantaggio per la creazione di "roba" di front-end Web per un po '(sviluppo rapido di applicazioni, se vuoi), ma penso che JEE6 e / o Spring e altri framework web / app abbiano praticamente colmato questa lacuna.

Inoltre, tieni presente che Linux non è la tua piattaforma principale, ma desideri trasferire il tuo progetto anche su Linux / MacOs. Dovresti assolutamente tenere presente il problema che ruota attorno a Oracle e la comunità Java e i limiti di Mono e Java. Sarebbe molto apprezzato se le persone con esperienza in entrambi possano dare una visione d'insieme e la propria visione soggettiva su quale sceglierebbero e perché.

Se si desidera eseguire il porting su Linux, UNIX e in particolare su Mac OS, come indicato sopra, Java ha un vantaggio lì.

Spero possa aiutare!


4

Tenendo conto del tuo elenco di punti, sarei diviso e dipenderà davvero da ciò che devo costruire.

.Net vince per questi aspetti:

  • Prestazione
  • Processo di sviluppo (più semplice / più veloce)

Java vince per questi aspetti:

  • Compatibilità multipiattaforma
  • Librerie (in particolare librerie di terze parti)

È un pareggio per questi aspetti:

  • Costo (Oracle sembra provare a monetizzare Java)
  • Strumenti disponibili (anche strumenti di terze parti)

.Net è, a tutti gli effetti, uno stack tecnologico a piattaforma singola. Sì, c'è Mono, ma fino a quando Mono non è compatibile al 100% con l'implementazione di Windows non offre una vera esperienza multipiattaforma. L'unico sottoinsieme su cui potresti contare per il supporto multipiattaforma è quello che si adatterebbe in Silverlight.

Detto questo, .Net ha una migliore percezione delle prestazioni (misurazioni effettive TBD). Agli occhi dell'utente, la prestazione percepita è l'unica cosa che conta. Dopo aver sviluppato Java negli ultimi 12 anni e aver fatto .Net di recente, posso apprezzare la potenza della piattaforma.

Java d'altra parte ha un set IDE molto più ricco tra cui scegliere, e il costo di questi IDE superiori è molto inferiore al costo della variazione .Net. D'altra parte, il costo dei motori J2EE professionali riduce facilmente i costi dell'ambiente di sviluppo. In .Net ho la percezione di essere nichelato e oscurato fino alla morte. In Java ci sono soluzioni alternative agli enormi costi, che possono essere facilmente compensati con il tempo degli sviluppatori che li imposta. Al di fuori dell'IDE, per gli strumenti che contano (profiler, copertura, ecc.) I costi sono uguali.

Alla fine dipende davvero dalla necessità . Se ho intenzione di implementare su Windows comunque, allora .Net è un gioco da ragazzi. Ho clienti che sono solo negozi di Windows. Se sto implementando Unix o devo supportare sistemi eterogenei, Java non è un gioco da ragazzi. Potrei anche essere radicale e suggerire uno stack a tecnologia mista. Dopotutto, solo perché il client richiede che il server sia Unix non significa che lo eseguano sui loro desktop. Non tutte le applicazioni possono essere trasformate in un'app Web.


4

Prestazioni - Pari

Entrambe le piattaforme funzionano estremamente bene praticamente per tutte le applicazioni.

Non molto per distinguerli, anche se la mia esperienza soggettiva è che Java ha un leggero vantaggio per le applicazioni di lunga durata, mentre .Net è più veloce per i tempi di avvio delle applicazioni.

Strumenti disponibili (anche strumenti di terze parti) - Discutibili

Dipende dagli strumenti di cui hai bisogno e dalle tue conoscenze.

.Net ha certamente alcuni ottimi strumenti forniti da Microsoft. D'altra parte, esistono strumenti altrettanto validi nel mondo Java, ad esempio negli ambienti Eclipse, Netbeans di IntelliJ.

Compatibilità multipiattaforma : vincita Java

.Net è fondamentalmente legato alle piattaforme Microsoft (Windows, Xbox ecc.). Le implementazioni complete non sono disponibili per piattaforme non Microsoft .

Mono è bello, ma in realtà non ti offre la piena capacità multipiattaforma perché non supporta tutte le librerie .Net (ad esempio non puoi aspettarti che tutte le cose della GUI di Windows funzionino correttamente, quindi a meno che non passi a un toolkit multipiattaforma come GTK # non sarai in grado di eseguire la tua app su piattaforme diverse)

Java è veramente portatile. Non solo la lingua, ma soprattutto le librerie Java sono portatili. Fornendo di attenersi alle librerie Java pure (ad esempio Swing per GUI), il codice verrà eseguito ovunque si disponga di un ambiente di runtime Java.

Librerie (in particolare librerie di terze parti) : vincita Java

Probabilmente il miglior punto di forza della piattaforma Java è il vasto ecosistema di librerie, in particolare le librerie open source. Qualche esempio:

  • Tutte le librerie e gli strumenti di Apache
  • Tutte le librerie nel vasto ecosistema Eclipse
  • Tutte le librerie hanno contribuito / gestito da Google
  • JBoss e tutti gli strumenti aziendali correlati gestiti da Red Hat

Costo (Oracle sembra provare a monetizzare Java) - Java vince se vai all'open source, altrimenti Pari.

Puoi avere uno stack Java open source al 100% che è gratuito e non ti lega a nessuna particolare piattaforma proprietaria. Questo è gratuito al 100%.

In alternativa, è possibile acquistare IntelliJ IDEA, eseguire Java su Windows e utilizzare un database proprietario, nel qual caso è praticamente lo stesso costo di un tipico stack Microsoft .NET.

Processo di sviluppo (più semplice / più veloce) - discutibile

Questo probabilmente dipende più dall'esperienza dei tuoi sviluppatori con ciascuna piattaforma piuttosto che dal particolare attribuito della piattaforma.

.Net ha sicuramente degli ottimi strumenti che possono renderti molto produttivo per semplici app GUI su Windows. Non sorprende in quanto questo è il "punto debole" per lo sviluppo .Net.

D'altra parte, preferisco lo stack Java per lo sviluppo lato server. Con strumenti come Maven e tutte le funzionalità di implementazione / integrazione continue è possibile stabilire un processo di sviluppo molto efficace per robuste app lato server.

Dal punto di vista linguistico, C # presenta alcuni vantaggi in termini di produttività rispetto a Java. D'altra parte, se stai sviluppando sulla piattaforma Java al giorno d'oggi, la tendenza non è quella di utilizzare Java stesso, ma invece utilizzare uno dei nuovi linguaggi JVM come Scala, Groovy o Clojure - se lo fai, sarai molto più produttivo di C # o Java.


3

.Netto

È difficile rispondere a questa domanda senza essere soggettivo o inattaccabile dalla fiamma (ho la sensazione che sto per essere sottoposto a downgrade), ma .Net è un linguaggio in ripresa e Java sembra impantanato da questioni legali oltre a diventare meno popolare.

Anche .net al giorno d'oggi è di gran lunga un linguaggio molto più coeso e moderno con un eccellente supporto per la programmazione multicore (Parallel.net) e asincrona (estensioni reattive), per non parlare di LINQ di cui non potrei vivere senza. .Net ha anche una serie di strumenti gratuiti, ma Visual Studio Express, Sql Server Express, Web Matrix ecc.

È vero che Java offre alcuni vantaggi multipiattaforma. Hai alcune opzioni per .Net con mono etc che potrebbero fare per applicazioni tradizionali o componenti back-end, ma alcune diventano incerte se stai facendo qualcosa di molto specializzato (e non evitiamo di discutere di WPF).

Un'altra opzione se la multipiattaforma è davvero molto importante è andare Silverlight, personalmente non sono così appassionato di "applicazioni" silverlight ma almeno funziona.

La piattaforma incrociata è il punto dolente, chiediti se è davvero davvero necessario, almeno a questo punto.


Preferire .Net non è una brutta cosa. In realtà mi piace abbastanza. Non c'è dubbio che Java sta affrontando una crisi di identità al momento, il che è un peccato - mi piace anche quella piattaforma. Sono contento che tu abbia riconosciuto il track record migliorato di Java per multipiattaforma (+1). Alcuni client richiedono la distribuzione Unix, altri richiedono la distribuzione Windows. Le persone Java possono servire entrambe le piattaforme, mentre .Net è davvero limitato a Windows. Detto questo, ci sono molti client Windows solo là fuori.
Berin Loritsch,

1

Nella nostra organizzazione, a questo punto nel tempo, sceglieremmo Java. Il motivo è semplice: il nostro team Java è più grande, più esperto e meglio attrezzato rispetto al nostro team .NET (che è anche abbastanza legato nella manutenzione dei sistemi esistenti da non avere le risorse per occuparsi di nuovi importanti progetti) .
Detto questo, se ci fossero motivi urgenti per utilizzare .NET (ad esempio i requisiti del client, alcuni clienti potrebbero avere una vasta base installata di software .NET e desiderare che il loro nuovo sistema si adatti a tale base, si occupi della manutenzione da soli, ecc.) farlo e assumere appaltatori per svolgere il lavoro in cui non possiamo liberare la nostra gente.
Non forzerei nessuna tecnologia su un cliente contro i suoi migliori interessi, e alcuni clienti traggono semplicemente vantaggio (a causa della loro organizzazione interna) più dall'uno dall'altro a causa degli investimenti necessari per implementare il sistema (di nuovo, diciamo che abbiamo già un cliente ha un certo numero di applicazioni .NET in esecuzione e ha lo staff per supportarle, non proveremo a costringerle ad assumere persone e ad acquistare licenze hardware e software per eseguire un'applicazione Java sul lato, e ovviamente il contrario sarebbe anche essere veri. In effetti, consigliamo loro di non farlo se fossero venuti da noi con questo come richiesta).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.