Discussion :

[_skip]

On peut peut être aussi parler de closures ou de ce qui se rapproche des pointeurs de fonctions, les extensions methods, la surcharge d'opérateurs. Mais soit pour moi ce sont des choses nice to have mais pas fondamentalement nécessaires.

ou si c'est uniquement du sucre syntaxique pour soulager les petits doigts de ceux qui codent dans un simple éditeur de texte (si, si, il en existe encore ... j'aurai bien dit vi mais c# et vi, j'y crois pas trop )

Alors là mon point de vue est très différent du tien (et je suis pas en train de dire que t'as tort rassure-toi). La qualité d'un langage dans mon sens est aussi sa capacité à éliminer ce que nos amis anglophones appellent "boilerplates", c'est à dire le code chiant et répétitif.

Quelque chose comme les properties en C# qui remplace les méthodes getters/setters java pour moi c'est important. Bien sûr qu'avec n'importe quel EDI digne de ce nom tu peux les générer, cependant je trouve que ça alourdit considérablement la lecture lorsque tu as 20 propriétés puis 40 getter/setters. Puis c'est ça en plus à documenter.

C'est rien pour toi, beaucoup pour moi.

[millie]

Puis c'est ça en plus à documenter.

En général, ça se documente pas un getter/setter (sauf en cas d'effet de bord), sinon ça sert pas à grand chose

[_skip]

En général, ça se documente pas un getter/setter (sauf en cas d'effet de bord), sinon ça sert pas à grand chose

Alors l'utilisateur de la classe n'a aucune info sur l'utilité de la propriété, je pense pas que ce soit acceptable pour tout le monde... Surtout si tu génères une documentation ensuite ça fait très brouillon.

[Tommy31]

Alors l'utilisateur de la classe n'a aucune info sur l'utilité de la propriété, je pense pas que ce soit acceptable pour tout le monde... Surtout si tu génères une documentation ensuite ça fait très brouillon.

Tu commente la propriété. (à condition de produire la doc des éléments privés)

[_skip]

C'est quand même plus sympa de documenter une fois pour toute une propriété que le getter avec sa @return value, et le setter avec son @param.

En plus d'un point de vue strictement subjectif, je préfère écrire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bill.Total = order.SubTotal + order.Country.ShippingCost + order.Tva;

que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bill.setTotal ( order.getSubTotal() + order.getCountry().getShippingCost() + order.getTva() );

En fait j'étais pour les properties dans java 7, si ça avait été sans cet opérateur -> (flèche à la noix du c++). Je trouve que ces getter/setter c'est souvent beaucoup de code superflu.

[Keihilin]

Ce serait bien d'être factuel pour la peine

S'agissant de la rapidité d'évolution, il suffit de regarder la roadmap de .Net pour avoir un élément factuel.

En ce qui concerne le fait que c'est maintenant Java qui obsèrve partiellement .Net :

JDK7 - Prop 12

JDK7 - Prop 5

JDK7 - Prop 11

Bref...Je ne vais pas toutes les lister, mais il s'agit quand même d'un bel échantillon de fonctionnalités existantes en .Net.

Et le temps que cela soit discuté, voté et implémenté, .Net aura encore une longueur d'avance avec la version 4...

Je ne critique pas la démarche de la communauté Java, mais de mon point de vu, cette façon concertée d'évoluer est quand même un sacré frein et cela n'évite en rien les mécontents (sauf à voir des votes unanimes à 100%)...

Bref, avec Java maintenant aux mains d'Oracle (qui rappellons-le n'a pas plus de vocation philanthropique que MS), que resterait-il à Java comme avantages si Microsoft décidait une bonne fois pour toute de fournir une CLR pour chaque système ?

[Jedai]

Je ne critique pas la démarche de la communauté Java, mais de mon point de vu, cette façon concertée d'évoluer est quand même un sacré frein et cela n'évite en rien les mécontents (sauf à voir des votes unanimes à 100%)...

Certains te diront qu'ils préfèrent nettement une évolution plus lente et concertée, qui observe les langages "en avance" et exploite leurs réussites sans les inconvénients d'un pionnier... Note que ce n'est pas forcément mon avis (entre autres je trouve vraiment ridicule qu'il n'y ait toujours pas de closures en Java) mais c'est un point de vue qui se défend tout à fait, surtout pour un langage installé comme Java.

Bref, avec Java maintenant aux mains d'Oracle (qui rappellons-le n'a pas plus de vocation philanthropique que MS), que resterait-il à Java comme avantages si Microsoft décidait une bonne fois pour toute de fournir une CLR pour chaque système ?

Je propose qu'on fasse abstraction de ta question purement hypothétique (tu crois vraiment que MS va bientôt fournir une version complète de sa CLR et ses API .Net pour Linux ?). Par ailleurs Java est aux mains d'Oracle certes, mais le langage lui-même a été complètement ouvert par Sun, s'il y avait un trop gros désaccord entre la communauté et Oracle, il y aurait toujours une issue.

--
Jedaï

[adiGuba]

En ce qui concerne le fait que c'est maintenant Java qui obsèrve partiellement .Net :

JDK7 - Prop 12

JDK7 - Prop 5

JDK7 - Prop 11

Bref...Je ne vais pas toutes les lister, mais il s'agit quand même d'un bel échantillon de fonctionnalités existantes en .Net.

Pas de bol il y a peu de chance que cela soit introduit dans Java 7

De même ce n'est pas vraiment de nouvelle notion ou de révolution, mais des éléments qui existent déjà dans plusieurs langages.
C'est normal que leurs intégrations soit envisagé...

Et le temps que cela soit discuté, voté et implémenté, .Net aura encore une longueur d'avance avec la version 4...

Oui surement. Et on a là toute la différence philosophique entre Java et .NET.
L'évolution de Java est lente car soumise à un processus commun entre plusieurs acteurs, là où Microsoft multiplie les fonctionnalitées plus ou moins utile dans .NET...
Java a un coté plus "industriel", moins enclin à l'évolution pour un oui ou pour un non...


Ce qui m'a impressionné dans C# c'est le nombre de mot-clef et d'éléments du langage.
Bien sûr certain concept sont vraiment intéressant ou utile (les properties justement, les expressions lambda, LINQ), mais je trouve qu'il y a beaucoup d'élément ultra-spécifique qui complexifie le langage pour pas grand chose (diverses déclarations de classes anonymes, types anonymes, mot-clef yield).

Or plus le langage est complexe, plus on aura du mal à le maitriser...

Bref, avec Java maintenant aux mains d'Oracle (qui rappellons-le n'a pas plus de vocation philanthropique que MS), que resterait-il à Java comme avantages si Microsoft décidait une bonne fois pour toute de fournir une CLR pour chaque système ?

Pourquoi ? Sun était philanthropique ???

Quand au coté multiplateforme de Java, ce n'est pas vraiment son plus gros point fort puisqu'il est surtout utilisé coté serveur.
Son gros point fort vient de son langage simple, de ses APIs déjà conséquente et de la quantité et la qualité des librairies externes (d'ailleurs de nombreuses librairies se sont logiquement retrouvé porté sur .NET), mais également de l'existant.

Tu crois vraiment que si demain Microsoft fournissait un CLR pour chaque système, tout le monde abandonnerait Java ???


a++

[Keihilin]

Vous me faites rire avec votre histoire de portabilité. On n'en à rien à foutre d'autant plus pour les entreprises qui ont opté pour une stratégie tout MS. La portabilité c'est pour ceux qui veulent ramasser des parts de marché un peu à droite et à gauche et qui espère remplacer MS par du *nux et pour certains industriels/scientifiques qui utilisent des os que MS ne peut pas fournir

Non, tu t'en fous, d'autres aussi, mais on s'en fout pas.

+1

Mais il convient quand même de pondérer un peu ce qui est souvent présenté comme un IMMENSE avantage.

Au niveau d'une entreprise, intégrer un serveur Microsoft dans un parc majoritairement *nux n'est pas vraiment un problème, l'inverse non plus.
De ce fait, et avec la mode des interfaces web, la portabilité devient vraiment une problématique accessoire dans une majorité des cas.

Après, pour des applications non-web destinées à être distribuées, il est clair que la portabilité est importante; pouvoir cibler Windows, Mac, Linux et la plupart des OS sur téléphones portables est indéniablement un plus.

[millie]

Au niveau d'une entreprise, intégrer un serveur Microsoft dans un parc majoritairement *nux n'est pas vraiment un problème, l'inverse non plus.
De ce fait, et avec la mode des interfaces web, la portabilité devient vraiment une problématique accessoire dans une majorité des cas.

Pourtant, dès que les serveurs sont sur AIX, Solaris, z/OS, Linux. Les postes clients développeur étant souvent sous Windows, il est possible de développer sous Windows, de packager puis de déployer sur n'importe lequels des serveurs.

Je connais pas grand monde qui développe directement sur de l'AIX par exemple

[Keihilin]

Pas de bol il y a peu de chance que cela soit introduit dans Java 7

De même ce n'est pas vraiment de nouvelle notion ou de révolution, mais des éléments qui existent déjà dans plusieurs langages.

Oui oui, mais justement tu remarqueras que je n'ai jamais dis que Java copiais, j'ai bien dit que Java observais.

Et même si ces fonctionnalités ne lui sont pas spécifiques, C# reste quand même le concurrent le plus direct, et donc celui qu'il faut tenir à l'oeil.

Accessoirement et puisque tu soulignes que ces fonctionnalités ne seront sans doute pas implémentées, je me demande si certains ne s'opposent pas systématiquement à une évolution simplement parce que ça existe en C#.

là où Microsoft multiplie les fonctionnalitées plus ou moins utile dans .NET...
Java a un coté plus "industriel", moins enclin à l'évolution pour un oui ou pour un non...

Or plus le langage est complexe, plus on aura du mal à le maitriser...

C'est effectivement le revers de la médaille. .Net évolue un peu trop rapidement et certaines décisions semblent plus tenir de l'esbrouffe marketing que de la pertinence technique.

Un certain nombre de nouvelles fonctionnalités sont à double tranchant; permettant un gain de productivité à celui qui maîtrise vraiment, mais conduisant le dilletante à produire une cochonnerie encore pire...

Pourquoi ? Sun était philanthropique ???

Pas du tout, mais Sun (grâce à Java sans doute) bénéficie d'une image "ouverte", un rien babacool...rien à voir avec l'image de mastodonte commercial d'Oracle.

Tu crois vraiment que si demain Microsoft fournissait un CLR pour chaque système, tout le monde abandonnerait Java ???

J'aimerais te répondre que non étant donné l'existant...mais il y a 20 ans on pensait la même chose du COBOL.

Imaginons un hypothétique scénario dans lequel .Net devient aussi portable que Java.
Si Java conserve son mode actuel d'évolution et se fait de plus en plus distancer, la machine marketing MS pourrait bien le marginaliser petit à petit...ou pas !

D'un point de vu plus réaliste, je pense que les deux mondes continueront à cohabiter, mais on ne sait jamais...

[adiGuba]

Accessoirement et puisque tu soulignes que ces fonctionnalités ne seront sans doute pas implémentées, je me demande si certains ne s'opposent pas systématiquement à une évolution simplement parce que ça existe en C#.

Peut-être... mais l'inverse doit aussi être vrai : certains proposent ces fonctionnalités car elles sont présente dans .NET/C# !

Mais mis à part un éventuel retour d'expérience de C# (ou tout autre langage), je ne pense pas que cela joue un rôle important dans la décision d'inclure ou non une fonctionnalité.

• Pour le typedef et les méthodes extensions, c'est les dangers de mauvaises utilisations qui ont été mis en avant, pour un gain somme toute assez réduit.
• Pour les properties, le problème vient du fait que cela change radicalement toute la logique des propriétés. Ce n'est pas évident de changer cela dans un langage existant avec autant de librairies sans que cela ne pose des problèmes... à moins d'utiliser du sucre syntaxique qui ferait perdre beaucoup d'intérêt à la chose
  Cela n'a pas été totalement abandonnés mais je ne le vois pas arriver pour Java 7...

Un certain nombre de nouvelles fonctionnalités sont à double tranchant; permettant un gain de productivité à celui qui maîtrise vraiment, mais conduisant le dilletante à produire une cochonnerie encore pire...

C'est généralement ce qu'on retrouve comme critique...
Or de ce point de vue là C# est quand même plus proche du C++, en proposant un maximum de choix et de possibilité, quitte à complexifier le langage.
L'approche de Java est radicalement différente car il y a une forte volonté de conserver un langage "simple"... même s'il a ses propres complexité !

J'aimerais te répondre que non étant donné l'existant...mais il y a 20 ans on pensait la même chose du COBOL.

Sauf que je ne vois pas vraiment .NET et C# comme une technologie de remplacement, mais plus comme une technologie concurrente...

COBOL c'est quand même un langage très particulier et assez verbeux

Imaginons un hypothétique scénario dans lequel .Net devient aussi portable que Java.
Si Java conserve son mode actuel d'évolution et se fait de plus en plus distancer, la machine marketing MS pourrait bien le marginaliser petit à petit...ou pas !

D'un point de vue marketing peut-être...
Mais il ne faut pas oublier l'existant et surtout le monde mobile qui explose et où Java est bien représenté.
De plus Java ce n'est pas uniquement Sun ou Oracle, mais un bon nombre compagnie plus ou moins lié au monde informatique : Apache, Google, IBM, HP, Intel...

a++

[toomsounet]

J'aimerais te répondre que non étant donné l'existant...mais il y a 20 ans on pensait la même chose du COBOL.

Imaginons un hypothétique scénario dans lequel .Net devient aussi portable que Java.
Si Java conserve son mode actuel d'évolution et se fait de plus en plus distancer, la machine marketing MS pourrait bien le marginaliser petit à petit...ou pas !

D'un point de vu plus réaliste, je pense que les deux mondes continueront à cohabiter, mais on ne sait jamais...

Je ne le crois pas,Cobol était un langage rendu obsolète sur bien des points qui a motivé son remplacement.

Tu crois sincèrement que les quelques fonctionnalités qu'on retrouve sur C# et pas Java justifieront une migration? Il faudrait vraiment un gap technologique, une productivité accrue ou un coût sensiblement plus faible...

[Keihilin]

Pour les properties, le problème vient du fait que cela change radicalement toute la logique des propriétés. Ce n'est pas évident de changer cela dans un langage existant avec autant de librairies sans que cela ne pose des problèmes... à moins d'utiliser du sucre syntaxique qui ferait perdre beaucoup d'intérêt à la chose
Cela n'a pas été totalement abandonnés mais je ne le vois pas arriver pour Java 7...

Ca c'est LE truc dont je n'arrive pas à comprendre le refus depuis x années !
De mon point de vu, c'est infiniment plus propre que ces damnés getters et setters explicites ! enfin bref...

Sauf que je ne vois pas vraiment .NET et C# comme une technologie de remplacement, mais plus comme une technologie concurrente...

COBOL c'est quand même un langage très particulier et assez verbeux

Tu crois sincèrement que les quelques fonctionnalités qu'on retrouve sur C# et pas Java justifieront une migration? Il faudrait vraiment un gap technologique, une productivité accrue ou un coût sensiblement plus faible...

Fondamentalement, je n'ai aucune certitude, je ne fais que des suppositions dans un contexte bien précis.

L'histoire de l'informatique nous apprend que l'évolution n'est pas toujours rationnelle, que ce n'est de loin pas toujours le meilleur qui s'impose et qu'une technologie aussi répandue soit-elle peut disparaître...

Entre les effets de mode et les discours marketing, les avis des décideurs au sein des entreprises (qui ne sont pas toujours des informaticiens mais qui prennent des décisions d'informaticiens) peuvent parfois changer de manière surprennante; or l'évolution rapide de C# et le "bling bling" qui l'accompagne pourrait lui permettre de passer l'épaule (toujours en supposant la même portabilité que Java).

[adiGuba]

Ca c'est LE truc dont je n'arrive pas à comprendre le refus depuis x années !
De mon point de vu, c'est infiniment plus propre que ces damnés getters et setters explicites ! enfin bref...

Oui je suis plutôt d'accord avec toi...
Toutefois ce n'est pas évident d'intégrer cela à l'existant...


La notion de getter/setter et de "beans" fait partie intégrante de Java depuis les toutes premières versions, et c'est ainsi massivement utilisé par les librairies tierces et l'API standard. Un grand nombre d'APIs existantes sont conçus pour fonctionner avec des getter/setter. En les remplaçant par des properties il faudra modifier toutes ces librairies et tout le code existant


De ce fait il y a trois grandes solutions :

• Intégrer des properties qui soient inutilisable par les librairies actuelles, ce qui n'est pas trop dans l'optique du monde Java...
• Intégrer cela via du sucre syntaxique, qui proposerait des fonctionnalitées similaires en générant implicitement les getter/setter. Ce qui n'est pas vraiment souhaitable car cela ne permettrait pas de couvrir l'ensemble des possibilités des properties.
• Enfin, mettre en place une solution qui permettrait à la fois d'utiliser des properties ET de conserver une compatibilité... ce qui n'est pas forcément évident à mettre en place.

On retrouve ce même genre de contrainte dans l'implémentation des Generics de Java...


Ce problème était moins présent en C# puisqu'il était plus "jeune", mais nul-doute que désormais les ingénieurs de Microsoft doivent se poser le même genre de question...


a++

[hegros]

Après, pour des applications non-web destinées à être distribuées, il est clair que la portabilité est importante; pouvoir cibler Windows, Mac, Linux et la plupart des OS sur téléphones portables est indéniablement un plus.

Désolé mais je ne peux m'empêcher de rire un bon coup lorsque vous parlez de portabilité en citant Windows, Mac, Linux, AIX, système osz et les mobiles comme choix c'est d'une pauvreté...et si cela représente l'ensemble du marché alors quelle pauvreté...


Vous me faîtes encore plus rire lorsque que vous pensez que votre programme tournera sur toutes les plateformes matérielles comme ça d'un coup de baguette de magique de système osz à du iphone.


Doux rêveurs les javaiste et dotnetiste...

[millie]

Vous me faîtes encore plus rire lorsque que vous pensez que votre programme tournera sur toutes les plateformes matérielles comme ça d'un coup de baguette de magique de système osz à du iphone.

Si on développe sur du z/OS, on utilise normalement le JDK d'IBM qui fait que l'application sera vraiment compatible uniquement sur les plateformes où il y a une version du JDK d'IBM : Windows, Linux, z/OS, AIX, Solaris.
Seul IBM garanti le fonctionnement d'une application développée avec son JDK entre ces plateformes.

Ca n'a pas de sens de porter une application z/OS (en général serveur) sous Iphone avec le JDK d'IBM (qui n'existe pas sous iphone).
Si on développe une application de type serveur, c'est pour le déployer sur un serveur. Et si on utilise les outils d'IBM, il vaut mieux le déployer avec un JDK d'IBM et le serveur d'application d'IBM (à moins de tout retester avec un autre JDK et un autre serveur d'application, mais ça marche pas forcement du premier coup).

[hegros]

Si on développe sur du z/OS, on utilise normalement le JDK d'IBM qui est compatible uniquement sur les plateformes où il y a une version du JDK d'IBM : Windows, Linux, z/OS, AIX, Solaris.

Ce qui est très pauvre en terme de nombre de plateforme logicielle en plus je parlais plus des plateformes matérielles parce qu'un logiciel sans matériel cela ne vaut pas un clou.

Ca n'a pas de sens de porter une application z/OS (en général serveur) sous Iphone avec le JDK d'IBM (qui n'existe pas sous iphone)

Si on développe une application de type serveur, c'est pour le déployer sur un serveur. Et si on utilise les outils d'IBM, il vaut mieux le déployer avec un JDK d'IBM et le serveur d'application d'IBM (à moins de tout retester avec un autre JDK et un autre serveur, mais ça marche pas forcement du premier coup).

Vu le nombre de fois que tu cites IBM avec le JDK on se demande vraiment comment cela peut-être un seul instant portable sur toutes les autres plateformes qui n'ont pas ce monstre de l'informatique comme fournisseur

[millie]

Les spécifications du JDK ont plusieurs implémentations (celle de Sun, d'IBM, HP et d'autres), qui peuvent éventuellement avoir certains bugs.
C'est pareil pour les serveurs d'applications Java EE.

Sun ne fournit pas de JDK pour z/OS, seul IBM le fait.
Mais IBM est le seul à "garantir" le fonctionnement d'une application sur tous ses JDK entre les différentes plateformes, c'est pour ça qu'il est important de rester avec leur JDK si on veut switcher entre z/OS, AIX etc.

Si on reste sur du Solaris/Linux/Windows, on peut prendre du Sun (normalement, ça déconne pas trop si on switche de plateformes, on peut se limiter à des tests minimale de compatibilités). Mais si on migre sur une plateforme avec un autre JDK, il est nécessaire de vraiment tout tester de fond en comble. Pas forcement juste à cause de la plateforme, mais surtout parce que l'on change d'implémentation de JDK (que ce soit le JDK d'HP ou d'IBM). Enfin, la migration peut se faire sans encombre.


J'ai jamais dit que le multiplateforme de Java était magique
Il faut suivre les recommandations des JDK qu'on utilise, il y a un périmètre à respecter. Mais normalement, le périmètre des applications pour mobiles n'interfère pas trop avec le périmètre des applications pour serveurs.

Je n'ai jamais fait de développement pour mobile, parait que la compatibilité, c'est pas la fête. Mais pour les serveurs, ça va plutôt pas mal. A moins d'utiliser des bibliothèques spéciales qui ne marchent que sur certaines plateformes ou serveur d'applications.

Ce qui est très pauvre en terme de nombre de plateforme logicielle

Côté serveur/PC ?
Il faut que ça touche combien de pourcentage des ventes de serveurs et PC pour que tu trouves que ce ne soit pas pauvre ?

[Keihilin]

[*]Enfin, mettre en place une solution qui permettrait à la fois d'utiliser des properties ET de conserver une compatibilité... ce qui n'est pas forcément évident à mettre en place.

Je sous-estime sans doute le problème, mais je ne vois pas en quoi implémenter les properties pourrait être bloquant pour l'existant dans la mesure ou les getter/setter ne sont que des fonctions et pourraient donc continuer à être utilisées ?

Libre aux développeurs d'API de migrer petit à petit...

Ce problème était moins présent en C# puisqu'il était plus "jeune", mais nul-doute que désormais les ingénieurs de Microsoft doivent se poser le même genre de question...

Pas encore.

Il faut savoir que lorsque le framework 1.0 est sorti, la roadmap jusqu'à la version 2.0 était déjà faite.
Anders Hejlsberg l'avait dit dans une interview; s'il avait eu quelques mois de plus à disposition, nous aurions eu directement en 1.0 90% des fonctionnalités du 2.0.

La 3.5 n'étant qu'une surcouche basée sur la 2.0, j'imagine que pour le moment il n'y a pas trop de points bloquants.

Accessoirement, Microsoft se pose nettement moins de question concernant la compatibilité avec les outils/api tiers. Les différentes versions du framework pouvant tourner en parallèle, migrer est un choix, pas une obligation.