Discussion :

[M_Makia]

Bonjour à toutes et tous.

Pour vous mettre dans le contexte, je suis développeur .Net depuis bientôt 10 ans et pour des raisons professionnelles je me dirige actuellement vers le langage JAVA pour acquérir la double compétence.

Je souhaiterais savoir si l'un d'entre vous est déjà passé du .Net à Java .
Quelles sont les difficultés et facilités que vous pu rencontrer ?
Avec quelle techno êtes vous le plus à l'aise ? et pourquoi ?
Pour vous, quels sont les points forts de JAVA et de .Net ainsi que leurs faiblesses respectives ?

Ce topic s'adresse principalement aux personnes ayant de solides connaissances en Java et .Net cependant tous commentaires constructifs m’intéresse !

je vous remercie.

[junior222]

Bonjour à toutes et tous.

Pour vous mettre dans le contexte, je suis développeur .Net depuis bientôt 10 ans et pour des raisons professionnelles je me dirige actuellement vers le langage JAVA pour acquérir la double compétence.

Je souhaiterais savoir si l'un d'entre vous est déjà passé du .Net à Java .
Quelles sont les difficultés et facilités que vous pu rencontrer ?
Avec quelle techno êtes vous le plus à l'aise ? et pourquoi ?
Pour vous, quels sont les points forts de JAVA et de .Net ainsi que leurs faiblesses respectives ?

Ce topic s'adresse principalement aux personnes ayant de solides connaissances en Java et .Net cependant tous commentaires constructifs m’intéresse !

je vous remercie.

Moi je ne suis pas un développeur .Net mais je connais java et tout dépens de ce que tu compte faire (développement des applications standalone, web, etc) mais ce qui est bien avec java c'est que tous les jours des bibliothèques sont développées pour faciliter et augmenter la performance du langage

[M_Makia]

Moi je ne suis pas un développeur .Net mais je connais java et tout dépens de ce que tu compte faire (développement des applications standalone, web, etc) mais ce qui est bien avec java c'est que tous les jours des bibliothèques sont développées pour faciliter et augmenter la performance du langage

Je vais principalement faire du développement Web.
Concernant la multitude de bibliothèques, je comprends que ça aide, mais pour un cadre professionnel comment savoir si une bibliothèque ou Framework va être maintenu dans le temps ?

[nathieb]

Bonjour,

Je connais bien Java mais peu .Net.
C'est deux mondes différents, mais si tu es expert en .NET je en vois pas de pb à l'apprentissage de JAVA.
Seul bémol, si tu était habitué à utulisé ton IDE sans modification de fond. Il existe en Java plusieurs façon d'aborder le build.
à la mano, façon C (au début)
Ant build genre make
Maven, plutôt déclaratif.

le dernier étant le point fort de Java. ce qui fait qu'il faut ausi apprendre un outil de build.
Pour ce qui est architecture, le + complexe est l'architecture JEE, avec l'utilisation des EJB, mais avec les dernières spéfications,
cela devient un "jeu d'enfant".
Après tout dépend, du niveau et des besoins, mais ce n'est qu'un langage de plus.

Pour ce qui est des bibliothèques, et de la perenité, je dirais que c'est un peu comme l'open source.
Il faut avoir le nez fin, programmer en ulisant des designs patterns (discours académique)
Tu ne seras pas à l'abri d'un changement mais c'est aussi vrai, voir pire dans le monde windows
ou à chaque version les choses changent. Cela fait parti des règles de notre métier.

Olivier

[Robin56]

Bonjour,

Je suis un profil Java mais par le passé j'ai fais du .NET sur quelques projets (C# ou VB.NET). Je n'affirme aucunement avoir de bonnes compétences en .NET mais je vais tenter tout de même de donner mon point de vue là dessus.

Quelles sont les difficultés et facilités que vous pu rencontrer ?

Disons que les difficultés de l'un sont les forces de l'autre pour moi. Autant, pour les langages en eux-même, on retombe totalement sur nos pieds car les mécaniques voir la syntaxe sont les mêmes. Leur différence est, pour moi, au niveau de leur écosystème.

Pour Java, sa force est son environnement truffé de framework, d'outils, de librairies en tout genre qui permet de toujours trouver une solution à son problème. Ça peut aussi se transformer en une faiblesse parfois car comme tu dis comment savoir quelle librairie sera maintenue ? ou comment savoir si on ne s'engouffre pas dans une solution complexe alors qu'il existe une solution plus simple ailleurs, etc..

Pour .NET, j'ai trouvé que sa force était sa cohérence dans son environnement. Je n'ai pas fais de développement web en .NET, juste du développement d'application lourde (VSTO,WPF, ..). Pas besoin là d'utiliser pleins de librairies, quand on développe pour du Microsoft, tout est là de base. Par contre quand on veut sortir des sentiers battus, là ça devient galère (enfin c'est mon expérience personnelle).

Avec quelle techno êtes vous le plus à l'aise ? et pourquoi ?

Du coup si je résume, j'ai apprécié .NET pour le fait que ce soit assez cadré mais je préfère Java pour sa liberté.

[M_Makia]

Merci pour vos réponses !
Je viens viens de commencer une formation JAVA et je dois dire que le passage .Net => Java ce fait plutôt facilement .
Cependant j'ai le sentiment que le langage Java à un "retard" significatif.
- Pas de type anonyme
- Pas de méthode anonyme
- Des génériques qui n'en sont pas
- Pas de surcharge d'opérateur
- Pas de type dynamique
- Pas de partial class
- Les expressions Lambda et les streams (équivalent de LINQ) qui n'arrivent que très tardivement
- Pas de delegate
- Pas de paramètres nommés et optionnels pour les méthodes
- Une nouvelle API date qui arrive tardivement

J'ai l'impression que le cycle de développement du langage java est assez long, quel sont vos points de vue ?

Du coup si je résume, j'ai apprécié .NET pour le fait que ce soit assez cadré mais je préfère Java pour sa liberté

Peux-tu développez pourquoi tu as plus de liberté avec Java ?

[Uther]

- Pas de méthode anonyme
- Pas de delegate

Les lambda qui permettent de réaliser l'équivalent sont arrivées dans Java 8.

- Pas de surcharge d'opérateur
- Pas de type anonyme
- Pas de type dynamique
- Pas de partial class

C'est une question de point de vue, pour moi c'est un avantage. Ces fonctionnalités sont tout a fait dispensables et je trouve qu'elles nuisent vraiment a la lisibilité, compréhensibilité ou à la facilité de navigation dans le code.

- Les expressions Lambda et les streams (équivalent de LINQ) qui n'arrivent que très tardivement
- Une nouvelle API date qui arrive tardivement

Sur ces points là je suis on le peu plus d'accord, ces fonctionnalités manquaient vraiment.

J'ai l'impression que le cycle de développement du langage java est assez long, quel sont vos points de vue ?

C'est vrai que Java évolue plus lentement, notamment parce qu’il a un processus de normalisation plus strict et qu'il est très regardant vis a vis de la compatibilité (c'est la notamment la raison pour laquelle les génériques ne sont pas réifiés et que paramètres nommés n'arriveront probablement jamais)

[adiGuba]

Salut,

Juste pour compléter les propos d'Uther :

- Pas de type dynamique
Java 7 comporte tout ce qu'il faut pour faire cela simplement et efficacement avec l'instruction du bytecode invokedynamic.
Mais c'est avant tout destiné aux langages dynamiques. Cela n'a pas été souhaité dans le langage Java (pourquoi vouloir écrire un code non-sécurisé ?)


- Pas de delegate
Les interfaces fonctionnelles de Java 8 sont l'équivalent des delegates.


- Des génériques qui n'en sont pas
A l'usage les différences sont quand même minimes.
A noter que les Generics de Java possèdent une covariance/contravariance plus aboutie, et permettent une retrocompatibilitée du code.


- Pas de paramètres nommés et optionnels pour les méthodes
C'est sûrement très pratique dans un projet, mais cela peut devenir casse-gueule dans une librairie.
La moindre modification d'une méthode utilisant paramètres nommés et/ou optionnels peut engendrer des incompatibilités !!!

J'ai l'impression que le cycle de développement du langage java est assez long, quel sont vos points de vue ?

Il est surtout une approche "industrielle", encadré par plusieurs entités, où toutes les modifications sont analysés et discutés...
Il en résulte une évolution plus lente, mais souvent bien maitrisée et adaptée (les Generics rétrocompatible, les enum qui ne sont pas de simple int, les interfaces fonctionnelles en tant que "type-fonction", les méthodes par défaut qui sont de vrai méthodes virtuelles, ...)


A l'inverse C# et son évolution "rapide" semble vorace en fonctionnalités, même si cela risque de compliqué le langage ou d'apporter de l'ambiguité...

a++

[M_Makia]

- Pas de méthode anonyme
- Pas de delegate

Les lambda qui permettent de réaliser l'équivalent sont arrivées dans Java 8.

Effectivement, cette fonctionnalité arrive également tardivement

- Pas de surcharge d'opérateur
- Pas de type anonyme
- Pas de type dynamique
- Pas de partial class

C'est une question de point de vue, pour moi c'est un avantage. Ces fonctionnalités sont tout a fait dispensables et je trouve qu'elles nuisent vraiment a la lisibilité, compréhensibilité ou à la facilité de navigation dans le code.

Je suis d'accord sur le fait que ces fonctionnalités ne soient pas indispensables.
Cependant je ne trouve pas qu'elles nuisent à qualité du code de façon général, mais je te rejoins sur le fait que cela peut poser des problèmes, en particulier lorsque c'est utilisé par des personnes peu expérimentées .
Comme tout outil, il faut savoir l'utiliser correctement et ne pas en abuser.
Pour moi ces fonctionnalités répondent le plus souvent à des besoins spécifiques et font gagner un temps et un nombre de lignes de code non négligeable.

- Pas de type dynamique
Java 7 comporte tout ce qu'il faut pour faire cela simplement et efficacement avec l'instruction du bytecode invokedynamic.
Mais c'est avant tout destiné aux langages dynamiques. Cela n'a pas été souhaité dans le langage Java (pourquoi vouloir écrire un code non-sécurisé ?)

Surtout utilisé pour l'interopérabilité avec les langages dynamique, IronPython, IronRuby, mais aussi utilisé dans certain cas particulier en C#.

- Des génériques qui n'en sont pas
A l'usage les différences sont quand même minimes.
A noter que les Generics de Java possèdent une covariance/contravariance plus aboutie, et permettent une rétrocompatibilité du code.

Architectes JAVA, formateur, développeurs sénior m'ont tous dit que les génériques posés problèmes du fait que le compilateur supprime le type du générique pour le remplacer par le type Object ,justement pour garder la rétrocompatibilité.
Cette méthode peut poser des problèmes de performances ainsi que des soucis pour faire de la réflexion.
Ils estiment que cette technique est trainé par java depuis trop d'années et que maintenant c'est plus un désavantage qu'un avantage

[adiGuba]

Architectes JAVA, formateur, développeurs sénior m'ont tous dit que les génériques posés problèmes du fait que le compilateur supprime le type du générique pour le remplacer par le type Object ,justement pour garder la rétrocompatibilité.
Cette méthode peut poser des problèmes de performances ainsi que des soucis pour faire de la réflexion.
Ils estiment que cette technique est trainé par java depuis trop d'années et que maintenant c'est plus un désavantage qu'un avantage

Des problèmes de performances ??? Franchement la différence doit être vraiment minime !
Je n'ai jamais rencontré de problème de performances liés aux Generics. Ce genre de problème vient plutôt des algorithmes...

Et franchement ce serait comme se plaindre de la surcharge mémoire impliqué par la duplication de code des Generics de C# !!!



Il y a bien quelques désavantages, dont le fait de ne pas pouvoir connaitre le type exact si on ne le stocke pas explicitement.
Mais franchement cela m'a toujours fait sourire de voir autant de gens crier au loup là dessus.



a++

[Uther]

Je suis d'accord sur le fait que ces fonctionnalités ne soient pas indispensables.
Cependant je ne trouve pas qu'elles nuisent à qualité du code de façon général, mais je te rejoins sur le fait que cela peut poser des problèmes, en particulier lorsque c'est utilisé par des personnes peu expérimentées .

L'utilité d'une fonctionnalité dépend du rapport entre le gain et le risque qu'elle apporte. Et chaque personne a une vision personnelle de la chose.
Je voulais juste dire que si ces fonctionnalités ne sont pas implémentées, ce n'est pas un retard de Java qui peinerait a les implémenter, mais un choix délibéré car le rapport intérêt/inconvénient n'a pas semblé assez bon à Sun/Oracle.

Des problèmes de performances ??? Franchement la différence doit être vraiment minime !

Je pense qu'en général il n'y a pas trop de problème de performance, sauf si on veux travailler avec des types primitifs car ils devront subir le Boxing/UnBoxing et dans certain cas ça peut être un vrai problème.

[M_Makia]

Merci à vous pour ces compléments d'informations et vos points de vues sur le sujet !

[Iradrille]

Hello,

Une différence qui n'a pas été citée : les struct n'existent pas en Java. Les Values Types (qui seront plus ou moins équivalents) sont en discussion et devraient arriver d'ici quelques mois / années.

[M_Makia]

Hello,
Une différence qui n'a pas été citée : les struct n'existent pas en Java. Les Values Types (qui seront plus ou moins équivalents) sont en discussion et devraient arriver d'ici quelques mois / années.

Effectivement, principalement utilisé pour des questions de performances.
En ce qui me concerne, je n'utilise quasiment jamais les struct.