Pour les développeurs c # qui cherchent à apprendre Java, existe-t-il de grandes différences sous-jacentes entre les deux langages à signaler?
Peut-être que certaines personnes peuvent supposer que les choses sont les mêmes, mais il y a certains aspects de l'importation qui ne devraient pas être négligés? (ou vous pouvez vraiment foutre en l'air!)
Peut-être en termes de constructions POO, de fonctionnement de GC, de références, de déploiement, etc.
Réponses:
Quelques échappées au sommet de ma tête:
byte est signé en Java (malheureusement)staticil aura une référence implicite à une instance de la classe contenant.voici une comparaison très complète des 2 langues:
http://www.25hoursaday.com/CsharpVsJava.html
Ajouté: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp
Je suis surpris que personne n'ait mentionné des propriétés, quelque chose d'assez fondamental en C # mais absent en Java. C # 3 et les versions ultérieures ont également implémenté automatiquement des propriétés. En Java, vous devez utiliser des méthodes de type GetX / SetX.
Une autre différence évidente est l'absence d'expressions LINQ et lambda en C # 3 en Java.
Il y a quelques autres choses simples mais utiles qui manquent à Java comme les chaînes verbatim (@ ""), la surcharge d'opérateurs, les itérateurs utilisant yield et le pré-processeur sont également absents de Java.
L'un de mes favoris personnels en C # est que les noms d'espaces de noms n'ont pas à suivre la structure de répertoires physique. J'aime vraiment cette flexibilité.
Il y a beaucoup de différences, mais celles-ci me viennent à l'esprit:
.equalsest ce que vous devez utiliser.
.NET a réifié les génériques; Java a effacé les génériques.
La différence est la suivante: si vous avez un ArrayList<String>objet, en .NET, vous pouvez dire (à l'exécution) que l'objet est de type ArrayList<String>, alors qu'en Java, à l'exécution, l'objet est de type ArrayList; la Stringpièce est perdue. Si vous mettez des non- Stringobjets dans le ArrayList, le système ne peut pas appliquer cela, et vous ne le saurez qu'après avoir essayé d'extraire l'élément, et la distribution échoue.
Stringobjets dans cette liste sans faire un cast non vérifié, quelque part , et le compilateur vous avertira correctement à ce stade que le compilateur ne peut plus vérifier les limites génériques. Tant que votre liste est toujours stockée dans une variable de List<String>, les tentatives pour y insérer un objet non String ne seront pas compilées.
addméthode (encore une fois, par réflexion). Le système rejettera-t-il un non- Stringobjet tout de suite, ou seulement lors de la diffusion du résultat de get?
List. Vous pouvez avoir des objets de types descendant de List, comme ArrayListet LinkedList. (Il est important de les utiliser Listau lieu de ArrayListles faire circuler, mais cela ne change pas le fait que vous ne pouvez pas dire new List().)
Une chose qui me manque dans C # de Java est la gestion forcée des exceptions vérifiées. En C #, il est bien trop courant que l'on ignore les exceptions qu'une méthode peut lancer et que vous êtes à la merci de la documentation ou des tests pour les découvrir. Ce n'est pas le cas en Java avec des exceptions vérifiées.
Java a une autoboxing pour les primitives plutôt que pour les types valeur, donc bien qu'il s'agisse d' System.Int32[]un tableau de valeurs en C #, il Integer[]s'agit d'un tableau de références à des Integerobjets et, en tant que tel, ne convient pas aux calculs de performances plus élevées.
Pas de délégués ni d'événements - vous devez utiliser des interfaces. Heureusement, vous pouvez créer des classes et des implémentations d'interface en ligne, donc ce n'est pas si grave
x => x.Foovs new Bar() { public void M(SomeType x) { return x.Foo; } }- qui se soucie que le code soit 10 fois plus court?
La fonctionnalité de date / calendrier intégrée à Java est horrible par rapport à System.DateTime. Il y a beaucoup d'informations à ce sujet ici: Quel est le problème avec l'API Java Date & Time?
Certains d'entre eux peuvent être récupérés pour un développeur C #:
De plus, Java n'a pas toutes les mêmes fonctionnalités que le GAC et les assemblys fortement nommés. Jar Hell est le terme pour désigner ce qui peut mal tourner lors de la liaison / du référencement de bibliothèques externes.
En ce qui concerne le packaging / déploiement:
Une chose qui saute aux yeux car c'est sur ma liste d'interview est qu'il n'y a pas de "nouveau" mot-clé analogique en Java pour le masquage de méthode et donc aucun avertissement du compilateur "vous devriez en mettre nouveau ici". Une méthode accidentelle qui se cache lorsque vous avez l'intention de remplacer entraîne des bogues.
(modifier par exemple) Exemple, B dérive de A (en utilisant la syntaxe C #, Java se comporte de la même manière que j'ai vérifié la dernière fois mais n'émet pas d'avertissement du compilateur). Le toto de A est-il appelé ou le toto de B? (A est appelé, surprenant probablement le développeur qui a implémenté 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();
}
newméthode à cacher intentionnellement - ou non finaux donc remplacés plutôt que cachés.
Java n'a pas LINQ et la documentation est un enfer. Les interfaces utilisateur en Java sont difficiles à développer, vous perdez toutes les bonnes choses que Microsoft nous a données (WPF, WCF, etc ...) mais vous devenez des "API" difficiles à utiliser et à peine documentées.
Le seul problème que j'ai rencontré jusqu'à présent lorsque je travaille avec Java provenant de C # est que les exceptions et les erreurs sont différentes.
Par exemple, vous ne pouvez pas détecter une erreur de mémoire insuffisante en utilisant catch (Exception e).
Voir ce qui suit pour plus de détails:
pourquoi-java-lang-outofmemoryerror-java-heap-space-not-catch
Cela fait si longtemps que je ne suis pas en Java, mais les choses que j'ai remarquées dès le départ dans le développement d'applications étaient le modèle d'événement C #, le glisser-déposer C # vs l'utilisation des gestionnaires de mise en page dans Swing (si vous faites du développement d'applications) et la gestion des exceptions avec Java en s'assurant que vous interceptez une exception et que C # n'est pas requis.
En réponse à votre question très directe dans votre titre:
«Les développeurs C # apprenant Java, quelles sont les plus grandes différences que l'on peut ignorer?
R: Le fait que Java soit considérablement plus lent sous Windows.