Développeurs C # apprenant Java, quelles sont les plus grandes différences que l'on peut négliger? [fermé]

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é les propriétés, quelque chose d'assez fondamental en C# mais absent en Java. C # 3 et au-dessus a automatiquement implémenté des propriétés aussi bien. En Java, vous devez utiliser des méthodes de type GetX/SetX.

Une autre différence évidente est les expressions LINQ et lambda en C# 3 absentes en Java.

Il manque quelques autres choses simples mais utiles à Java comme les chaînes verbatim ( @ "" ), la surcharge de l'opérateur, les itérateurs utilisant yield et le pré-processeur sont manquants en Java ainsi.

Un de mes favoris personnels en C# est que les noms d'espace de noms n'ont pas à suivre la structure de répertoire physique. J'aime vraiment cette flexibilité.

Il y a beaucoup de différences, mais celles-ci me viennent à l'esprit:

• Absence de surcharge de l'opérateur en Java. Surveillez votre instance.Equals(instance2) par rapport instance == instance2 (en particulier w/cordes).
• Habituez-vous aux interfaces QUI ne sont PAS préfixées par un I. Souvent, vous voyez des espaces de noms ou des classes suffixés avec Impl à la place.
• Le verrouillage à double vérification ne fonctionne pas à cause du modèle de mémoire Java.
• Vous pouvez importer des méthodes statiques sans les préfixer avec le nom de classe, ce qui est très utile dans certains cas (DSL).
• Les instructions Switch en Java ne nécessitent pas de valeur par défaut, et vous ne pouvez pas utiliser les chaînes comme étiquettes de casse (IIRC).
• Les génériques Java vous mettront en colère. Les génériques Java n'existent pas au moment de l'exécution (au moins en 1.5), ils sont une astuce du compilateur, ce qui pose des problèmes si vous souhaitez réfléchir aux types génériques.

. NET a réifié les génériques; Java a effacé les génériques.

, La différence est ceci: si vous avez une ArrayList<String> objet, dans .NET, vous pouvez dire (à l'exécution) d'un objet de type ArrayList<String>, alors qu'en Java, à l'exécution, l'objet est de type ArrayList; {le[3]} la partie est perdue. Si vous mettez des objets non-String dans le ArrayList, le système ne peut pas l'appliquer, et vous ne le saurez qu'après avoir essayé d'extraire l'élément, et la distribution échoue.

Une chose qui me manque en C# de Java est la gestion forcée des exceptions vérifiées. En C # est-il assez courant que l'on ne soit pas au courant des exceptions qu'une méthode peut lancer et que vous soyez à 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.

Pas de délégués ou 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

Java a autoboxing pour les primitives plutôt que les types de valeur, donc bien que System.Int32[] soit un tableau de valeurs en C#, Integer[] est un tableau de références à Integer objets, et en tant que tel ne convient pas pour des calculs de performances plus élevées.

La fonctionnalité de date/calendrier intégrée en Java est horrible par rapport au système.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 des gotchas pour un développeur C#:

• La classe Java Date est mutable, ce qui peut rendre les dates de retour et de passage dangereuses.
• La plupart des java.util.Les constructeurs de date sont obsolètes. Instancier simplement une date est assez verbeux.
• je n'ai jamais obtenu le java.util.Classe de date pour bien interopérer avec les services Web. Dans la plupart des cas, les dates de chaque côté ont été sauvagement transformées en une autre date et heure.

De plus, Java n'a pas toutes les mêmes fonctionnalités que les assemblys GAC et fortement nommés apportent. Jar Hell est le terme pour ce qui peut mal tourner lors de la liaison/du référencement de bibliothèques externes.

En ce qui concerne l'emballage/le déploiement:

• il peut être difficile à emballer up des applications Web dans un format EAR / WAR qui s'installent et s'exécutent sur plusieurs serveurs d'applications différents (Glassfish, Websphere, etc.).
• déployer votre application Java en tant que service Windows demande beaucoup plus d'efforts qu'en C#. La plupart des recommandations que j'ai reçues pour cela impliquaient une bibliothèque tierce non gratuite
• la configuration de l'application n'est pas aussi facile que d'inclure une application.fichier de configuration dans votre projet. Il y a un java.util.Classe de propriétés, mais elle n'est pas aussi robuste et trouve le bon endroit pour déposer vos .fichier de propriétés peut être source de confusion

Il n'y a pas de délégués en Java. Par conséquent, outre tous les avantages que les délégués apportent à la table, les événements fonctionnent également différemment. Au lieu de simplement brancher une méthode, vous devez implémenter une interface et l'attacher à la place.

Une chose qui saute b/c c'est sur ma liste d'interview est qu'il n'y a pas de "nouveau" analogue de mot-clé en Java pour le masquage de méthode et donc aucun avertissement du compilateur "vous devriez mettre du nouveau ici". La méthode accidentelle de masquage lorsque vous vouliez remplacer conduit à 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 la dernière fois que j'ai vérifié mais n'émet pas d'avertissement du compilateur). Un des foo appelés, ou B foo? (A est appelé, surprenant probablement le dev qui mise en œuvre 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();
}

Java n'a pas LINQ et la documentation est l'enfer. Les interfaces utilisateur en Java sont pénibles à développer, vous perdez toutes les bonnes choses que Microsoft nous a données (WPF, WCF, etc...) mais obtenir des "API"difficiles à utiliser et à peine documentées.

Le seul problème que j'ai rencontré jusqu'à présent en travaillant avec Java provenant de C# est les exceptions et les erreurs sont différentes.

Par exemple, vous ne pouvez pas détecter une erreur de mémoire insuffisante à l'aide de catch(Exception e).

Voir ce qui suit pour plus de détails:

Pourquoi est-java-lang-outofmemoryerror-java-tas-de l'espace-pas-pris

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 de gestionnaires de mise en page dans Swing (si votre développeur d'application fait), et la gestion des exceptions avec Java en

En réponse à votre question très directe dans votre titre:

"Développeurs C # apprenant Java, quelles sont les plus grandes différences que l'on peut négliger?"

A: Le fait que Java est considérablement plus lent sous Windows.

La différence la plus harrassante pour moi lorsque je passe à java, c'est la déclaration de chaîne.

En C# string (la plupart du temps) en Java String

C'est assez simple, mais croyez-moi, ça vous fait perdre beaucoup de temps lorsque vous avez l'habitude de s pas S !