Per gli sviluppatori c # che stanno iniziando a imparare Java, ci sono grandi differenze di fondo tra i due linguaggi che dovrebbero essere evidenziate?
Forse alcune persone potrebbero presumere che le cose siano le stesse, ma ci sono alcuni aspetti importanti che non dovrebbero essere trascurati? (o puoi davvero sbagliare!)
Forse in termini di costrutti OOP, il modo in cui funziona GC, riferimenti, distribuzione correlata, ecc.
Risposte:
Alcuni trucchi dalla cima della mia testa:
byte è firmato in Java (purtroppo)static, avrà un riferimento implicito a un'istanza della classe contenitore.ecco un confronto molto completo delle 2 lingue:
http://www.25hoursaday.com/CsharpVsJava.html
Aggiunto: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp
Sono sorpreso che nessuno abbia menzionato le proprietà, qualcosa di abbastanza fondamentale in C # ma assente in Java. Anche C # 3 e versioni successive hanno implementato automaticamente le proprietà. In Java devi usare metodi di tipo GetX / SetX.
Un'altra evidente differenza è rappresentata da LINQ e dalle espressioni lambda in C # 3 assenti in Java.
Ci sono alcune altre cose semplici ma utili che mancano in Java come le stringhe verbatim (@ ""), il sovraccarico degli operatori, gli iteratori che utilizzano il rendimento e il pre processore mancano anche in Java.
Uno dei miei preferiti personali in C # è che i nomi degli spazi dei nomi non devono seguire la struttura della directory fisica. Mi piace molto questa flessibilità.
Ci sono molte differenze, ma queste mi vengono in mente:
.equalsè quello che devi usare.
.NET ha reificato i generici; Java ha cancellato i generici.
La differenza è questa: se hai un ArrayList<String>oggetto, in .NET, puoi dire (in runtime) che l'oggetto ha tipo ArrayList<String>, mentre in Java, in runtime, l'oggetto è di tipo ArrayList; la Stringparte è persa. Se inserisci non Stringoggetti in ArrayList, il sistema non può imporlo e lo saprai solo dopo aver provato a estrarre l'oggetto e il cast fallisce.
Stringoggetti non- oggetti in quella lista senza fare un cast non controllato, da qualche parte , e il compilatore ti avviserà correttamente a quel punto che il compilatore non può più controllare i limiti generici. Finché il tuo elenco è sempre memorizzato in una variabile di List<String>, i tentativi di inserire un oggetto non String in esso non verranno compilati.
addmetodo (di nuovo, tramite la riflessione). Il sistema rifiuterà un non Stringoggetto immediatamente o solo quando proietterà il risultato di get?
List. Puoi avere oggetti di tipi che discendono da List, come ArrayListe LinkedList. (È importante usarli al Listposto di ArrayListquando li si passa in giro, ma non cambia il fatto che non si possa dire new List().)
Una cosa che mi manca in C # di Java è la gestione forzata delle eccezioni controllate. In C # è molto comune che non si sia a conoscenza delle eccezioni che un metodo può generare e che si sia in balia della documentazione o dei test per scoprirle. Non così in Java con eccezioni controllate.
Java ha l'autoboxing per le primitive piuttosto che per i tipi di valore, quindi sebbene System.Int32[]sia un array di valori in C #, Integer[]è un array di riferimenti a Integeroggetti e come tale non è adatto per calcoli con prestazioni più elevate.
Nessun delegato o evento: devi usare le interfacce. Fortunatamente, puoi creare classi e implementazioni dell'interfaccia inline, quindi non è un grosso problema
x => x.Foovs. new Bar() { public void M(SomeType x) { return x.Foo; } }- a chi importa che il codice sia 10 volte più breve?
La funzionalità data / calendario incorporata in Java è orribile rispetto a System.DateTime. Ci sono molte informazioni su questo qui: Cosa c'è di sbagliato con Java Date & Time API?
Alcuni di questi possono essere trucchi per uno sviluppatore C #:
Inoltre, Java non ha tutte le stesse funzionalità offerte dalla GAC e dagli assembly con nomi forti. Jar Hell è il termine per ciò che può andare storto quando si collega / si fa riferimento a librerie esterne.
Per quanto riguarda il packaging / la distribuzione:
Una cosa che salta fuori b / c è nella mia lista di interviste è che non c'è una parola chiave analoga "nuova" in Java per nascondere il metodo e quindi nessun avvertimento del compilatore "dovresti mettere nuovo qui". Il metodo accidentale che si nasconde quando si intendeva sovrascrivere porta a bug.
(modifica ad esempio) Esempio, B deriva da A (usando la sintassi C #, Java si comporta allo stesso modo in cui ho controllato l'ultima volta ma non emette un avviso del compilatore). Viene chiamato foo di A o foo di B? (A viene chiamato, probabilmente sorprendendo lo sviluppatore che ha implementato B).
class A
{
public void foo() {code}
}
class B:A
{
public void foo() {code}
}
void SomeMethod()
{
A a = new B(); // variable's type is declared as A, but assigned to an object of B.
a.foo();
}
newmetodo per nascondere intenzionalmente, o non finali, quindi sovrascritti piuttosto che nascosti.
Java non ha LINQ e la documentazione è un inferno. Le interfacce utente in Java sono un problema da sviluppare, perdi tutte le cose buone che Microsoft ci ha dato (WPF, WCF, ecc ...) ma diventi "API" difficili da usare e poco documentate.
L'unico problema che ho riscontrato finora quando lavoro con Java proveniente da C # è che le eccezioni e gli errori sono diversi.
Ad esempio, non è possibile rilevare un errore di memoria insufficiente utilizzando catch (eccezione e).
Vedere quanto segue per maggiori dettagli:
È passato così tanto tempo da quando sono stato in Java, ma le cose che ho notato subito nello sviluppo di applicazioni sono state il modello di eventi C #, il trascinamento della selezione C # rispetto all'utilizzo di Gestori layout in Swing (se stai facendo lo sviluppo di app) e la gestione delle eccezioni con Java assicurandosi di catturare un'eccezione e C # non richiesto.
In risposta alla tua domanda molto diretta nel titolo:
"Sviluppatori C # che imparano Java, quali sono le differenze maggiori che si possono trascurare?"
R: Il fatto che Java sia notevolmente più lento su Windows.