Un article de LaPageDuJour.

Sommaire 1 Les idées associées 1.1 Les Mac Fags 1.2 Les politiques d'entreprises 2 Histoire du .Net par rapport au Java 3 Dans la programmation 3.1 Les contraintes sur les fichiers 3.2 L'imposition du tout objet 3.3 L'absence de macros 3.4 Une non finition volontaire du Framework 3.5 L'absence d'évènements 3.6 Les méthodes anonymes 3.7 Les nomenclatures absurdes 3.8 Les environnements de développement

[modifier] Les idées associées

[modifier] Les Mac Fags

Souvent le .Net est utilisé par des gens très cool qui par ailleurs aiment bosser sur mac, se regroupent entre eux pour parler de leur logiciels Mac Os X ultra jolis se racontent des blagues sur Microsoft. Vous pouvez les reconnaître car ils ont un air important, parlent assez fort, ont des beaux ordinateurs tout blancs et ne font rien d'utile avec.

Ils sont couramment appelés les "Mac Fag". Contrairement aux idées reçues, ils ne se regroupent pas par paire, ils peuvent très bien être en groupe de 3/4/5.

N'abordez jamais de sujet qui les fâchent, la première chose qu'ils feraient serait de vous dénigrer en vous faisant comprendre que vous faites parti de l'axe du mal.

[modifier] Les politiques d'entreprises

Sun a une politique jusqu'à très récemment d'extrême fermeture vis à vis de leur technologie. Java est un environnement totalement fermé.

[modifier] Histoire du .Net par rapport au Java

Même si ce n'est clairement défini nul part, le .Net est une reprise complètement du Java. Les équipes qui ont repris le projet on cherché à faire un langage managé plus cohérent et plus fini.

[modifier] Dans la programmation

[modifier] Les contraintes sur les fichiers

Vous êtes obligé de fixer des contraintes sur les fichiers. Une seule public class par fichier et de surcroit du même nom que le fichier.

[modifier] L'imposition du tout objet

Rien ne peut être défini comme étant n'étant pas un objet. Ainsi un thread est un objet. Pourquoi ? Parce que Sun l'a décidé ainsi. Si vous avez une classe utilisant 5 threads, vous devrez faire 5 objets en conséquence.

[modifier] L'absence de macros

Les macros (et typiquement les #ifdef (DEBUG)) sont très pratiques pour réaliser plusieurs version d'un même code.

[modifier] Une non finition volontaire du Framework

Le framework java n'offre par tout volontairement. Pourquoi ? Parce que Sun l'a décidé ainsi. Vous ne pouvez ainsi pas accèder aux ports série à part en utilisant des librairies externes.

[modifier] L'absence d'évènements

Les évènements permettent dans les modèles objets d'inscrire des méthodes dans des piles de pointeur de méthodes pour pouvoir ensuite réaliser des appels dessus. En java, ça n'existe pas. On peut le faire autrement, mais c'est bien moins pratique et esthétique en terme de code.

[modifier] Les méthodes anonymes

En Java, l'utilisation des méthodes anonymes nécessite encore une fois de définir un objet dont redéfinira une méthode anonyme par la suite. Donc en gros, on crée, comme pour les threads, un objet pour n'en utiliser qu'une méthode.

[modifier] Les nomenclatures absurdes

Selon que vous ajoutez un évènement dans une Map ou dans une List, vous n'utiliserez pas le même nom de méthode. Les List utilisent add les Map utilisent put.

Pourquoi ? Il n'y a pas tellement de raison

[modifier] Les environnements de développement

Sun n'a jamais accepté que Microsoft réalise un IDE Java. Et on se demande bien pourquoi.

• Eclipse 3.3 n'est vraiment pas très pratique à utiliser. Notamment de par son fonctionnement en "Workspace" qui rend le partage de projets très complexe. Par ailleurs, il prend beaucoup de mémoire vive (mais il en fait un usage satisfaisant).
• NetBeans 6.0 est extrèmement lent mais sa gestion des fichiers de projets est bien plus cohérente.

Pour ces deux environnements, l'auto-complétion, l'équivalent de l'intellisense de Microsoft est à un niveau extrêmement faible. On perd beaucoup en productivité.