Dovremmo scegliere Java su C # per un nuovo progetto? [duplicare]

Questo proviene da uno sviluppatore che ha lavorato in entrambi i framework .NET e Java.

Quelli che si arrabbiano e si arrabbiano per questa situazione sono miopi, pigri o semplicemente stupidi. Prima di essere svalutato, ascoltami, non perché ritengo che Java sia una piattaforma superiore a .NET, anzi, è proprio l'opposto. Il linguaggio C # è MOLTO meglio e EntityFramework con LINQ è IMHO RIVOLUZIONARIO.

Il motivo per cui dovrebbero prendere in considerazione questa decisione è perché avere più di 2 anni di esperienza in entrambi i framework mi ha aperto le porte. Non posso andare in bagno senza i cacciatori di teste che mi supplicano di parlare loro della pila di opportunità di lavoro che hanno schierato.

Quando il mercato del lavoro è del 45% - Java, 35% - C # /. NET e 20% - (PHP, Perl, Ruby, ecc.), sei sostanzialmente qualificato per quasi i 4/5 del lavoro disponibile aperture in qualsiasi momento.

E anche se il denaro non è il tuo principale motivatore, allora non diventare compiacente è. Non appena inizi a sentirti a tuo agio, è il momento in cui hai bisogno di scuotere le cose e provare qualcosa di nuovo. Le persone che non riescono ad allontanarsi dalla loro zona di comfort sono o miopi o dominate dalla paura dell'ignoto e questo non è quello che cerco quando intervisto gli sviluppatori.

Ammettiamolo, sto lavorando abbastanza felicemente in Java ora - sto facendo buoni soldi e se questo non funziona ho la sicurezza e la tranquillità di sapere che ho molte più opportunità di tanti altri Sarò in competizione con. Mi manca C #? sì, ma alla fine ho avuto bocche da sfamare e sto solo cercando di farmi strada.

In primo luogo, Linux come nuova piattaforma non è un grosso problema. Java è basato sulla JVM che fa un buon lavoro nascondendo il sistema e l'hardware. Se hai bisogno di scavare nel sistema operativo, a mio parere né Java né C # sono la lingua prescelta. È molto simile allo sviluppo di PHP. Puoi farlo con un server web su Linux e Windows, e in quasi tutti i casi non ci sono differenze durante il runtime a causa del sistema su cui è distribuito.

Quando sviluppi applicazioni Web con Java, in particolare applicazioni Web aziendali, probabilmente utilizzerai Java EE , quindi dovrai utilizzare un contenitore ( JBoss , WebSphere , GlassFish , ecc.). Questi possono essere eseguiti su Windows o Linux, non importa. I nostri sistemi di produzione utilizzano Red Hat Enterprise Linux con JBoss, mentre la maggior parte degli sviluppatori ha sistemi Windows 7 e questa disomogeneità non ha mai causato problemi.

Anche il passaggio a Java da C # non è molto complicato. Le lingue sono abbastanza simili nella maggior parte degli aspetti. Mancherete davvero alcune funzionalità come Proprietà e LINQ , ma questa è davvero una preoccupazione minore.

Un problema molto più grande sono le API. Java e J2EE fatti bene differiscono parecchio dalle tecnologie .NET (web). Dovresti fare uno sforzo serio per imparare JPA e EJB best practice (se si utilizza Java EE, ovvero, JPA può anche funzionare in modalità standalone). Consiglio anche di utilizzare EJB 3.0 in quanto le versioni precedenti sono completamente sovrastampate e ora sono state semplificate. Purtroppo, la maggior parte dello sviluppo di Java in questi giorni è ancora un'avventura attraverso l'XML-Hell. Sebbene la convenzione sulla configurazione sia stata implementata nelle versioni più recenti della maggior parte delle API, c'è ancora molto XML da scrivere. Questo è particolarmente vero per lo sviluppo web ( JSF per esempio). Si noti che in questo contesto sto parlando di problemi di configurazione e non dello sviluppo dichiarativo dell'interfaccia utente.

Per quanto riguarda le tecnologie web, consiglierei di non usare JSF (che è propagato come standard), in quanto è complicato e troppo ingegnerizzato. Potrebbe migliorare con le prossime versioni. Preferisco usare Apache Wicket o Tapestry , che ti farà risparmiare un sacco di mal di testa, soprattutto se avrai la necessità di controlli utente personalizzati o di script ricchi di client.

Per quanto riguarda l'interoperabilità: se i servizi esistenti sono codificati in base agli standard del settore ( REST / SOAP ) quindi probabilmente non hai problemi a consumarli con .NET. Tuttavia, se devi utilizzare librerie e moduli esistenti, probabilmente è meglio usare Java, per mantenere alta la riusabilità ( ASCIUGA ) e per omogeneità.

Il mio consiglio è di mantenere pulito l'ambiente del cliente. Usa Java, il cambio di lingua non è così complicato. Allenati sulle API che desideri utilizzare ampiamente . So che gli sviluppatori stanno per imprecare, perché mancheranno LINQ e perché scriveranno un codice un po 'più standard, ma puoi sicuramente trasferire molta esperienza (specialmente sulla parte di modellazione) al nuovo ambiente.

Modifica Per quanto riguarda le API di scelta, alcune persone (@TMN per esempio, grazie per averlo indicato) suggeriscono di saltare del tutto EJB e di adottare Spring Framework e Hibernate . Hibernate può anche essere utilizzato come provider JPA. Questo non è certamente un cattivo consiglio.

Perché non usare Mono?

In realtà ho utilizzato con successo Mono e .NET 3.5 su linux per software commerciale negli ultimi due anni. Ci sono solo alcune cose che non sono completamente supportate da Mono. Tuttavia, il nostro team ha generalmente sfruttato al meglio e siamo estremamente soddisfatti dei risultati.

Il cambio di framework non è banale

Conosco personalmente sia Java (Spring MVC, J2EE, WebSphere, ecc.) che C # (3.5, 4.0, Castle MVC, ASP.NET MVC, NHibernate, ecc.). Il passaggio tra l'utilizzo di ASP.NET e Java è tutt'altro che banale.

Puro codice sì molto simile e facile da passare tra Java e C # (senza Linq ovviamente, tuttavia c'è java funzionale ).

Perdere esperienza combinata in framework .NET

Tuttavia ciò che perdi se decidi di cambiare è la tua esperienza combinata con i tuoi quadri attuali e dovrai ricominciare da zero ad apprendere un nuovo framework. Il che richiederà tempo e denaro a velocità di progetto ridotta mentre i tuoi sviluppatori apprendono un nuovo framework.

La pianificazione basata sull'evidenza è diventata molto più difficile

Questa è la parte più banale dell'equazione, non solo non sarai più in grado di calcolare con successo le date del progetto poiché gli sviluppatori non saranno in grado di giudicare se una parte del progetto funzionerà nel modo in cui lo desiderano . Quindi ci si può aspettare che uno sviluppatore dicesse "Se stavo usando .NET mi aspetterei che occorresse X giorni con un tasso di accuratezza dell'80% in entrambi i casi, ma visto che sto usando una struttura non familiare forse il tasso di accuratezza dovrebbe essere 160% ".

I tuoi sviluppatori VOGLIONO imparare una nuova lingua / struttura?

La chiave qui sta assumendo che i tuoi attuali sviluppatori VOGLIONO imparare un nuovo framework. Altrimenti potrebbero non dare una buona idea all'apprendimento di Java / J2EE e rinunciare al primo segno di cambiamento o resistenza al modo in cui sanno come farlo in .NET.

Gli sviluppatori possono decidere di lasciare

Se non hai un buy-in per gli sviluppatori, potresti finire con gli sviluppatori che escono completamente. È triste, ma forse la situazione che dovrai affrontare considerando che esiste un'alternativa open source molto usata in Mono.

Sono passato da Java a C # e di nuovo a Java / Clojure, quindi posso davvero simpatizzare con il tuo team. Le persone naturalmente resistono al cambiamento, in particolare quando temono che le loro abilità acquisite con fatica diventino inutili o meno preziose.

Tuttavia ci sono molti modi positivi per guardare questo:

• Java e C # sono in realtà, nel grande schema delle cose, molto simili a livello di linguaggio. Non è particolarmente sorprendente se si considera che la sintassi C # era ampiamente basata su Java (con varie aggiunte). Abilità in un modo significa che diventerai bravo nell'altro abbastanza rapidamente (mi ci sono voluti solo un paio di settimane per passare da una parte all'altra), e sembra buono sul tuo curriculum non essere visto solo come "una persona con una sola tecnologia".
• Una volta superato le differenze sintattiche minori della differenza, si utilizzano i diversi framework (J2EE vs ASP.NET vs WPF vs Swing, ecc.). Tuttavia, se stai sviluppando un nuovo stack basato su HTML5, probabilmente dovrai comunque imparare nuovi framework. Quindi questo è davvero un grosso problema? Lo considererei un'opportunità per imparare nuovi modi di fare le cose che ti renderanno un programmatore migliore a lungo termine.
• La piattaforma Java è fantastica e ha molto da offrire. L'ingegneria nella JVM è sorprendente, c'è un fantastico ecosistema di librerie open source, gli strumenti sono eccellenti (Eclipse, Maven, EGit sono quelli che uso di più), puoi scrivere in realtà soluzioni cross-platform, c'è una quantità enorme di happening di innovazione (specialmente nel framework e nello spazio new-language JVM). Certo è diverso dallo stack Microsoft, ma è certamente almeno complessivamente buono.
• Ci sono un sacco di cose fantastiche sulla piattaforma Java perché le persone si entusiasmino . Non sei legato a Java-the-language in futuro. Esempio: Android , Scala , Clojure , sono tutte aree di vera innovazione e opportunità.
• Linux è una grande piattaforma per imparare e lavorare. La tua squadra potrebbe trovarlo diverso e insolito in un primo momento se non hanno avuto esperienza in precedenza, ma ha un sacco di grandi cose per questo. Sicuramente ogni sviluppatore che si rispetti può vedere il valore nell'imparare una nuova tecnologia?
• Anche tu non devi rinunciare a Windows - Personalmente uso Windows come ambiente di sviluppo desktop preferito (con IDE Eclipse per Java), ma distribuisco tutte le mie applicazioni con Linux sul lato server.

Alcuni consigli se fai lo switch:

• Keep It Simple e non esagerare con tutte le cose Java "Enterprisey". Va bene se stai scrivendo un sistema bancario per 25 anni ma probabilmente esagerare per la maggior parte delle situazioni e sarà estremamente spaventoso per i nuovi arrivati. Attenersi invece alle soluzioni più moderne / più semplici / più leggere. (Cose come Vaadin per l'interfaccia utente, ad esempio)
• Considera Scala o Clojure piuttosto che Java come linguaggio di sviluppo. Scala è più OOP, Clojure è più funzionale, ma entrambi sono un grande progresso su Java / C #. Entrambi interagiscono estremamente bene con Java (tutte le librerie sono compatibili, la chiamata a / da Java è molto semplice, vengono eseguite nello stesso processo / spazio di memoria ecc.) Quindi non è un problema se si mescola questo con qualche sviluppo fatto in Java nella tua azienda.
• Avvia un buon ambiente di sviluppo - la cosa peggiore quando fai un cambio è avere un sistema di sviluppo / build non funzionante in modo da non sapere cosa sta andando male. Sia che tu usi Eclipse o qualcos'altro, assicurati di avere un vero esperto per creare uno sviluppo di best practice. ambiente in modo che i membri del tuo team possano essere immediatamente produttivi / iniziare l'apprendimento senza troppi problemi.

Vorrei integrare la risposta di Justin Shield.

Mono è maturato oltre le aspettative di chiunque (oltre a Miguel). Il team ha davvero bisogno di persone come la tua azienda per dimostrarne la fattibilità. Devono ottenere una trazione credibile da qualche parte.

Detto questo, né io né nessun altro garantiremmo una transizione indolore da .NET Framework a Mono. Pensa a Mono come a una versione rigorosa di .NET Framework. Lo hanno implementato sulla base dell'API pubblica e delle informazioni rilasciate all'ECMA. Microsoft ama rendere gli sviluppatori più semplici, facendo funzionare le cose che davvero non dovrebbero. Probabilmente non fermeranno mai questa pratica. Il team Mono può sapere solo quando Microsoft ha fatto ciò quando qualcuno ha riscontrato un problema. Assicurati che il nuovo codice sia conforme a CLR.

C'è anche un'altra soluzione che la tua azienda può dare un'occhiata. IKVM . È una Java Virtual Machine scritta in C #. Sì, una JVM completa scritta sulla piattaforma .NET. Non solo, ma ha un compilatore per convertire qualsiasi codice Java Byte in codice IL e utilizza una versione convertita di OpenJDK. È un'altra soluzione che ha bisogno di più dimostrazione con l'uso commerciale.

Se il mio datore di lavoro mi ha dato una OPPORTUNITÀ per lavorare su un nuovo progetto e imparare una nuova lingua / struttura e c'era un budget di formazione e comprensione del fatto che ci sarebbe stato un tempo di la nuova lingua, probabilmente li abbraccerei.

Developers with a range of experience from 2 to 6 years ... How do I find something positive in moving over that will convince the other developers?

È bizzarro che una decisione strategica di piattaforma strategica come questa sia lasciata ai capricci degli sviluppatori junior. Il tuo ragazzo anziano deve essere in grado di scegliere la piattaforma giusta per l'azienda. In altri 5 anni C # potrebbe benissimo essere in strong declino dato che Win32 / 64 perde importanza alla luce dell'uptake di OS X e iOS (non crederci, controlla i numeri e i grafici delle entrate di AAPL). Chiedi ai tuoi sviluppatori perché vogliono svilupparsi per una piattaforma che sarà morta tra 10 anni. Vogliono essere come IBM negli anni '80?

Per questo motivo, Java è il modo migliore per andare perché consente la migrazione alla nuova piattaforma (con il desiderato Linux e OS X) in modo multipiattaforma, senza altri middleware come Mono (livelli di emulazione). C # e Java sono quasi identici linguaggi sintatticamente. .NET è solo un mucchio di chiamate in biblioteca. Riferimento: link

La mia risposta presuppone che stai si muoverà.

Aggiungerò alla risposta di @ Falcon:

La JVM è una piattaforma incredibile su cui correre. Se i tuoi sviluppatori hanno bisogno della potenza di un altro linguaggio (ad esempio Scala, che supporta LINQ), possono usare felicemente quel linguaggio e interagire direttamente con Java. È molto più flessibile del CLR. Come menziona @Falcon, i tuoi sviluppatori possono anche continuare a sviluppare e testare su Windows fino a quando non si sentiranno più a loro agio nell'ambiente Linux. Credo che gli sviluppatori dovrebbero anche sentirsi a proprio agio con la build, la distribuzione, i server di app, ecc. Quindi suggerisco di fare un po 'di formazione per questo.

Guardate sicuramente lo stack JEE6 (EJB 3.0, JPA, ecc.). La codifica basata sulle annotazioni sarà abbastanza vicina a ciò che fanno i C # oggi (sì, devi ancora fare qualche configurazione XML, ma non è così male come una volta, onesto). Ci sono un bunhc di server di applicazioni open source gratuiti che eseguiranno il codice JEE6 (Jboss, Glassfish, Tomcat e altri). C'è uno strumento particolare chiamato JRebel, che è un must se si sta sviluppando in questo ambiente in quanto significa che non è necessario avere il costoso ciclo di stop / start per il server delle applicazioni ogni volta che si distribuisce.

In alternativa, se hai bisogno di fare un po 'di prototipazione rapida per iniziare, puoi guardare SEAM, Spring Roo o Grails, ma preparati a buttare via i risultati in seguito.

L'ecosistema Java ha una libreria per tutto . Questa è solo una leggera esagerazione, ha davvero una libreria libera e open source per quasi ogni occasione. Se c'è una caratteristica che manca al tuo team da C # o da qualche altra libreria che usano, ci sarà quasi sicuramente un equivalente basato su Java libero e open source.

Si spera che si possa mantenere il livello Web semplice, basato sulla classe AJAX rispetto a qualsiasi delle tecnologie Java ben intenzionate ma imperfette (JSP, JSF, Wicket, Tapestry ecc.)

Puoi segnalare ai tuoi sviluppatori che l'ecosistema Java sta vivendo una massiccia rinascita al momento, ha una community davvero appassionata e un ambiente di libertà per gli sviluppatori (hai una scelta infinita di lingue, librerie e piattaforme).

Se c'è una cosa più fastidiosa della richiesta di codificare in modo produttivo in un ambiente in cui non si ha esperienza, è stare in una squadra dove nessuno ha esperienza nella tecnologia. The Blind Leading the Blind.

Ottieni un allenatore / allenatore / consulente che conosca lo stack verso il quale ti stai spostando. Invitalo a far parte del team e renderli principalmente responsabili per l'assistenza alla tua squadra. (Non assegnare loro compiti, ma chiedi loro di ruotare e di accoppiarsi con gli sviluppatori.) Questo darà alla tua squadra una "vecchia mano" per andare quando hanno domande sul nuovo ambiente. (Se sei già una squadra agile che fa l'accoppiamento, sarà più facile per l'assorbimento.)

Un paio di punti che vorrei aggiungere.

Sì, come dev, passare da .Net a Java sarà un po 'una sfida.

E sì, paga per lo sviluppatore, espandendo le abilità.

E sì, fa in una mano pagare per la compagnia, in quanto gli sviluppatori sono più facilmente trasferiti tra i progetti (dal momento che la lingua non è una barriera)

Ma c'è un lato negativo quando un'organizzazione è bloccata con una lingua. Ed è lo stesso problema di uno sviluppatore bloccato in una lingua. Quando vai ad acquistare app e le integri con il tuo codice esistente, sei bloccato nello stack che conosci e impila a lavorare.

Finisci per ignorare un ottimo prodotto perché non hai persone addestrate a personalizzarlo in base alle tue esigenze. O lo compri ancora e fai un lavoro a metà con l'integrazione perché non lo capisci completamente. Ma poi, sei di nuovo bloccato in due pile, con gli stessi problemi che avevi prima.