Du côté des nouveautés du langage, on trouve : les types génériques, l'"autoboxing", la possibilité d'associer des métadonnées au code, une boucle du genre "foreach", l'import statique, les énumérations, des fonctions à nombre d'arguments variables, une lecture plus facile des données d'entrées, une nouvelle gestion de la synchronisation, et une génération d'interfaces RMI plus facile.
S'y ajoutent de nombreuses améliorations en termes de performances, de diagnostic et de disponibilité. Quelques détails sur les nouveautés du langage les plus saillantes :
- les types génériques correspondent aux "templates" de C++ : ainsi un vecteur de chaînes peut maintenant être écrit comme tel et non plus comme un vecteur d'objets quelconques dont il fallait transtyper les éléments à chaque utilisation...
- l'autoboxing permet la conversion implicite et automatique entre les types natifs et leurs homologues objets, par exemple entre "int" et "Integer"
- avec les métadonnées, on peut ajouter des balises au code, à destination du compilateur ou d'autres outils (par exemple pour la génération automatique de code)
- la boucle for permet maintenant de parcourir chaque élément d'une collection d'objets: for(Integer i : list) { ... }
- grâce à l'import statique, on peut éviter d'avoir à préfixer le nom de la classe d'une méthode statique à chaque utilisation. Par exemple, après un "import static java.lang.Math.cos;" on peut appeler directement la fonction cos()
- l'"enum" fonctionne comme en C
- les fonctions à nombre d'arguments variable...permettent d'implémenter printf()... ;-)
- il est plus facile de lire des données formatées sur un flux d'entrée
- le package java.util.concurrent fournit de nouveaux outils pour synchroniser des threads, par exemple des sémaphores
- il n'est plus nécessaire d'utiliser rmic pour la génération d'interfaces RMI.
D'autres nouveautés sont à découvrir : nouveau thème Ocean pour Swing, nouvelle version du support XML, gestion des caractères Unicode sur 32 bits...
Aller plus loin
- Page de J2SE 5.0 chez Sun (3 clics)
- J2SE 5.0 in a Nutshell (3 clics)
- J2SE 5.0 New Features and Enhancements (1 clic)
# Livre
Posté par Jean-Marc Spaggiari . Évalué à 3.
Si quelqu'un a une référence à proposer, elle est la bienvenue... Le seul que j'ai trouvé pas trop mal pour le moment et "Java how to program".... Mais à 100$CA, ca fait un peu beaucoup et il est trop généraliste...
JMS
[^] # Re: Livre
Posté par Flipo . Évalué à 7.
[^] # Re: Livre
Posté par Anomaly . Évalué à 3.
http://lroux.developpez.com/article/java/tiger/(...)
# révolutionnaire !
Posté par ploum (site web personnel, Mastodon) . Évalué à -2.
On a des trucs (comme en C++) et des machins (comme en C). En gros, on va maintenant presque pouvoir faire de la vraie programmation avec Java...
Ah non, juste, les utilisateurs n'auront pas la machine virtuelle adéquate...
Bon, ben on retourne faire du C, C++ et Python, je n'arrive toujours pas à voir l'intérêt de Java par rapport à ces 3 là
/me, qui a convoqué par avance l'huissier pour constater le record de moinssage dont il va être victime. De toutes façons, ce moinssage n'est rien par rapport avec ce que je vais endurer avec tous les projets en Java que je dois faire cette année...
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 9.
On peut faire de la vrauie programmation en Java.. en fait, je sais pas koi donner comme argument, il y a des softs en java dans tous les domaines, des jeux, des applications serveurs, des site webs, des applis pour PDA... bref..
Les ajouts étaient nécéssaires certes et certains viennent du C et du C++.. maintenant, on attend de voir combien de temps vont mettre C et C++ pour intégrer les bonnes choses de java.. comme la possibilité d'associer des métadonnées au code... on se reparle dans 10 ? ;)
Ah non, juste, les utilisateurs n'auront pas la machine virtuelle adéquate...
La je capte pas ?
Bon, ben on retourne faire du C, C++ et Python, je n'arrive toujours pas à voir l'intérêt de Java par rapport à ces 3 là
Chacun voit les avantages dont il a besoin...
moi je vois la simplicité, le support des leaders du marché, des api jdbc bien fouttues, un paquet de projets libre géniaux comme JOnAS, hibernate, tomcat, XMLBeans, AXis...
une API riche, la portabilité...
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par ckyl . Évalué à 9.
> La je capte pas ?
Bha comment je fais du java 5.0 sur mon linux ppc ou NetBSD ppc (j'ose pas mettre FreeBSD ppc par ce qu'il faudrait deja que ca tourne avant de lancer une usine a gaz :-) ?
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par ckyl . Évalué à 5.
Si le maximum de plateformes c'est 5 je glousse doucement.
TRAUMAT => tramo ? :-)
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 6.
Il n'y a pas que SUN qui fait des JVM :
http://www.geocities.com/marcoschmidt.geo/java-jdk-jre.html(...)
elles ne sont pas toutes des 5.0 mais laissez un peu de temps aux gens pour développer... je me permets de rappeller qu'il n'y a pas que sun qui fait des jvm
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par ufoot (site web personnel) . Évalué à 8.
Ceci dit il y a de belles initiatives. GCJ par exemple est carrément la piste à suivre je pense. Mais le moteur du langage a beau être propre et carré et tout ce que tu veux, tout ça est bien joli mais il faut aussi que les bibliothèques suivent, et GNU ClassPath c'est pas du petit projet qui va être terminé demain. L'enjeu de la portabilité ce n'est pas tant le moteur du langage que ses bibliothèques. Dans ce domaine encore un Perl ou un Python font un carton comparé à Java en terme de nombre de plate-formes supportées.
Alors certes "il sufffit d'attendre". Moi ça fait 7 ans qu'on me raconte que "bientôt une fois que les JVMs seront dispos sur toutes les plates-formes ça sera super ton programme Java il tournera sur n'importe quoi!". Ca commence à sentir le réchauffé et j'y crois plus...
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Il y a des JVM pour de nombreuses plateformes et je n'ai pas comparé avec perl.. c'est vrai.
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par ufoot (site web personnel) . Évalué à 4.
write once, run anywhere 8-)
Tu as 100% raison quand tu précise "vous allez ensuite pouvoir déployer sur n'importe quelle plateforme qui a une machine virtuelle...". Le problème est que l'argument "WORA" a été martelé assez longuement et sans trop d'explications sur les vrais détails techniques de la chose. Et là SUN - ou plutôt son service marketting - en sont totalement responsables. Ce sont eux qui ont mis en avant la portabilité à 100%. Evidemment que c'est le marketting qui a poussé ce message et qu'il est faux, car il y a ce petit "oui mais" en forme de "vous avez besoin d'une JVM ad hoc". Maintenant il y en a qui sont déçus parce qu'on leur a promis la lune et ils l'ont pas eue. C'est un juste retour de bâton dans les dents du marketting de SUN, fallait pas raconter n'importe quoi (et entre autres faire croire à coup de cravattes et costumes que le concept de VM était révolutionnaire alors que ça existait depuis des décennies...).
Ceci dit tu as raison il y a plein de JVMs pour de nombreuses plateformes, mais avec cette nouvelle version 1.5, toutes celles qui ne disposent que du 1.4 vont à nouveau être à la bourre, et on repart pour un cycle où seules celles officiellement supportées par SUN ou IBM seront à la page.
C'est dommage.
Ceci dit je ne désespère pas de me remettre à Java un jour, faut pas dramatiser 8-)
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Bien sur, il faut une JVM et je pense que personne n'a été assez naif pour croire que ca marcherait partout, sur tout et pour toujours...
mais avec cette nouvelle version 1.5, toutes celles qui ne disposent que du 1.4 vont à nouveau être à la bourre
Enfin, ca, vieux, c le jeu de l'évolution... tu gueules quand même pas quand un nouveau noyau linux sort et qu'il est pas aussitot dans les distribs ? faut du temps.
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 4.
Petite erreur de raisonnement, que l'on retrouve dans cette blague éculée où Toto, 6 ans vient d'apprendre que son grand-père a 86 ans. Comme il a aussi appris les soustractions récemment, il fait un petit calcul, et conclut tout joyeux que dans 80 ans, il aura le même âge que son grand-père.
Pour les gens en manque de café, je traduit: les JVM alternatives ne seront jamais au même niveau que les JVM officielles tant que celles-ci continueront à évoluer.
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
1) L'évolution est "obligatoire" en informatique.. quand on s'arrete on meurt non ?
2) Pkoi est ce que les jvms alternatives ne seront jamais au nivo des jvm officielles ? je vois pas le rapport
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 3.
Pourquoi une JVM alternative sera toujours à la traîne par rapport à la JVM de Sun ? Parce que pendant qu'ils comblent les manques, Sun continue de développer sa JVM et son langage (Actuellement le niveau de portabilité maximal c'est plutôt Java 1.1 que Java 2+).
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Je ne suis pas d'accord.. les specs sont en libre accès et les jvm alternatives peuvent avoir les informations au même moment que sun.. donc à partir de la, ils pourraient très bien ne pas avoir de retard...
Sauf le fait que sun a plus de monde dessus.
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 0.
Effectivement, dans ma blague sur Toto, si Toto arrive à vieillir plus vite que son grand-père ça résoud le problème... mais ça semble difficile dans l'état actuel des choses.
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
Petite erreur de raisonnement, que l'on retrouve dans cette blague éculée où Toto, 6 ans
Il n'y avait pas d'erreurs dans mon raisonnement mais dans le tien
La situation serait peut-être égale si tous les deux partaient de zéro, mais étant donné qu'ils ont du retard maintenant, il faudrait avoir plus de développeurs que Sun pour rattraper ce retard.
C'est comme pour tout et je n'ai pas besoin de blague pour te le montrer.. quand quelqu'un part avant, il a plus d'avance que celui qui part après ! et oui !
je pense qu'il a fallu aussi quelques années à linux pour rattraper les unix.
et donc ta phrase : les JVM alternatives ne seront jamais au même niveau que les JVM officielles tant que celles-ci continueront à évoluer. était fausse.. "ne seront jamais" n'est pas juste. C'est possible.
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 0.
Pour résumer l'idée: lorsque je dois faire un choix d'une techno, je me fiche royalement de savoir si dans un monde idéal qui n'existe pas, une techno est acceptable comme choix. Ce qui m'intéresse, c'est de savoir si dans le monde réel, cette techno est acceptable.
«et donc ta phrase : les JVM alternatives ne seront jamais au même niveau que les JVM officielles tant que celles-ci continueront à évoluer. était fausse.. "ne seront jamais" n'est pas juste. C'est possible.»
Je n'est pas dit "c'est impossible, dans aucun univers parallèle ça n'arrivera", j'ai dit "ça n'arrivera pas", sous entendu dans notre Univers. Ça pourrait arriver dans un monde où il y a plus de développeurs dans l'équipe du libre que dans celle de Sun, mais quelle pertinence pour choisir une techno dans notre monde ?
Je maintiens donc ma comparaison, Toto ne vieillit pas plus vite que son grand père, et les JVM libres n'évoluent pas plus vite que celle de Sun. Par conséquent, je ne suis pas prêt de voir une JVM libre au niveau de celle de Sun.
«je pense qu'il a fallu aussi quelques années à linux pour rattraper les unix.»
Les unix étant pour la plupart des gros dinosaures qui n'évoluent pas énormément, non ?
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Ce n'était pas ton propo au début mais admettons... dans le monde réel, java est utilisé pour tout et par beaucoup de gens.
je suis content de voir que tu dises Par conséquent, je ne suis pas prêt de voir une JVM libre au niveau de celle de Sun.. ca change de ton les JVM alternatives ne seront jamais au même niveau que les JVM officielles
Euh d'après toi ? combien d'années il a fallu à linux pour passer de statut d'embryon à celui "d'équivalent" Unix ?
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 2.
C'était quoi mon propos alors ?
«je suis content de voir que tu dises Par conséquent, je ne suis pas prêt de voir une JVM libre au niveau de celle de Sun.. ca change de ton les JVM alternatives ne seront jamais au même niveau que les JVM officielles»
Si ton contentement porte sur le fait que j'ai dit libre au lieu de alternative, j'admet que je n'avais pas été précis au début... Sinon, je ne vois pas ce que tu veux dire. Je maintiens exactement la même chose depuis le début (à cette imprécision prêt): en pratique, on doit utiliser une JVM non libre pour exécuter un programme Java récent, et ce n'est pas pret de changer.
«combien d'années il a fallu à linux pour passer de statut d'embryon à celui "d'équivalent" Unix ?»
Unix était un concept stable quand Linux est apparu, ça suffit à invalider toute comparaison. J'veux bien en discuter quand même, mais les questions rhétoriques c'est assez lourd, il faut deviner soi même l'argument... Tu veux dire que si on attend encore deux ou trois ans, les JVM libres seront au niveau de celle de Sun ? Mais laquelle, de Sun ? Au niveau de Java 1.5, ou au niveau de la version de Java de dans deux-trois ans ?
[^] # Re: révolutionnaire !
Posté par Anonyme . Évalué à 3.
1) - La vitesse de développement se mesure en temps*homme, avec quelques corrections d'échelles (ressources matérielles, qualité des dévelloppeurs, etc ...).
2) - Si la mesure temps*homme global d'un projet 1 est supérieur à celui d'un autre projet 2 (demandant la quantité de tavail comme une JVM, par exemple), alors le dévellopement du projet 1 ira plus vite (le nombre de fonctionnalité implémentées dans un même laps de temps pour le 1 sera supérieur au 2).
3) - quelque chose qui va plus vite qu'une autre, est soit devant, soit ratrapera l'autre en un temps fini.
4) - Sachant 1, 2,3, une JVM develloppé par un tiers peu rattraper la JVM de Sun.
Mais il y a des restrictions à ce raisonnement pour le placer dans un raisonnement de faisabilité :
1) - la quantité de dévellopeur sur une JVM alternative dépends de la demande des utilisateurs, + ou -.
2) - sun peu augmenter le temps*homme pour le dévellopement de java, dont l'un des critère peu être la quantité d'utilisateurs.
3) - La réécriture demande à réinventer la roue, et parfois on doit la faire de manière différente. (pour contribuer au projet classpath, il ne faut SURTOUT pas s'inspirer des sources du Java de sun, c'est l'une des première choses qu'il imposent aux contributeurs)
4) - et bien d'autre ....
Ceci pour dire : nous vivons dans un monde réel, qui a ses contraintes, et que je sache, les dévellopeurs de sun seront toujours d'un nombre fini.
Le modèle de dévellopement habiltuel du libre permet d'avoir un très grand nombre de dévelloppeurs sans comprommettre le projet, alors que dans le monde de l'entreprise le modèle de dévellopement peu s'avérer invalide si l'on a trop de ressources humaines (problèmes de communication, et autres ...). Certaines entreprises on planté des projets à causes de problèmes d'organisation !
Ceci implique que faire un JVM libre du niveau de celle de sun est *possible*.
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 2.
Ma formulation de départ laissait penser que je disais que c'était impossible dans l'absolu, je le reconnais, mais nous avons éclairci ce point dans la suite de la discution. Je suis d'accord que c'est théoriquement possible, et ma comparaison n'est évidemment valide que parce que les équipes de développement de JVM libres n'évoluent pas plus vite que celle de Sun. Mais je maintiens qu'elle est valide à cause de ça, et que c'est un obstacle important à la portabilité.
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 2.
«dans le monde réel, java est utilisé pour tout et par beaucoup de gens.»
Dans le monde réel, une écrasante majorité de gens n'en a rien à faire de savoir si un logiciel est libre. Comme tu peux t'en douter, l'objection dont on parle ici (le fameux "java trap") ne leur est pas destinée.
Je vais quand même achever ma participation ici, parce qu'en relisant, j'ai compris ce que tu voulais dire en exprimant ton contentement. Tu fais une citation sélective de mes propos, pour me faire dire des conneries, ce qui clot la discution (je n'ai pas dit que les JVM alternatives ne seraient jamais au niveau des JVM officielles, j'ai dit que ce serait le cas tant que les JVM officielles continuerait d'évoluer en même temps).
[^] # Re: révolutionnaire !
Posté par nicolassanchez . Évalué à 4.
[^] # Re: révolutionnaire !
Posté par nooky59 . Évalué à 1.
Par contre, évidemment, çà ne doit pas être aussi libre qu'un projet sous GPL mais je ne connais pas les restrictions.
[^] # Re: révolutionnaire !
Posté par moyan . Évalué à 2.
je crois que java a dit un peu plus :
compile once, run anywhere
[^] # Re: révolutionnaire !
Posté par par . Évalué à 5.
Et comparer la portabilité de Perl et de Java, c'est léger : ils ne jouent pas dans la même cour. C'est plus facile de traduite un "Perl précis et concis" de 100 pages en Urdu, que le "Larousse encyclopédique" en 5 volumes...
[^] # Re: révolutionnaire !
Posté par Chaddaï Fouché . Évalué à 7.
Vous aurez compris que je fais une allergie à Java, surtout ces derniers temps: Bien que je lui trouve effectivement des avantages objectifs (dans tous les sens du terme ;-) ), ce langage m'attire décidemment de moins en moins (d'autant plus qu'il semble actuellement perdre son âme, qui ne m'avait pas parue particulièrement originale pour commencer).
(J'attends le moinssage sauvage que ce troll ne manquera pas de provoquer :-) )
--
Jedaï
[^] # AHMA
Posté par _alex . Évalué à 10.
Perso, j'apprécie ce langage, en fait les bibliothèques et les communautés autour y sont pour beaucoup.
En même temps, c'est vrai je n'ai pas beaucoup programmer en C++ ou en Python; et j'utilise java pour faire des traitements sur des données XML.
Note sur feature pas donné dans la news: la JVM ne recharge plus 2 fois le contenu classpath en RAM si on lance 2 JVM : http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.htm(...)
[^] # Re: AHMA
Posté par nooky59 . Évalué à 1.
Par exemple, les APIs XML et les webservices.
[^] # Re: révolutionnaire !
Posté par Croconux . Évalué à 9.
En créant Java, les devs de Sun on voulu créé un langage simple à apprendre et débarassé des fonctionnalités dont l'utilisation complexe et souvent mal maitrisée conduit souvent dans le mur (heritage multiple, surcharges d'opérateurs).
Il se trouve que dans le monde merveilleux du logiciel certains sont fans des goodies qui pimentent la vie. Sun a trainé les pieds mais ils ont fini par plier.
[^] # Re: révolutionnaire !
Posté par Romain Guy . Évalué à 10.
Ces nouveautés sont donc la volonté de la communauté et non de Sun, qui se doit malgré tout de communiquer positivement à ce sujet, quel que soit leur avis.
[^] # Re: révolutionnaire !
Posté par gc (site web personnel) . Évalué à 7.
Pour moi l'absence d'autoboxing de Java < 1.5 est une des pires tares du langages, j'aimerais vraiment connaître ses arguments.
[^] # Re: révolutionnaire !
Posté par Cook Captain . Évalué à 4.
* En fait l'autoboxing peut entrainer des trucs bizarres :
public int compute(int a, int b) {
return a+b ;
}
Qu'est ce qui se passe quand tu fais :
Integer AA = new Integer(1) ;
Integer BB = null ;
int sum = compute (AA, BB) ;
Tu auras un null pointer exception sur une methode qui ne comporte que des types primitifs !!!
* De plus l'autoboxing peut entrainer des pb de perfs assez conséquent si on n'est pas vigilant. (création et destruction d'objets).
Bref moi non plus je ne suis pas un fan...
[^] # Re: révolutionnaire !
Posté par tene . Évalué à 2.
- Des types "valeurs", qui ne pourrait être null... même si ça ressemble à une classe (et au passage faire que le boxing/unboxing soit un peu plus qu'un jeu syntaxique, genre que ça permette d'optimiser le brol...)
Et puisqu'on est gentil, des nullable type quand même, parce qu'on a assez chié en ramant sur les valeurs nulles de notre SGBD favori...
Mouais ce serait pas mal d'avoir un langage avec ça :p
[^] # Re: révolutionnaire !
Posté par reno . Évalué à 2.
L'autoboxing masque les conversions ce qui rend le code beaucoup plus lisible, mais d'un autre coté les conversions ont un cout en perf qui n'apparait plus maintenant..
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
M'enfin chez Sun ils sont tellement doués qu'ils sont eux même tombé dans le panneau : avec leur implémentation des generics, tout type primitif se vera boxé et déboxé lorsque associée à une classe générique... comme quoi.
[^] # Re: révolutionnaire !
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
On a ajouté un certain nombre de choses de C+C++ mais surtout de C# à mon avis.
Mais c'est la vie.. l'informatique évolue très vite et si les gens ont des idées, pkoi ne pas les utiliser ? les choses changent.
Ce qui me ferait vraiment chier perso, c'est de programmer dans des langages qui n'évoluent pas et qui ne reprennent pas le meilleur de ce qui se fait à un instant t.
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 4.
Justement, et je trouve dommage que Sun, pourtant dans une position très favorable, n'en profite pas pour justement faire germer des idées : non là ils se contentent de copier, et laisse les autres innover. C'est pas vraiment grâce à celà que l'informatique va évoluer, rien ne vaut l'innovation.
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
et puis, inventer des nouvelles choses dans les langages, tu fais pas ça tous les jours.. je suis à peu près sur que tout existe dans l'ensemble des langages ;)
Et oui, ce JDK est une innovation et oui, java fait évoluer l'informatique
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
Pourtant certaines boîtes ont un secteur R&D et développe des nouveaux concepts, parfois tirés d'autres concepts mais dans l'innovation il y a aussi le fait de réussir à intégrer des technos du passé...
Et oui, ce JDK est une innovation
dans le monde Java uniquement.
et oui, java fait évoluer l'informatique
De part sa communauté et des produits qui sont créés avec. Mais cette version de Java en soit de fait rien progresser du tout. Je dirais même que leur implémentation des generics va plutôt limiter dans le futur, parcque ce genre de choix est difficilement modifiable. Mais fallait sortir vite fait leur produit, sans faire de gros effort de R&D alors bon...
[^] # Re: révolutionnaire !
Posté par Cook Captain . Évalué à 2.
> va plutôt limiter dans le futur
Une implémentation n'est jamais gravée dans la pierre. Comme l'a fait C#, cela obligera à un changement du bytecode.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: révolutionnaire !
Posté par Cook Captain . Évalué à 2.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: révolutionnaire !
Posté par Cook Captain . Évalué à 2.
Il ne l'ont pas choisi car Sun ne voulait pas changer son bytecode comme l'a fait Microsoft. De toute manière, changer le byte code casse beaucoup plus de choses. En tout état de cause, je ne sais pas si c'est un bon choix car de tout manière, il faudra bien qu'un jour le byte code évolue.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
Non non, à l'exécution tu auras une classe avec comme paramètre object... youpi.
Effectivement celà apporte une modification au niveau de la JVM : ajouter une notion aux types. M'enfin la solution de Microsoft le fait, et les anciens programmes marchent très bien sur la nouvelles VM. Evidemment l'inverse n'est pas possible... Mais bon là ils ont pété le langage en y ajoutant des modifs qui casse tous les compilateurs : ils auraient pu en profiter pour faire pareil sur la JVM... Franchement ils n'ont à mes yeux aucune excuse sur ce coup.
[^] # Re: révolutionnaire !
Posté par mdlh . Évalué à 2.
Pour le C et le C++: http://www.hpl.hp.com/personal/Hans_Boehm/gc/(...)
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Mais non :)
http://about.me/straumat
[^] # Passez à l'Objective-C !!!
Posté par nicolassanchez . Évalué à 4.
En effet, il n'y a pas dix milliards de mots clefs à ajouter (y'a pas de abstract, virtual, etc.).
Tu gardes tous les avantages du C, la gestion de mémoire se fait à l'aide de compteur de références que tu incrémente et décrémente à la main (ou avec un garbage collector de ton choix si tu le souhaites), tu fais de l'objet distribué ultra facilement...
Contrairement au C++, l'Objective-C a un Runtime comme le Java ou le C#... en gros tu peux modifier tes classes pendant l'exécution...
Grâce à GNUstep, l'objective-C et OpenStep devient compatible entre tous les systèmes après recompilation (sur MS pas tout à fait mais très bientôt...). Avec GNUstep, il sera bientôt possible de mêler du C++ avec de l'Objective-C dans le même fichier...
Pour ne rien oublier, l'accès aux bases de données se fait à l'aide de EOF ou avec du SQL standard...
GnustepWeb est une implémentation de WebObjects qui repose sur GNUstep...
C'est vrai qu'il faut recompiler selon le système, mais bon, il y a gnustep-make qui rend l'opération extrêmement facile...
En gros, avec GNUstep et ses petits copains, tu peux tout faire, facilement et très proprement...
[^] # Re: révolutionnaire !
Posté par RuleZ . Évalué à 6.
- Le language en lui même est pure objet, java est né objet, et ça c'est ce qui en fait un language d'un immense intérêt pour les développements d'applications. Petit rappel : L'orienté objet offre la possibilité d'architecturer, d'étendre, et d'entretenir à merveille une application pour peu que sa conception ai su profiter de l'objet, et que le language en permette une mise en oeuvre aisé .. Java répond à tous les besoin d'un developpeur d'applications en matiére de conception objet.
- La plateforme Java/J2EE, standart, extrémement compléte, sans aucune lacune. Pour un développement applicatif c'est idéal : on se concentre sur l'algorithmie, sur l'architecture de nos objets et leurs routines de base, sur de l'assemblage basique de composants et d'objets ... On n'a pas à passer des heures à réécrire des fonctions de gestion d'un bout d'interface, de traitement d'entrées/sorties, on a déja tout à porté de main, chaque développeur ne réinvente pas la roue dans son coin, chacun se concentre sur ce qui différencie réellement son application d'une autre, en utilisant les objets fournis en standart avec la plateforme, et on n'a pas à réécrire une banale routine déja écrite un million de fois par un millions d'autres développeurs.
- La machine virtuelle : qui, dans un monde utopique, offrirai la portativité absolue, puisque c'est le code compilé lui-même qui peut s'éxécuter sur des OS différents, sur du matos différent (dans un monde ou Microsoft n'a pas encore réussi sa tentative d'hégémonie), sans que le développeur n'ait à se préoccuper des milliers de petites différences qui pourraient bouleversé l'éxecution de son application.
Résumé: Java ce n'est pas seulement un language, c'est aussi et surtout une plateforme et une machine virtuel.
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Je préfère faire un commande.ajouterArticle(article); à des sales inserts sql ;)
Et j'ajouterais que la jvm et J2ee sont définis par JCP dont sun est un membre comme BEA, JBoss ou Gavin King.
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 9.
T'en as d'autres des énormités pareilles ? Java est orienté objet, il n'est pas pur objet. Il n'y a qu'à voir les types de base qui ne sont pas des objets. Ils commencent tout juste à masquer la différence entre un type de base et un objet dans cette version, qui permet si j'ai bien compris un cast implicite de int vers Integer, etc.
"Petit rappel" pour moi aussi, dans un langage pur objet, tout est un objet, par exemple ceci est valide:
(2 + 3).to_string()
Dans les langages "presque pur objet", il y a l'Eiffel, dont on a parlé ici récemment, il y a le Ruby aussi, que je recommende à tout le monde. Je crois que Smalltalk est complètement objet, mais je n'ai jamais vérifié par moi même.
[^] # Re: révolutionnaire !
Posté par RuleZ . Évalué à -5.
Pour te déstresser, sache donc que j'avais parfaitement conscience de mon abus de language (à la limite), qui m'évitais juste de partir trop en vrille en digressant excessivement sur ce que n'est pas java.
Ce que mon "pure" associé à "objet" signifié implicitement, ce n'était pas que dans java tout est objet, mais plutot que rien dans java n'est procédurale, contrairement à un certains C++.
[^] # Re: révolutionnaire !
Posté par celastus . Évalué à 9.
Je ne connais pas de langage qui soit autant "objet" que smalltalk, à part peut-être certaines implémentations en lisp à l'interêt principalement éducatif.
Smalltalk est un tres, tres beau langage avec lequel j'ai pu m'amuser en entreprise il y a quelques années. Cela fait bien longtemps que je ne l'ai pas vu tourner. Je ne sais même pas s'il est encore mis à jour.
Les problemes de smalltalk étaient les suivants :
- Les concepts de l'interface graphique (MVC - Modele vue contrôleur) étaient tres puissants mais difficiles à apprehender
- Le systeme de classe étais un peu complexes pour un débutant. Chaque classe créée par le développeur donnait lieu à la création se sa méta-classe. La classe Collection était instance de la metaclass "class Collection". La classe Object Class étais sous-classe de la classe Metaclass, elle-même indirectement sous-classe de Object (comme toutes les classes de smalltalk). Comme vous voyez ce n'est pas simple...
- La machine virtuelle prenait beaucoup de mémoire. Elle incluait un environnement de développement, un débogeur et ln compilateur, tout tres tres bien faits mais gourmands...
- Le typage statique est inexistant ou presque. Ce n'est qu'à l'execution que la machine virtuelle peut détecter qu'une methode appellée n'existe pas. Pour couronner le tout, il est possible de faire de la meta-programmation, et d'appeller une méthode par son nom. Il n'est alors même plus possible en regardant le code de savoir quelle est le nom de la méthode appellée...
Le compilateur, comme tout l'environnement de développement, étais écrit en Smalltalk. Il produisait du code-ocyet (bytecode) interpreté par une machine virtuelle, coeur de l'architecture smalltalk. Les methodes primitives étaient les seules méthodes ne contenant pas de code smalltalk, et faisaient directement appel à la machine virtuelle. Par exemple, la méthode + de la classe Integer, ou les méthodes de bas niveau ayant trait à l'interface graphique.
Le concept de fermeture si cher à Lisp existait dans smalltalk. Ainsi le bloc [:x :y | (x>y) itTrue: [x] ifFalse: [y]] prends en entrée deux nombres et en renvoie le plus grand. Notez la méthode ifTrue:ifFalse, implementée dans la classe Boolean, qui prends deux blocs sans arguments en entrée et execute l'un ou l'autre selon la valeur de l'objet courant (self). Notez aussi que ce type de code est totalement générique : tant que la classe dont l'objet x est instance implémente la méthode >, accepte y comme argument, et renvoie un booléen, le code fonctionnera.
Les apples de méthodes étaient evidemment tous résolus dynamiquement, il n'étais pas question comme en c++ de devoir déclarer qu'une méthode était virtuelle. Toutes les méthodes étaient virtuelles sans exception. Les méthodes de type static étaient implémentées comme des méthodes standard dans la métaclasse. Par exemple, la méthode new de la classe "class Table" renvoyait une instance de la classe "Table", non sans lui avoir envoyé le message init (i.e. appellée la méthode init sur cet objet).
[^] # Re: révolutionnaire !
Posté par _alex . Évalué à 3.
J'ai appris ce langage à l'université, on a eu un TP à faire. 5 min avant de faire la démo un groupe avait un bug, partout ou il devait utiliser "<" il utilisait ">". Solution d'un des élève : patcher le code Integer, méthode "<" , pour que le programme marche.
Il y a peu d'autre langage ou c'est possible ;-)
(Je trouvais la création d'interface utilisateur assez sympa)
[^] # Re: révolutionnaire !
Posté par celastus . Évalué à 1.
Par contre, il y avait un truc que j'aimais bien faire : patcher la méthode d'affichage graphique des caracteres pour les afficher à l'envers (comme dans un miroir). A peine la méthode validée, toute l'interface graphique de smalltalk, du gestionnaire de classes au débogueur, était affichée à l'envers.
[^] # squeak
Posté par zebul666 . Évalué à 2.
http://www.squeak.org(...)
[^] # Re: révolutionnaire !
Posté par lorill (site web personnel) . Évalué à 1.
[^] # Re: révolutionnaire !
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: révolutionnaire !
Posté par gc (site web personnel) . Évalué à 2.
irb(main):001:0> i = 1
=> 1
irb(main):002:0> i.class
=> Fixnum
irb(main):003:0> i.class.class
=> Class
Pour les structures de contrôle je ne savais pas que ça pouvait/devait être des objets aussi, ça doit être parce que j'ai raté la case Eiffel :/
En quoi est-ce utile ? Enfin je veux dire, quelle chose jolie on peut faire en Eiffel (ou autre) grâce au fait que les structures de contrôle sont des objets, que l'on ne peut pas faire en Ruby ?
[^] # Re: révolutionnaire !
Posté par Yusei (Mastodon) . Évalué à 2.
Je ne crois pas qu'en Eiffel les structures de contrôle soient des objets, mais Eiffel n'est pas pur objet (selon les définitions que l'on prend, les opinions diffèrent).
Pour le fait que ça puisse être des objets, étant donné qu'en Ruby un bloc de code est un objet, on peut voir une struture for comme un objet défini par:
- Le bloc de code d'init
- Le bloc de test
- Le bloc «d'incrémentation»
- Le bloc à effectuer à chaque itération.
Ce n'est pas spécialement intéressant tel quel, sauf si on veut pouvoir modifier un des blocs au vol. Par contre on peut imaginer quelques applications à l'héritage sur une structure de contrôle, j'en prend une complètement bidon:
J'ai un "while" qui attend une connexion, effectue un dialogue, et boucle. Je voudrais modifier cette boucle pour effectuer un calcul au début de chaque itération. Je peux redéfinir l'object "while" pour rajouter cette fonctionnalité à toutes les boucles.
Un peu plus intéressant, je peux avoir deux versions d'un objet While, une avec des opérations de débug, et l'autre sans. Lors de l'exécution, je définis celle qui m'arrange en fonction des arguments donnés.
[^] # Re: révolutionnaire !
Posté par TSelek . Évalué à 0.
par contre, "def", "if" etc ne sont pas des objets (quoique... ça ne serait pas des méthodes en elles-mêmes?...) mais bon, en arriver à savoir si le ';' est un objet, heing...
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Bon, soyons sérieux, l'informatique est un eternel recommencement.
On dit que si on veut voir l'informatique dans le futur, jetons un coup d'oeil à Smalltalk. Je pense que ce n'est pas loin d'être vrai.
Ce que l'on a sous la main, on se dit super ! et on se précipite à le refaire, différemment, évidamment, pour finalement, peu à peu, introduire de nouvelles caractéristiques qui lui font peu à peu ressembler à l'original mais ... pas en mieux. J'aime bien la diversité, mais je n'aime pas ce qui essaie de copier en moins bien l'original.
Par exemple, j'aime bien Ruby/python, Self, Eiffel pour leur apport et différentiation.
Vous aimez les caractéristiques de Java 5 ou de C# ? Regardons de côté d'Eiffel par exemple pour s'appercevoir que finalement ce n'est pas si révolutionnaire que ça. Autant Java, langage des années fin 90, a les circonstances atténuantes, autant C#, apparue au 21e siècle, n'a aucun pardon pour être aussi "pauvre" comme langage dit objet ; mais bon, faut pas se leurrer, ce sont avant tout des langages commerciaux.
Vous aimez le principe de la VM, regardons du côté de Smalltalk (et aussi pour toutes ses caractéristiques) et là vous commencez à pleurer de vous tapper ces merdes (pardon pour ce gros mot) que l'on appelle JVM (essayer squeak et je pense que vous comprendrez).
ha, l'API de Java ? Lorsqu'on l'a compare à celui de Smalltalk ou d'OpenStep, vous commencez à mettre en doute les compétences réelles en objet des concepteurs de cette API Java (oui, je sais, j'y vais un peu fort). Enfin bref, une API de qualité différente, non cohérente sur l'ensemble des composants. Mais bon, nul n'est parfait et Java (il n'est pas le seul) l'illustre parfaitement :)
Bon, bref. Ce que je peux dire, c'est que Java 5 n'est pas une révolution, mais une simple évolution qui va, enfin, me permettre de programmer correctement, avec une certaine souplesse et à prendre enfin plaisir à programmer avec ce langage.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
En quoi C# est-il pauvre ?
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
- pas de généricité contrainte. Permet de rajouter de la flexibilité à des langages à typage statique, de pouvoir faire de l'objet selon l'appoche F-Bound et non celle, plus limitée, de Liskov.
- pas de covariance. Du moins avec les types de retour des méthodes, car celle des arguments est plus problématique sauf si il y a support des types ancrés, auquel cas on peut faire là aussi de l'objet selon l'approche F-Bound.
- plus discutable : pas de visibilité flexible (telles methodes ne sont visibles que par les objets de telle et telle autre classe)
- etc.
Je ne mettrait pas ici l'héritage multiple, même si, depuis la fin des années 80, on sait correctement la gérer (pas comme C++ ou c'est pitoyable). Ca dépend si le langage veut se faire simple ou non.
De même je n'introduit pas non plus la faculté de définir des méthodes supplémentaires à une classe existante ou mieux à des objets ; ceci permet une utilisation souple du concept de rôle.
Ce n'est que quelques exemples, mais les deux points ci-dessus sont, AMHA, les plus importants que devrait supporter un langage objet à typage statique moderne.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu peux expliquer ?
pas de covariance.
L'utilisation qui est généralement faite de la covariance peut tout à fait être envisagé par les arguments de méthodes passés en référence. Même si il n'y a pas de covariance, il n'y a pas de limitation, puisque le but peut être atteind autrement.
pas de visibilité flexible
Alors là c'est vraiment discutable.
Il suffit d'avoir une interface I qui contient une méthode foo, alors la classe A :
class A : I {
I.foo();
}
la méthode foo n'est accessible que lorsqu'elle est référencé en tant que I. Celà permet de gérer proprement les accès aux objets utilisateurs en leur filant seulement l'interface désirée.
Je ne mettrait pas ici l'héritage multiple
Même si leur implémentation est tout à fait envisageable, il y a de nombreuses raisons de s'en passé (d'abord parcque ce n'est pas indispensable).
De même je n'introduit pas non plus la faculté de définir des méthodes supplémentaires à une classe existante ou mieux à des objets
Ce concept peut très bien envisager avec une méthode orientée aspect et un tissage sur des classes existantes. Par contre j'ai du mal à comprendre l'intérêt en dynamique (pas la beauté de la chose, l'intérêt)
C# est un langage destiné à être utilisé, pas destiné à des fins académiques, ce qui explique de nombreux choix de conceptions.
Donne moi le nom d'un seul langage "moderne" qui intègre tout tes killerfeatures et qui soient utilisées parcque utilisable et simple à apréhender ?
[^] # Re: révolutionnaire !
Posté par thecat . Évalué à 7.
>pas de généricité contrainte.
Tu peux expliquer ?
En faisant simple, c'est de pouvoir contraindre un parametre générique à n'etre que d'un certains type, par exemple:
ENSEMBLE_ORDONNE<T : COMPARABLE>
Un ensemble ordonné ne peut contenir que des elements qui sont comparables entres-eux.
... la covariance peut tout à fait être envisagé par les arguments de méthodes passés en référence ...
On parle de la covaraince du type de retour (du resultat quoi) qui à l'avantage d'etres sûr du point de vue des types.
Même si il n'y a pas de covariance, il n'y a pas de limitation, puisque le but peut être atteind autrement
Non! Contre exemple : En C il n'y a riens pour faire de l'objet et il y a donc des limitations pour faire de l'objet, meme si on peut faire autrement.
Avoir la possibilité de la covariance est vraiment interressant (et ne coute vraiment rien au langage). Ne pas l'avoir inclu dans un langage recent est une erreur, surtout quand ce langage n'a pas vraiment pour but d'etres simple (cf la fin de ce post).
>pas de visibilité flexible
Alors là c'est vraiment discutable.
Il suffit d'avoir une interface I ...
Non ce n'est pas discutable. Il ne propose pas de visibilité flexible point. Ta proposition est un hack immonde qui rendrait incompréhensible n'importe quelle bibliothèque un peu volumineuse. De plus ta solution n'est pas réalisable quand ce n'est pas toi qui a concu la bibliothèque.
l'heritage multiple n'est pas indispensable
Bin si justement, il est indispensable pour une bonne modélisation et pour éviter certaines duplication de codes.
Comme pour tout tes autres arguments précédent: effectivement on peut éviter d'utiliser l'héritage multiple mais dans certains cas tu sera embeter de ne pas l'avoir et du coup tu contournera le problème en duplicant ton code.
Ce concept peut très bien envisager avec une méthode orientée aspect...
Laisse les Aspect ou ils sont! Ajouter les aspect c'est introduire un nouveau paradigme (trés criticable en plus) dans un langage qui ferrait biens mieux de se concentrer sur l'aspect objet. Par contre l'ajout d'une methode à une classe aurrait etait une vraie nouvauté interressante (pour la version dynamique, je suis d'accort avec toi: je ne vois pas encore l'utilité ...)
Donne moi le nom d'un seul langage "moderne" qui intègre tout tes killerfeatures
Eiffel propose tout cela, et est portable (niveau source) sur beaucoup d'architecture.
Mais de toutes facon le problème n'est pas de te donner un exemple car voila maintenant pourquoi C# est nul:
Le C# est l'un des dernier langages industriels (qui se veut trés utilisables donc) sorti. Or il n'a apporté aucune amélioration ni innovation notoire. Pire même, il a repris des scories incompréhensible pour un langage objet du "21eme siecle" : en l'occurence, le mot clef "virtual". Le fait même d'avoir conservé ce mot clef devrait faire condamner ce langage par toutes personnes ayant compris le paradigme objet. De plus, l'ajout de ce mot clef empeche de langage de se prétendre vraiment "simple", du coup pourquoi ne pas avoir ajouter d'autres possibilitées plus "évoluées" (héritage multiple, covariance, types ancrés ...)
Java lui etait innovant pour l'epoque (un langage industriel multi-plateforme, pouvant etres orienté web, suffisament efficace, avec un gc et possédant un framework unifié et trés complet): il se voulait simple et a expliqué comme ca tous les manques que l'on pouvait lui reproché (généricité, héritage multiple ...)
Java ajoute maintenant certaines fonctionalitées, c'est plutot biens mais il ne faut pas réver: esseyer de faire évoluer un langage qui se voulait simple vers un langage proposant toutes les fonctionalitées possibles ne peut pas conserver une bonne intégration. Mais bon c'est un moindre mal.
Donc voila pourquoi C# est minable comparé à Java: il n'apporte riens, ou plutot apporte n'importe-quoi.
!Par contre! La plateforme .Net est une vraie innovation: la possiblitée de mélanger différents langages sur une VM. Mais sur ce sujet, je suis plutot sceptique sur la reelle pertinance.
Ok ca permet de réutiliser des bibliothèque d'autres langages plus rapidement, mais l'intégration ne peut pas vraiment etres homogéne et si on choisi un langage possédant un framework complet, cela devient inutile.
Mais cela a au moins le mérite d'avoir était proposé.
[^] # Re: révolutionnaire !
Posté par reno . Évalué à 2.
>Bin si justement, il est indispensable pour une bonne modélisation et pour éviter certaines duplication de codes.
Si le coté des admirateurs de Java "nous on n'a pas l'héritage multiple qui est compliqué mais on a les interfaces, c'est mieux", alors que les interfaces sont un sous-cas de l'héritage multiple m'a toujours fait beaucoup rire, je ne sais pas si l'héritage multiple est indispensable: certains langages tels Ruby, D utilise des "mix-in" a la place de l'héritage multiple.
J'avoue avoir beaucoup de mal a comparer mix-in et héritage multiple, car j'ai du mal a comprendre ce qu'est un "mix-in"..
En tout cas, cela doit être plus simple a implementer dans le compilateur: c'est la justification des concepteurs de D.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 1.
Oué enfin la solution C# ne permet effectivement pas d'imposer un type, mais permet d'imposer une interface... donc bon pour moi l'utilité est la même, il n'y a donc pas de lacune pour ce cas précis.
On parle de la covaraince du type de retour
je sais ce qu'est la covariance, ce que j'ai voulu te dire, c'est que C# a le mot clé ref qui permet d'effectuer des passages par référence et donc de "retourner" plusieurs valeurs, là encore avec vérification du type, puisque celà semble être un bon critère.
De plus ta solution n'est pas réalisable quand ce n'est pas toi qui a concu la bibliothèque.
? Une bibliothèque n'est pas censé être modifiée, tout ce qu'on peut faire c'est utiliser des constructions de la bibliothèque en les spécialisant par héritage. Je ne vois vraiment pas le rapport avec la choucroute, ou alors tu t'explique ou alors je comprend mal. QUand à mon hack immonde, désolé mais je le trouve vraiment élégant, implémenter une interface en lecture/écriture sans autoriser tout le monde à y accéder, je trouve ça class.
Laisse les Aspect ou ils sont!
Je te propose une solution, et tu me dis de la laisser tomber. Poutant elle marche très bien. Uen variante consiste à injecter du code à travers des infos passées en méta-données, là encore de manière élégante. Arrête de snober tout ce qui résoud le problème.
Mais sur ce sujet, je suis plutot sceptique sur la reelle pertinance. [multi-langages]
Ben, c'est vrai que recompiler une application existante en .NET grâce au support multi-langages c'est parfaitement inutile, c'est vrai que laisser le choix au programmeurs du langage dans un projet (ok au sein d'un même projet c'est discutable) sans se soucier de comment l'API sera utilisé et par qui, c'est encore plus inutile. D'ailleur c'est rigolo, mais pour tous les langages de la plateforme tu as accès de manière uniforme aux API du frameworks, et pourtant tu ne sais strictement pas dans quel langage il a été codé...
et du coup tu contournera le problème en duplicant ton code
Non pas forcement, il y a toujours une autre solution. Mais je maintient ce que je dis : l'héritage multiple peut poser des problèmes (multiples c'est le cas de le dire), ne serais-ce qu'à cause de l'héritage de concepts à la signature identique et à d'autres sortes de conflits.
Le fait même d'avoir conservé ce mot clef devrait faire condamner ce langage par toutes personnes ayant compris le paradigme objet
Ben désolé il me semble avoir compris le "paradigme" objet, et j'attend une explication. SI tu veux parler du choix d'avoir mis en "final" par défaut, ben l'explication est par ici : www.artima.com/intv/nonvirtual.html .
java lui etait innovant pour l'epoque
je suis tout à fait d'accord. Dommage que ce n'est pas le cas de cette version.
il n'apporte riens, ou plutot apporte n'importe-quoi.
C# a peut-être copier des fonctionnalités d'autres langages sans vraiment rien inventer, mais il a innover comme l'a fait Java à son époque : il a inclu dans un même langages des principes et techinques jusque là dispersées dans différents langages. Java5, dont on parle actuellement, n'apporte rien de plus que C#, toutes les fonctionnalités existant dans un même langage : C#.
Mais bon c'est vrai que avoir inclu dans un mêmes des petits trucs vraiment utiles (par rapport à la covariance qui est un concept facilemetn contournable) c'est vraiment du n'importe-quoi. Et puis c'est vrai que le concept d'événement qui permet d'utiliser le patron de conception Observateur facilement c'est inutile. Et puis c'est vrai que avoir rajouter la possibiliter de checker les débordement dans les opérations élémentaires c'est n'importe quoi. Et puis tout ces petits trucs tirés à droite à gauche qui rende ce langage agréable, comme le foreach, les propriétés, ou encore les métas-datas, les itérateurs, et bien sûr tout ce qui touche le confort pour la réutilisation de code : les pointeurs, la notion de structure, de stack, etc. Mais bon tout celà c'est n'importe quoi. Pourtant dans la pratique c'est super utile, en tout cas beaucoup plus que la covariance ou l'héritage multiple.
Eiffel propose tout cela, et est portable (niveau source) sur beaucoup d'architecture.
Voilà, superbe langage. Mais du point de vu "industriel" comme tu dis : rien que sur un point, facilite-t-il la réutilisation de l'existant ? Ah vi y'a une méthode simple : il cible .NET ;)
[^] # Re: révolutionnaire !
Posté par thecat . Évalué à 4.
je sais ce qu'est la covariance, ce que j'ai voulu te dire, c'est que C# a le mot clé ref qui permet d'effectuer des passages par référence et donc de "retourner" plusieurs valeurs, là encore avec vérification du type, puisque celà semble être un bon critère.
Ca n'a absolument pas le même but. La covariance permet une modélisation élégante et efficace.
Une bibliothèque n'est pas censé être modifiée ... tout ce qu'on peut faire c'est utiliser des constructions de la bibliothèque en les spécialisant par héritage
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment? Tu propose de définir une interface pour chaque exportation possible, je doit donc creer une interface spécifique (et qui ne servira à riens d'autres) pour chaque clause d'exportation? Tu trouve toujours cela "élégant"?
Au sujet des Aspect ...
Tu propose comme solution d'introduire tout un nouveau paradigme de programmation, qui est en plus trés criticable au niveau de l'utilisabilitée réelle; je ne trouve cela vraiment pas adapté. Le problème est juste d'avoir la possibilité d'ajouter une methode à une classe (en statique, la classe n'etant pas la tienne tu ne peut pas toucher le code). La possibilité de manipuler une classe et de lui ajouter une méthode est loins d'etre compliqué au point d'inventer des mecanismes super sofistiqués (et surtout qui rompent avec la conception objet).
[sous .Net] tu as accès de manière uniforme aux API du frameworks, et pourtant tu ne sais strictement pas dans quel langage il a été codé...
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité (je ne me rapelle plus l'appelation) et du coup ceux qui font les API, ne peuvent pas reellement exploiter toutes les possibilitées du langage qu'ils utilisent si ils veulent etres "compliant".
Mois si j'utilise un langage foncitonel, c'est pas pour faire de l'objet. Si je fait une biliothèque en langage fonctionel, Ok, elle sera directement utilisable sous d'autres langages grace à .Net, mais elle ne sera pas homogène dans mon autres programe qui l'utilise écrit lui en C#.
Cepandant je le répète la posibilité de diretement réutilisé une bibliothqèue existante est super-pratique, mais ce n'est vraiment pas idéal.
Non pas forcement, il y a toujours une autre solution.
Dur a suivre si on ne ce répond pas dans le même sens! ;-)
Non il n'y a pas d'autres solution que de dupliquer ton code. Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire! (non ce n'est pas moi qui suit mauvais, mais Ok cela reste -heureusement- peu fréquent)
Au sujet des mixins (du post du dessu) il est vrais qu'ils se propose d'étres une alternative à l'héritage multiple, mais je ne trouve pas leur utilisation reelement plus simple.
Au sujet du "Virtual" ...
Toujours les même arguments.
Sur la performance, c'est n'importe quoi: .Net est une machine virtuelle! donc ce n'est pas sur un petit appel de méthode que l'on va gagner les perf! Pour la version compilé (je sais que tu va m'en parler) des langages propose des methodes "tout" virtuel et une implémentation trés trés veloce! (biens meilleure que pour le C++ par exemple) donc l'argument ne tiens plus vraiment la route avec les progrés des compilo de nos jours.
Pour le versionning, c'est pareil, des langages proposent du tout virtuel sans avoir de scories dans les bibliothèques qu'ils proposent. Dans le pire des cas le mot "final" (ou son equivalent) existait pour les cas trop critique.
Bref rien de neuf, avoir gardé ce mot est vraiment une grande erreur.
[Java était innovant] Dommage que ce n'est pas le cas de cette version
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage (mais pas par rapport au autres Ok)
Mais surtout, Java abandonne l'aspect "langage trés simple" qu'il avait.
[Eiffel] facilite-t-il la réutilisation de l'existant ? Ah vi y'a une méthode simple : il cible .NET ;)
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!): Eiffel facilite la réutilisation des bibliothque à un point qu'aucun langage compilé à typage statique n'a atteint.
La possibilité de le compiler vers .Net n'est qu'une démarche commerciale: Eiffel est déja multiplateforme (OK seulement Win et Linux mais c'est déja pas mal), possède un héritage multiple, des types ancré, des assertions trés puissantes, ... alors je ne pense pas que cela soit pour réutiliser les bibliothèque de .Net qui ne proposent aucune des ces possibilitées.
La encore on voit a quel point l'utilité de .Net est limitée: Je vais vouloir réutiliser des bibliothèque de .Net dans mon programme Eiffel? Elles serons modélisé avec un héritage simple et n'utiliserons pas la puissance du langage de mon application cible.
Un gros avantage est de pouvoir rapidement utilisé ces bibliothèque, mais cela n'est pas une solution vraiment idéale que de jongler intelectuelement avec différentes conceptions.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
Désolé, je me suis planté de mot clé : c'est le mot clé "out" dont je voulais parler :) (Mais sinon explique moi le but de la covariance par rapport à "out")
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment?
Pour moi soit tu es le développeur, et tu as accès au source, tu peux modifier l'accessibilité. Sinon je vois vraiment pas l'intérêt de laisser la possibilité aux utilisateurs de modifier l'accès aux attributs et méthodes d'une classe... Ca va tout péter la signature de la classe !
Tu propose comme solution d'introduire tout un nouveau paradigme de programmation, qui est en plus trés criticable au niveau de l'utilisabilitée réelle;
Pour l'ajout de méthode, pareil qu'au dessus, donne moi un exemple élégant qui me permette celà, avec bien entendu un exemple où celà a un intérêt et qui ne casse pas toute la signature de ma classe. J'ai vraiment des doutes quand à l'utilité réelle.
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité
Tout à fait : CLI (Common Language Interface)
En effet si tu veux garantir la réutlilisabilité de tes API, il faut mieux respecter ces règles (même si t'es pas obligé), mais à l'intérieur de ton code, tu peux utiliser toutes les fonctionnalités du langage, seules les parties exposées doivent être conformes. Pareil à l'utilisation, si ton langage support l'héritage multiple, il peut utiliser des classes conçues en héritage simple.
Cepandant je le répète la posibilité de diretement réutilisé une bibliothqèue existante est super-pratique, mais ce n'est vraiment pas idéal.
C'est quoi l'idéal ?
Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire!
Vas-y balance :)
Ensuite on va voir si c'est pas contournable et si celà ne va pas poser des problèmes potentiels :)
Sur la performance, c'est n'importe quoi
Me semble que ce n'est qu'un argument, contestable effectivement, mais le 2ème est déjà mieux : le créateur de C# pense qu'il est préférable de fermer la possibilité de modifier une méthode par défaut, plutôt que l'inverse, pour des tas de raisons (d'abord le programmeur ne s'en soucis pas, il ne documente pas la possibilité et l'impact d'une méthode sur les attributs d'une classe et son état, etc.) Pleins de bonnes raisons à mon goût, même si celà va à l'encontre du paradigme "objet". Et puis dans la pratique personne ne s'en plaint.
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage
Vi c'est ce que j'ai dis plus haut (ou plus bas), c'est bien pour le langage, mais celà ne créé pas d'émulation, et je trouve ca vraiment dommage.
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!)
C'était juste pour la vanne :)
Je parlais principalement de la réutilisation de code d'API natifs, notamment de d'API écrit en C ou dans d'autres langages, la réutilisation du code écrit en Eiffel je m'en doute ;)
Donc alors la réutilisabilité de l'existant ? (pas de l'existant Eiffel)
[^] # Re: révolutionnaire !
Posté par Philip Marlowe . Évalué à 1.
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Je me pose la question par rapport au mot-clé 'out' que tu apportes comme solution.
La covariance est la faculté de raffiner le type des paramètres d'une méthode en sous-types.
Par exemple, covariance des paramètres et du résultat de retour :
Sinon, il apparaitrait que C# 2.0 intégrera la généricité contrainte (si j'ai bien compris). Il apparaitra, si j'ai toujours bien compris avec Visual .NET 2005.
A part ça, je comprends que les développeurs Microsoft s'exaltent face à C#. Jusqu'à présent, ils fallaient qu'ils se tappent Visual C++ ou Visual Basic. Deux langages qui n'ont d'objet que leur prétention (bon, d'accord, j'exagère), un peu comme bcp de développeurs d'ailleurs (ho la la, que je suis méchant, vraiment :) ).
Et tout d'un coup, on leur propose un langage des années 90, né au 21e siècle, C#. Pour eux, qui ne connaissent que le monde Microsoft ou qui sont condamnés à développer pour ses plate-formes, c'est une découverte ! Expérience vécue dans ma boite.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 4.
N'emploi pas le futur, la norme C# 2.0 est sorti il y a maintenant plus d'un an.
Le compilateur de MS est passé depuis un moment en version 2.0. Effectivement elle n'est distribué que dans les version "bétas" de Visual Studio 2005 parcque MS aime bien filer la plateforme complète de développement qui va avec. Mais si tu veux tu peux chopper cette version sans Visual Studio, et Mono a une preview de C# 2.0 depuis un moment, et à un ou 2 détails près c'est parfaitement utilisable (il manque surtout de l'optimisation, mais ça compile et ca fonctionne comme on le souhaite).
Si ca peut te faire plaisir C# est un langage des années 90 (c'est pas entierment faux, ils ont commencé à bosser dessus au 20ème siècle ;)), mais largement plus utile, notamment en ce qui concerne le confort de réutilisation que l'apport de langage du 21ème siècle comme Eiffel, qui sont par contre très joli à montrer à l'université, parcque ils respectent le paradigme objet et tout et tout. Mais désolé, je trouverai toujours plus utile la gestion transparente des évenements et les métas-données que la covariance, même si c'est des fonctionnalités moins récentes et déjà existantes. C# a été conçu comme un best-of des langages industriels, et de ce fait est un langage industriel. J'entend par industriel puissant, agréable et utile, pas seulement sur le papier, mais aussi avec une équipe de programmeurs.
Pour ton vécu et les mecs qui sotn passés de VB à C#, tu aurais pu leur montrer VB.NET, ils auraient eu quasiment les mêmes possibilités qu'en C# en gardant leur syntaxe favorite ;) La transition aurait été plus douce et vous y auriez gagner en productivité ;)
[^] # Re: révolutionnaire !
Posté par Gabriel . Évalué à 1.
Ce qui de toutes façons demande 6 mois-un an.
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Déjà en avance pour son époque :)
AMHA, son auteur, Bertrand Meyer, en dehors de l'homme lui-même, a des idées et des conceptions que bon nombre d'entre nous, et particulièrement les concepteurs de langages objet, devrait s'inspirer.
Sinon, non, ce n'est pas qu'un langage d'université. Il est vrai qu'en France il est surtoût connu dans ce milieu. Mais aux Etats-Unis il est utilisé dans l'industrie et semble être apprécié dans certains cercles du milieu embarqué là bas.
Tu parles d'événements et de meta-donnés. Si tu veux vraiment faire de la méta programmation, je te recommande fortemement Smalltalk-80 ou Squeak (une version Smalltalk-80 orientée multimédia).
Quant à C#, je le vois avant tout comme une action marketing de Microsoft à l'encontre de Sun. C# 1.x est un java like de Microsoft, C# 2 est une avancée pour incorporer des mécanismes minimum que font de lui un langage objet à typage statique suffisamment utilisable (que Java n'était pas AMHA et qu'il va l'être avec Java 1.5), ceci afin de répondre à la réponse de Sun avec Java 1.5.
Si dans tout ça, nous développeurs, on trouve notre bonheur tant mieux.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . Évalué à 2.
Si tu veux vraiment faire de la méta programmation, je te recommande fortemement Smalltalk-80 ou Squeak
Je veux pouvoir en faire quand j'en ai besoin. Tu me conseille Smalltalk, c'est d'ailleur entre autre de ce langage que s'est inspiré C#. Je préfère utiliser un langage qui est un bon compromis entre fonctionnalités, performances et confort plutôt qu'un langage "joli" mais parfois dur à apréhender. Pour moi le langage doit être là pour me permettre d'exprimer des concepts avec le maximum de confort, sans avoir à trop réfléchir. Ce pourquoi par exemple je n'utilise jamais l'héritage multiple, sachant pertinament que celà va m'obliger à me poser pleins de question quand à aux conséquences. C'est de ce principe qu'est parti le concepteur de C#, c'est pourquoi il n'y a pas d'exceptions rattrapées, c'est pourquoi il n'y a pas d'héritage multiple, c'est pourquoi les méthodes sont finales "par défaut".
Tu peux voir si tu veux le C# comme une opération marketing. Il est évident que ce langage a été développé pour concurrencer Java. Mais ce que j'ai trouvé positif, c'est qu'ils ont vraiment ajouter des petits "+" qui ont su faire la différence en terme de confort et aussi de productivité (réutilisation aisée de code), bref ils ont voulu apporter des nouveautés par rapport au concurrent : c'est d'ailleur pourquoi il a eu beaucoup de succès, et c'est pas pour rien que Java reprend la plupart des petits "+" qui font la différence. C# répond à de vrais besoins, pas à des jolies théories objets.
Après on peut argumenter pendant des heures sur le fait que C# ne suit pas correctement le dernier paradigme objet à la mode avec toutes les fonctionnalités qui font la beauté d'un vrai langage objet, mais ce n'est absolument pas le but de ce langage : il existe pour répondre à des attentes, et les nouveautés apportées apporte un véritable "+" pour la plupart des utilisateurs, et pas seulement les experts. D'ailleur tu sembles clairement indiquer que Java n'était pas pour toi suffisament utilisable par rapport à d'autres langages comme Eiffel. Pourtant pour beaucoup de développeurs, l'histoire a montré que leur point de vue n'était pas du tout le même, et qu'ils n'avaient pas du tout la même notion d'un langage utilisable.
C# et Java ce sont des langages pour la "masse" de développeurs, des langages tout public si on veut, pour la plupart des programmeurs. Je ne vais pas comparer à Eiffel que je ne connais absolument pas, mais à d'autres langages comme OCaml par exemple, qui sont certes très joli et procure une certaine satisfaction lorsqu'on n'a réussi à appliquer à la perfection un concept du langage, mais qui par contre sont destinés à des programmeurs qui aime bien se "branler" le cerveau (excuse moi pour l'expression, mais je trouvais qu'elle correspondait bien ;) )
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Il est vrai que la perception d'un langage "utilisable" dépend de chacun. Ma perception est : "s'exprimer simplement, de façon élegante, sans à faire du contorsionnisme ou du bidouillage pour arriver à mes fins et avec une syntaxe simple."
Ainsi, pour l'avoir utiliser, dans les langages à typage statique, la covariance et la généricité contrainte apportent une souplesse très importante.
Le fait aussi de pouvoir affiner la visibilité au niveau classe pour telles ou telles méthodes (par exemple, telle méthode n'est accessible que pour les objets de telle classe) permet d'implémenter de façon élegante un certain nombre de patterns (visual proxy, factory, etc.) sans se compliquer les méninges.
Je suis d'accord que Java et C# sont des langages de masse, et comme bcp de chose destinée à la masse, le résultat est obtenu par "un équilibre par le bas".
Quant à Smalltalk, AMHA je ne pense pas que c'est de la "masturbation intellectuelle" :) Je pense plutôt que c'est une façon de pensée différente de ce que l'on a l'habitude (un peu comme GNU/Linux pour les windowsiens). J'ai l'impression que toute notre vie, et particulièrement professionnelle, on nous "lobotomise", on nous "écrase" par nous imposer des limites dans notre champs de perception. Or, pour avoir codé avec, Smalltalk nous offre un moyen d'exprimer pleinement nos capacités, limitées ou non. Elle offre à notre perception ce qu'est en fait l'univers : infinie où toutes choses se mouvoient et changent ; chose que l'on a perdu, peut etre depuis l'enfance, à percevoir.
Une fois que tu connais la syntaxe de Smalltalk (qui n'est pas difficile en soit), et que tu as passé le plus difficile (un champs de perception non limitée), alors tu peux exprimer de façon très simple et élegante des solutions complexes.
Pour moi, la "masturbation intellectuelle" dans le développement est de trouver des solutions de coutournement des limitations d'un outil pour arriver à exprimer quelque chose qui se doit d'être évident. D'autant plus si les mécanismes de représenter simplement notre expression existe et avec une syntaxe simple.
[^] # Re: révolutionnaire !
Posté par tene . Évalué à 1.
http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/43f40(...)
"De même je n'introduit pas non plus la faculté de définir des méthodes supplémentaires à une classe existante ou mieux à des objets ..."
http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/27320(...)
"pas de covariance"
http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/284c5(...)
Les autres trucs sympas: http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/10891(...)
http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/e473c(...)
l'attribut InternalsVisibleTo etc...
Attention, je réalise bien que les solutions proposés ne sont pas toute parfaite!! Mais bon, entre rien et ça... bah vaut mieux ça :p
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Par rapport à l'ajout de méthodes, ton lien ne me donne pas l'information escomptée.
Par rapport à la covariance (et à la contravariance), elle est plutôt restreinte. Applicable seulement aux méthodes de délégation (un mécanisme semblable aux agents d'Eiffel par exemple).
Par rapport aux autres goodies ... hum. Le nullable type n'apporte pas grand chose excepté si le langage a un pb de ... conception. Quant au mot clé 'yield' il est interéssant même si de grandes discussions ont encore lieux par rapport au bien fondé d'un pareil mécanisme.
[^] # Re: révolutionnaire !
Posté par tene . Évalué à 0.
Concernant l'ajout de méthode, il s'agit juste de partial class, ce n'est pas de l'ajout de méthode, mais le concept n'est pas très très loin: écrire une classe en plusieurs partie. Pratiquement c'est plus "esthétique" qu'autre chose. Cependant, est-ce qu'ajouter des méthodes à une classe n'est pas facilement simulable grâce aux events/delegates et à l'héritage?
La covariance est en effet restreinte, mais bon c'est sympa de se dire qu'on l'aura bientôt en C#.
Le nullable type?... j'ai du mal à voir comment tu veux l'éviter tout en restant performant?
Le yield est cependant, amha, le plus intéressant, il devrait permettre de faire certaines choses sympathique, mais personnelement je me demande la qualité du code généré derrière.
Enfin voilà, ça va viendre, et perso, j'ai plutôt été convaincu par le C# et .NET... surtout le couple des deux en fait... mais bon, on a pas encore le langage idéal, celui qui fait le café! :p
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
(Java signifie café en argo anglais.)
Sinon, par rapport au nullable type, une solution de conception du langage, plus élegant à mon avis, peut être celle d'Eiffel : un objet prédéfini Void qui est de type NONE, lui même descendant de toutes les classes de ton appli. Bref, autrement dit pas une bidouille que doit se tapper le développeur.
Je suis pour faciliter la vie des développeurs (donc au détriment du ou des concepteurs de langages). Malheureusement, c'est souvent l'inverse que l'on observe : le concepteur qui facilite sa vie au détriment du développeur qui doit utiliser son langage.
Par rapport à C# et .NET, je trouve que ce sont des outils interessant.
Le seul truc qui me fait tiquer, c'est qu'ils viennent de Microsoft et je me méfie de ses produits. Souvent c'est : au début ça parait super, à l'utilisation c'est finalement plus limité que prévu, et à la fin, au fur et à mesure des évolutions, c'est le cauchemar ... mais c'est trop tard (faut comprendre : l'existant, les licences, les développeurs qui ne connaissent que ça et tout ça).
[^] # Re: révolutionnaire !
Posté par Philip Marlowe . Évalué à 1.
Ca fait du bien de lire ça. Je n'envie pas les programmeurs en Java ou en C#. Design By Contract, héritage y-compris multiple et même répété (comprenant l'héritage dit en diamant, mais pas seulement), généricité, le tout accessible avec une syntaxe claire, une fois qu'on y a goûté c'est difficile de revenir en arrière. Si je dois un jour passer au C# ou à Java, je sens que je vais souffrir...
[^] # Re: révolutionnaire !
Posté par Philip Marlowe . Évalué à 1.
[^] # Re: révolutionnaire !
Posté par tene . Évalué à 2.
glurps (discuter plus bas, par des gens qui ont plus de compétences que moi...)
"La plateforme Java/J2EE, standart, extrémement compléte, sans aucune lacune."
glurps... J2EE c'est quoi? un amas de techno plus ou moins bien (ou mal) pensée mise ensemble avec un joli nom... standard? ISO? ECMA?... de fait? complète? pourtant on en est toujours à utiliser un paquet de lib qui tourne autour de java... (log4j, junit, struts, hibernate, etc...). Ca ne veut pas dire que c'est mauvais, mais faut pas pousser non plus... T'as touché à quoi d'autre que java...?
"La machine virtuelle : qui, dans un monde utopique, offrirai la portativité absolue"
Dans ton monde idéale, tous les ordinateurs seraient alors les mêmes...
[^] # Re: révolutionnaire !
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
J2EE est un standard en ce sens qu'un certain nombre de gens se rassemblent pour le définir et le faire évoluer et ensuite.
Mal pensé ? vas falloir te justifier.
Et le but n'est pas de définir des libs autour...
log4j d'ailleurs n'a plus a être utilisé ( intégré au jdk )
junit n'a rien avvoir avec une plateforme, il permet de tester
struts est une surcouche "jsp et servlet" qui eux fonrt partie de J2EE, struts met juste en place de modèle MVC qui n'a pas a être définie dans la norme
hibernate est une api de persisitence hors norme comme il en existe bien d'autre...
La portabiltié absolue n'a jamais été promise... juste une portabilité sur les plateformes ou une jvm est dispo.
http://about.me/straumat
[^] # Re: révolutionnaire !
Posté par tene . Évalué à 1.
Alors tous est standard :p
Mal pensé? Parle moi de l'implémentation des generics en java :p ou des évolutions de J2EE offrant la joie de casser du code existant :p... si tu veux des idées générale: problème potentiel de scalability, abstraction parfois abusée, etc... Attention je ne prétends pas que J2EE, c'est nul! au contraire, je l'utilise tous les jours, mais de là à en faire une solution "sans aucune lacune", faut pas pousser...
Je me demande sinon, comment tu définis ce qui doit être ou ne pas être intégré dans la norme? Tu te bases sur quel critère? Perso j'ai tendance, mais c'est un pt de vue de pauvre développeur, à me dire que quand j'en ai besoin et que je l'ai pas, c'est que ça manque... ce qui a pour conséquence directe qu'aucune API n'est vraiment complète... d'un côté heureusement, ça nous fait du boulot, mais d'un autre, ça rend l'API perfectible... (ceci dit, c'est évidemment à relativisé, mais c'est un choix amha trop compliqué que pour être résumé à "c'est complet", "c'est pas complet").
"La portabiltié absolue n'a jamais été promise... juste une portabilité sur les plateformes ou une jvm est dispo. "
Qui est en effet vraie dans un monde utopique, en pratique, tu te retrouves quand même à devoir tester ton appli sur X plateforme, et apporter certains changements... t'as déjà essayer de porter une appli swing sous macosx? :p
Ceci dit mon post n'était qu'une réponse... n'y vois pas une négation de tous ses propos, juste une tentative de relativisation ;)
[^] # Re: révolutionnaire !
Posté par Mouns (site web personnel) . Évalué à 1.
a moins que quelqu'un est un truc propre pour modeliser les dependances entre :
polygone, quadrilatere, trapeze, losange, rectangle et carré.
ou entre les triangles.
je dis ca, car quand on fait des animations, les propriétés de certaines figures permettent de gagner du temps de rendu ...
... mais bon, aujourd'hui, à la force brute ( cf ATI et nVidia ) on y arrive ... alors pourquoi se faire chier ?
[^] # sortez couvert de certitudes, ca evite d'attraper la maladie du doute
Posté par Mouns (site web personnel) . Évalué à 4.
je demande une explication sur comment faire pour respecter l'heritage en java, puisqu'un carré est un rectangle et un losange ?
ou pour le triangle isocele rectangle voir l'equilateral ?
quand on fait du rendu 3D avec des polygones, si on ne rend que des triangles, les propriétés geometriques du triangles influent sur l'algo de rendu d'un triangle quelconque.
et quand on fait de l'animation, les isometries spatiales simplifent grandements certains calculs de mouvement.
mais bon, maintenant que l'on a des Go et GHz, plus besoin de faire de l'optimisation ...
( moinsissez moi au lieu d'aller ouvrir un bouquin d'algo en 3D ou de maths )
[^] # Re: sortez couvert de certitudes, ca evite d'attraper la maladie du dout
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: sortez couvert de certitudes, ca evite d'attraper la maladie du dout
Posté par Mouns (site web personnel) . Évalué à 1.
[^] # Re: sortez couvert de certitudes, ca evite d'attraper la maladie du dout
Posté par Mouns (site web personnel) . Évalué à 1.
[^] # Re: sortez couvert de certitudes, ca evite d'attraper la maladie du dout
Posté par celastus . Évalué à 2.
C'est un peu comme si vous disiez, comment faire une base de données sur les animaux d'un parc naturel sans héritage multiple, alors que certains animaux sont à la fois damifferes et des invertebrés...
[^] # cachez ce sein que je ne saurai voir
Posté par Mouns (site web personnel) . Évalué à 2.
je parle de rendu 3D, donc un carré est rectangle sur un rendu dont au moins un coté est parallele à un axe du repere, et un losange sinon.
parce que rendre un rectangle penché est chiant, alors qu'un losange ( 4 triangles rectangles et pour le carré, isoceles rectangles ) ca roxorisationne au point de lapider une mémé !
donc choisir une strategie de rendu en fonction d'un angle permet de faire de l'optimisation à la volé avec un seul test.
un produit scalaire du vecteur normal à la surface avec l'axe de profondeur permet de savoir si tu dois rendre la surface.
pour rendre un triangle, il suffit de tracer des lignes horizontales ( ou verticales ) en suivant la direction de 3 segments ( plus exactement deux d'un cote et un de l'autre ).
maintenant, tu prend une surface parametrique, tu la rend. tu fais comment ? ( le premier qui ose -> [] :) )
... tu derives les fonctions, tu en tire des vecteurs direction. pour un rendu rapide, tu cherches une progression tel que tu ne rend pas sous le pixel. le produit vectoriel des deux vecteurs directions d'un point donne un vecteur normal qui donne l'orientation de la surface, pour en zapper des bouts.
ca à l'air compliqué, mais ya tout plein d'algo rapide pour faire ça :)
mais bon, c'est plus facile d'innonder son bus AGPx8 et saturer le hard plutot que de faire de simples additions sur son Pentium IV 3GHz avec hyperthreading ...
[^] # Re: cachez ce sein que je ne saurai voir
Posté par gc (site web personnel) . Évalué à 4.
Moi je trouve ça pas très crédible et je pense que ce sont des artefacts pour parer au fait qu'on n'a pas d'héritage multiple - mais encore une fois il faut que je regarder Tomcat/Eclipse quand même.
[^] # Re: cachez ce sein que je ne saurai voir
Posté par Mouns (site web personnel) . Évalué à 4.
ca me fait penser à un truc en prog objet ...
-- pourquoi tout le monde fait plein de test dans un prog objet ? --
l'heritage permet de zappé cela.
la programmation objet sans couche d'introspection est une cata, java fait cela comme un sagouin.
tiens, un truc "cool" à faire en java ... je l'ai fait quand j'ai fait un "toolkit XML" pour faire du "rendu SWING" ( en gros un XUL like sans XUL ) ...
tu veux rajouter une methode à tous les composants swing ? tu fais comment ?
- de l'instrospection pour generer des classes à la volée ... simple ... sauf qu'en java ca pue
- soit tu fais de l'heritage multiple ... simple ... sauf qu'en java ca pue aussi
- soit tu fais des classes de serialisation / rendu, et cela devient vite inmaintenable
- reste une methode lourde : se taper toutes les classes et leur coller une interface, et au choix :
* copier / coller une methode generique pour la serialisation
* faire des zoli cast de classes ( et ca derange personne de faire un cast en java ) pour recuperer la methode dans une autre classe
en gros, c'est crade à mort si tu veux que cela soit un peu rapide ( ct pour les GUI d'un centre de supervision de serveurs et routeurs ), et meme avec ça, c'était lent.
[^] # Re: cachez ce sein que je ne saurai voir
Posté par TImaniac (site web personnel) . Évalué à 3.
Plus sérieusement, même si la méthode ne te plait pas, AspectJ ca marche très bien, et rien ne te dis que le compilo de ton langage qui tue ne fait pas de trucs aussi crade derrière.
[^] # Re: cachez ce sein que je ne saurai voir
Posté par Romain Guy . Évalué à 3.
[^] # Re: cachez ce sein que je ne saurai voir
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: cachez ce sein que je ne saurai voir
Posté par Romain Guy . Évalué à 2.
Si si promis, il parlait d'interface graphique, *aussi* :-) Pour ajouter des méthodes aux composants Swing, tu peux, dans une certaines mesure, étendre les objets UI et placer tes méthodes dedans. Ce n'est pas le plus élégant dans certains cas mais ça à le mérite de marcher. A condition de ne pas vouloir changer de look and feel tout le temps.
[^] # Re: cachez ce sein que je ne saurai voir
Posté par Mouns (site web personnel) . Évalué à 1.
[^] # Re: cachez ce sein que je ne saurai voir
Posté par TImaniac (site web personnel) . Évalué à 2.
Sinon je capte pas trop l'intérêt de vouloir rajouter une méthode à toutes les classes Swing... c'est pour quoi faire ? C'est quoi le pattern par derrière que je vais utiliser tous les jours qui me dis que franchement me faut cette killerfeature dans le langage ?
[^] # Re: cachez ce sein que je ne saurai voir
Posté par Mouns (site web personnel) . Évalué à 1.
l'interet ...
bon, je t'explique le truc de l'epoque ( 2001 ) :
faire un toolkit de rendu de GUI portable pour faire de l'admin d'un NOC.
donc, j'ai codé deux trucs :
- un systeme de construction à partir d'un fichier XML d'une interface SWING ( pour java ) ou GTK ( pour perl )
- un langage de programmation embarquable dans le XML pour gerer les interactions entre objets XML.
le tout était orienté scenario applicatif.
donc en gros, on avait des objets qui prenait des evenements. ces objets etaient empilé et apres j'operais sur la pile et je depilais dans l'ordre inverse.
j'avais des composants swing que je devait empiler et depiler sachant que ct une serialisation propre au composant ( ou à sa classe ).
[^] # Re: cachez ce sein que je ne saurai voir
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: cachez ce sein que je ne saurai voir
Posté par Mouns (site web personnel) . Évalué à 1.
donc j'ai derivé JComponent et toute les autres ( merci perl ) en collant des interfaces. et selon l'appartenance à l'interface, je castais differemment mon objet en un autre pour executer ma methode generique ... ( beurk, je me croyais faire du C et niveau souplesse du code c a chier :( )
pour ce qui est des metadata ...
j'utilisais le java.lang.reflect pour mon compilo à la volée, et ca volait pas haut au niveau des perfs.
conclusion, c pas cool de manipuler du java en java, et c pire de generer du java à la volée.
# A comparer plutot au C#
Posté par mosfet . Évalué à -1.
J'ai l'impression que Sun veut surfer sur la mode C#/.Net et rajoute vite fait bien fait des caractérisiques qui n'auraient peut etre jamais vu le jour si C# n'était pas passé par la.
[^] # Re: A comparer plutot au C#
Posté par Quentin Delance . Évalué à 10.
1) C# n'existerait probablement pas sans Java ; sans rire regarde un peu le nombre d'idees repompees sur Java par le C#. Alors oui aujourd'hui c'est Java qui reprend des choses mais ce n'est qu'un juste retour des choses
2) SUN ne surfe pas sur la mode C# Tout simplement parce que si l'adoption de C# se fait petit a petit je ne sens pas une grande mode. Au debut oui avec les effets d'annonce de M$ mais depuis la mode retombe un peu. On se rend compte que c'est une plateforme prometteuse mais qui n'a definitivement pas le niveau de maturite de Java et encore moins la meme communaute derriere (Eclipse, Tomcat, Hibernate, JBoss)
[^] # Re: A comparer plutot au C#
Posté par TazForEver . Évalué à -1.
[^] # Re: A comparer plutot au C#
Posté par Emmanuel Hugonnet (site web personnel) . Évalué à 6.
Meem si la dessus je ne defendrai pas Sun, avec son histoire de ne pas couvrir OO :(
[^] # Re: A comparer plutot au C#
Posté par TazForEver . Évalué à 1.
[^] # Re: A comparer plutot au C#
Posté par Christophe Fergeau . Évalué à -1.
[^] # Re: A comparer plutot au C#
Posté par TazForEver . Évalué à -2.
[^] # Re: A comparer plutot au C#
Posté par Emmanuel Hugonnet (site web personnel) . Évalué à 8.
Tu as 5 versions sur le site de Sun mais tu sembles ne pas savoir qu'il n'y a pas que Sun dans l'histoire de Java.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par Malrog Malrog . Évalué à 0.
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 1.
Soi dit en passant les dernières JVM d'Apple sont maintenant tout à fait performantes (et stable, ce qui n'a pas tjs été le cas).
[^] # Re: A comparer plutot au C#
Posté par tanguy_k (site web personnel) . Évalué à 5.
Et quelque chose empeche d'avoir la meme chose pour Java ?
Non, rien et d'ailleurs c'est meme en train de se faire.
De facon generale je rappelle que Java n'est pas moins libre que C++, C, C# ou meme UNIX.
Java c'est des specifications et un ensemble d'API, libre ensuite a chacun de programmer une implementation. Linus Torvalds a cree Linux il l'a voulu compatible avec UNIX, tout comme GCC implemente C++ et le C. Bref s'il n'y a pas d'implementation libre correcte de Java c'est pas de la faute de Sun mais c'est de la faute des developpeurs de logiciels libres. Apres il est vrai que si Sun pouvait mettre Java sous LGPL ca serait "sympa".
Au moins ce qui est clair c'est que Sun ne mettra pas de batons dans les roues de projets libres Java contrairement a Microsoft. Je suis persuade que si une implementation de .NET est trop presente, Microsoft se donnera les moyens de renverser la tendance.
[^] # Re: A comparer plutot au C#
Posté par TazForEver . Évalué à 1.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
tu peux facilement faire un programme Java et le faire tourner sans aucun soft de sun !
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par Yusei (Mastodon) . Évalué à 6.
Prenons un exemple pratique: à l'heure actuelle j'aimerais bien pouvoir exécuter le logiciel FreeMind avec des logiciels libres. Je ne peux pas, à moins d'une solution miracle que je ne connais pas.
Tu pourrais rétorquer que ce n'est pas la faute de Sun si la communauté du libre ne propose rien de compatible, mais ça ne change rien pour l'utilisateur de base qui veut juste exécuter son programme...
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par allcolor (site web personnel) . Évalué à 0.
2- BEA c'est pas libre non plus.
Donc oui y a pas de problème pour développer en java... mais il y en a un peu pour déveloper en java pure libre... c'est dommage, mais je suis convaincu que ça ne tardera plus trop... (enfin je fait la méthode coué depuis quelques années).
[^] # Re: A comparer plutot au C#
Posté par Sylvain Sauvage . Évalué à 2.
Ben si : du fait de la licence imposée par Sun, il est impossible de proposer une mise en ½uvre alternative de Swing (que cette alternative soit libre ou non).
[^] # Re: A comparer plutot au C#
Posté par tanguy_k (site web personnel) . Évalué à 6.
C'est impressionant, a chaque news sur Java toujours les memes ragots qui sont ecrits et re-ecrits. Vous en avez pas marre de raconter des conneries a longueur d'annees ?
Expliques moi en quoi Sun rends impossible une implementation de JVM/Swing en libre ? rien, la preuve ils l'ont deja fait:
http://forum.hardware.fr/forum2.php?config=hardwarefr.inc&post=(...)
http://gcc.gnu.org/java/(...)
http://www.gnu.org/software/classpath/(...)
http://www-124.ibm.com/developerworks/oss/jikes/(...)
ect...
Si la communaute ne s'investie pas aussi dynamiquement dans l'implementation d'une JVM libre, c'est pas de la faute de Sun. C'est aussi probablement parceque les JVM existantes suffisent. De meme que ce n'est pas de la faute a Microsoft si Mono avance tres vite. De toute facon si Mono ne le fait pas, c'est pas Microsoft qui va fournir .NET sous Linux/*BSD contrairement a Sun avec Java. Mon avis est que le monde Java est infiniment plus ouvert a tous les niveaux que celui de .NET par exemple.
[^] # Re: A comparer plutot au C#
Posté par Sylvain Sauvage . Évalué à 0.
Voir http://www.debian.org/doc/manuals/debian-java-faq/ch5.html(...) ,
notamment la section 5.3.1
rien, la preuve ils l'ont deja fait : [...liste d'exemples...]
Faire n'est pas droit.
De plus, SWT n'a pas l'api de Swing, SwingSWT l'a (à la distinction près du nom des paquets) ce qui le rend tangent, Classpath a décidé de « braver » Sun (en se « protégeant » par le refus des développeurs ayent eu accès au code de Sun, c'est-à-dire tous ceux qui ont téléchargé un jsdk de Sun un jour).
Pour revenir au message de départ : faire fonctionner l'application X (en l'occurrence freemind) avec n'importe quelle JVM n'est pas encore possible. Par exemple, SWT et SwingWT demandent une modification et une recompilation du source (pas toujours disponible).
[^] # Re: A comparer plutot au C#
Posté par tanguy_k (site web personnel) . Évalué à 3.
- la licence des logiciels appartenant a Sun
Ca je m'en fou, c'est le business de Sun.
- l'utilisation des noms de packages java et sun
[You] may not create, or authorize your licensees to create
additional classes, interfaces, or subpackages that are
contained in the "java" or "sun" packages or similar as specified by
Sun in any class file naming convention;
Pourquoi ils ont fait ca ? simplement pour se premunir d'entreprises (Microsoft au hasard) qui pourraient ajouter des classes java.bidule et laisser penser qu'elles font partie de Java. Sun a peur que des versions incompatibles de Java apparaissent et le passé leur donne raison. Quant a la restriction sur les packages en utilisant le mot sun, ca me semble evident.
Rien n'empeche de faire des packages gnu.org.swing c'est techniquement pas un gros probleme de faire un script qui renomment les noms automatiquement.
De plus je ne suis pas persuade qu'implementer swing dans son coin en utilisant comme nom de package javax.swing soit un gros probleme vu que le paragraphe s'applique aux ajouts. Le mieux c'est encore de demander a Sun parceque la remarque de Debian [1] ne clarifie rien.
[1] it is unclear whether or not the word 'additional' includes reimplementations of existing classes, or whether it applies only to classes with new names.
Enfin pour la remarque toujours sur le site web de Debian:
Sun has made public statements in connection with their legal strategy in the Sun-Microsoft lawsuit that indicate that the company considers the published specifications of Java2 to be intellectual property that can not legally be used by persons involved in efforts to create Java2 clean-room implementations.
J'attend de voir des ecrits de Sun a ce sujet parceque j'ai pas trouve. Le seul truc que j'ai trouve indique justement le contraire: http://lists.debian.org/debian-java/2002/02/msg00156.html(...)
Les multiples re-implementations de J2EE dont une a ete certifiee [2] ne posent pas de probleme alors pourquoi J2SE poserait un probleme ? Et sur le CVS de Kaffe on peut voir des classes Java2 je me pose donc des questions sur la justesse des propos sur le page web de Debian.
[2] http://linuxfr.org/2004/07/19/16847.html(...)
De toute facon dans le pire des cas tous ces problemes s'appliquent aussi a .Net/Mono
[^] # Re: A comparer plutot au C#
Posté par Croconux . Évalué à 2.
Et en quoi est-ce différent pour DotNet? Prend un programme fait avec le framework .net de MS et essaie de le faire tourner sur Mono. Tu aura s les mêmes problèmes. Si le programme en question utilise des classes non présentes dans Mono (using Microsoft.DirectX ?) c'est cuit.
La situation pour Mono est même moins avantageuse que pour Java car .net facilite l'utilisation de bibliothèques natives depuis du code alors que pour Java c'est très fortement déconseillé. Si une appli utilise une DLL native dont le nom commence par MSqqchose je pense que tu aura quelques difficultés à la faire tourner sur autre chose que windows.
[^] # Re: A comparer plutot au C#
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 0.
C'est effectivement une des grosses différences philosophiques entre .NET et Java. Java propose de réinventer la roue pour qu'elle soit portable, alors que .NET propose de ne pas perdre du temps et réutiliser l'existant.
Mais c'est un faux débat de dire que Mono a plus de difficulté que une implémentation de l'environnement Java : Mono doit effectivement porter des API natifs, soit en les écrivant, soit en utilisant d'autres API d'une autre plateforme. Mais pour Java on a le même problème : il faut réinventer la roue et recoder. Même inconvénients. Sauf que la solution .NET laisse plus de liberté, notamment lorsque le multi-plateforme n'est pas une priorité.
Tu vois dès que .NET est sorti, il était possible d'utiliser DirectX. Au même titre que OpenGL ou autre. En Java celà a mis combien de temps ? Tout celà parcque Sun préfère la portabilité à la réutilisation. C'est dommage car .NET propose un meilleur compromis : tu veux réutiliser du code sans perdre de temps ? C'est facile, on vous propose tous les outils adéquates dans le langages, et on vous y encourage. Vous voulez porter votre application ? Faites comme en Java, et réinventer la roue, on vous y encorage également.
[^] # Re: A comparer plutot au C#
Posté par Croconux . Évalué à 3.
C'est clair qu'au lieu de faire du code portable on devrait tous se mettre à coder pour windows et utiliser Wine. Quel progrès.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 2.
> il est de toute façon toujours possibler plus tard
> de résoudre ce problème en faisant ce travail
> supplémentaire
Non il est justement beaucoup plus facile de faire l'inverse.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Je ne parlerais pas de .net mais vas pas dire qu'en Java on réinvente à chaque fois la roue car il y a une API qui est pour l'instant plus grande que celle de la plateforme.net
bien sur, on ne peut pas utiliser directx comme ça... mais je doute que drectx fasse parti des technos prioritaires pour java.
.net te dit en fait : hey prenez la facilité !
Un peu comme du temps où on disait prenez vb + acces, c plus simple !
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 3.
J'ai pas dis à chaque fois. Me faites pas dire ce que je n'ai pas dis ;)
une API qui est pour l'instant plus grande que celle de la plateforme.net
Je suis d'accord, celà est due en partie à la vieillesse de la plateforme Java et justement au fait qu'il faille parfois "réinventer" la roue en Java. DirectX, même si ce n'est pas une priorité, c'était juste un exemple d'API difficilement exploitable en Java, pourtant on peut imaginer qu'une équipe de développement puisse avoir recour à cette techno, propriétaire mais performante. Quand on développe en Java, on s'arrange pour faire avec ce qui est dispo sur cette plateforme, comme tu le soulignes, il y a beaucoup d'API qui ont été portés, cetains étant de simple wrapper JNI (auquel cas c'est comme en .NET, mais en beaucoup moins élégant et pratique) et on ne réinvente pas la roue, mais dans d'autres cas il faut tout recoder.
Je vais prendre l'exemple tout bête du "port" de Quake2 sur la plateforme Java (l'exemple vaut ce qu'il vaut, il faut regarder le point de vue technique) : ils se sont fait chier à refaire un moteur complet (bref réinventer la roue), car impossible d'utiliser l'existant : bref plusieurs mois de boulot par plusieurs programmeurs.
Un autre s'est lancé dans le portage sur .NET : hop il a passé une journée à passer le code original du moteur en C en C++ managed (histoire que ca compile en .NET) et une autre journée de tuning : zou il obtient exactement la même chose, avec une seule commande il compile soit en natif soit en managé, et il obtient les mêmes perfs que l'équipe Java.
Tu vois où je veux en venir ?
Je ne dis pas que c'est toujours le cas (tu ne réinvente pas toujorus la roue !), mais forcer de reconnaître que Java n'aide pas à réutiliser l'existant et a conduit à faire de nombreux API en Java qui existait déjà en natif : beaucoup de perte de temps, avec un avantage : la portabilité.
Moi je préfère faire de la portabilité le jour où j'en ai besoin, plutôt que de m'enmerder avec dès le début parcque je n'ai pas le choix.
Un autre exemple : Mono a vu très rapidement le jour, pourquoi ?
Parcque en très peu de temps on a pu obtenir une plateforme utilisable qui se basait sur un existant fiable : GTK, Mozilla, libxml, Qt, etc. Pas toujours très portable, bien qu'ils aient tout de même choisi leurs technos, ils ont eu rapidement quelque chose d'impressionnant et de relativement stable, en proposant à l'utilisateur des API qu'il connait. En Java je rigole encore du temps qu'il a fallut pour obtenir Swing, sans parler que cette solution est loin d'être parfaite, et question intégration, elle se contente d'essayer d'imiter l'aspect graphique de l'environnement qui l'entour... Clap clap clap. Tout celà parcqu'ils ont voulu réinventer la roue et refaire une couche graphique portable. Résultat : un truc portable, mais un qualité perdue : l'intégration.
.net te dit en fait : hey prenez la facilité !
je dirais plutôt : avec .NET faites simple et utilisez l'existant, soit à travers la simplicité d'utilisation d'API natif, soit à travers le support de nombreux langages permettant de réutiliser du code existant.
[^] # Re: A comparer plutot au C#
Posté par Marc Perron (site web personnel) . Évalué à 2.
Je ne crois pas que l'exemple rend justice au problème. Puisque la compilation de code C en C++ peut, en la majorité des cas, être fait sans pénalitée (c-à-d, le C est quand même du C++ valid malgré que l'inverse ne soit pas vrai). Traduire un program du C en Java prendra naturellement plus de temps. Je crois qu'une meilleur comparaison serait de prendre un program écrit en Delphi, par exemple, et de produire une nouvelle impémentation pour chaqu'une des platformes. Ça ferais une plus juste comparaison à mon avis.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 1.
Ça ferais une plus juste comparaison à mon avis.
Pas du tout, celà fait parti d'un des atouts majeurs de la plateforme .NET : elle a été pensé multi-langages, afin notamment de pouvoir programmer dans celui qu'on veut (même si certains sont plus adaptés), mais aussi pour pouvoir réutiliser facilement l'existant. Pareil pour la faciliter d'utiliser des APIs natifs : réutiliser l'existant. A l'opposé Java n'encourage pas à réutiliser l'existant lorsqu'il est natif et ne cherche pas faciliter l'intégration d'autres langages sur sa plateforme.
[^] # Re: A comparer plutot au C#
Posté par Pierre Tramonson . Évalué à 3.
Il n'y a pas eu de réutilisation du code existant.
Ca ne veut pas dire que ce n'est pas intéressant dans certains cas !
Mais j'ai constaté que souvent homogénéiser les applis et les langages de dev cela va de pair.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
et rappellant au passage que Mono a environ 18 mois de retard sur Microsoft... ca représenté quoi 18 mois en informatique ?
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 1.
A condition que Sun veule bien. même si Sun n'est pas seul à décider, Sun "choisi" son entourage, l'indépendance du JCP est toute relative.
[^] # Re: A comparer plutot au C#
Posté par Romain Guy . Évalué à 3.
[^] # Re: A comparer plutot au C#
Posté par boubou (site web personnel) . Évalué à 3.
C'est ouvert, mais Sun garde le contrôle...
[^] # Re: A comparer plutot au C#
Posté par Romain Guy . Évalué à 1.
[^] # Re: A comparer plutot au C#
Posté par boubou (site web personnel) . Évalué à 1.
Oui, enfin, le texte du JCP est quand même bien pourri, j'ai du cherché pour retrouver la référence au droit de veto, donc tu es bien pardonné ;-)
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 3.
Justement, c'est ce que j'ai fait : pourtant ce que je dis est parfaitement vrai :
"Participation as a Member requires you or your organization to sign the Java Specification Participation Agreement (JSPA). The JSPA is a one-year, renewable agreement between you and Sun Microsystems, Inc."
Même si Sun ne contrôle pas les décisions à l'intérieur de l'organisation, c'est Sun qui décide au cas par cas qui a le droit de rentrer ou non. Mais bon, ton commentaire semble plus pertinent, et pourtant tu ne démontres en rien mon affirmation. (elle ne me contredis pas, tes propos étant également exacts)
[^] # Re: A comparer plutot au C#
Posté par Romain Guy . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par Gabriel . Évalué à 3.
Il ne travaillait pas pour les gros (Oracle, Sun, IbM, BEA, JBoss, Apache, et j'en oublie)
Il avait simplement envoyé son CV.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à -1.
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: A comparer plutot au C#
Posté par Julien Wajsberg . Évalué à 3.
Ils sont pas plus en retard sur la réimplementation de ce que je vais appeler le "Framework" que ce que l'est Mono.
[^] # Re: A comparer plutot au C#
Posté par Croconux . Évalué à 2.
Mono s'est concentré sur l'implémentation de ce qui figure dans la norme ECMA (c'est à dire les bases). Du coup ils peuvent facilement sauter comme des cabris en disant "ça y est on a fini". C'est un peu facile. Côté java, les packages de base aussi ont été réimplémentés.
Il me semble qu'au niveau status c'est kifkif.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Et nivo plateforme :
http://rss.zdnet.fr/actualites/technologie/0,39020809,39163418,00.h(...)
18 mois de retard
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
Pour ce qui est du langage en soit, Mono va aussi vite que MS, ayant tous les 2 les spécifs en même temps. Là Sun est seul à sortir une implémentation du langage Java version "5" : c'est pas la même réactivité, pourtant dans le consortium JCP il y a des acteurs "professionnels" comme IBM... Mais bon faut dire que les spécifications définitives de Java 5 ont vraisemblablement permis à tous de partir en même temps : http://www.jcp.org/en/jsr/detail?id=924(...) ...
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 4.
Pour Java, il faut comprendre la plate-forme dans son ensemble, et la difficulté vient essentiellement de la mise à jour des librairies (au niveau de la JVM les nouvelles fonctionnalités sont relativement simples à implémenter). En revanche si tu considères, Mono + dotNet, tu t'exposes exactement aux mêmes problèmes, en pire, car les api M$ sont énormes, peu documentées, et sujettes à des évolutions sans préavis. (cf Wine).
Maintenant, comme dans Mono, rien n'empêche une appli Java d'appeler des fonctions natives, ex. http://java-gnome.sourceforge.net/news.en.html(...) . Et tant qu' à faire du non portable, tu peux utiliser GCJ et CNI (plus simple et + rapide que JNI).
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
tu oublies la pile "Microsoft" dans les API de Mono, qui visent à recoder tous les API de MS, même ceux qui ne sont pas normalisés. Et ils vont plutôt vite. Donc c'est exactement le même combat que pour ClassPath par exemple.
Pour Java, il faut comprendre la plate-forme dans son ensemble
Pareil pour Mono.
les api M$ sont énormes, peu documentées, et sujettes à des évolutions sans préavis. (cf Wine).
N'importnawak.
les APIs sont énormes, OK. Ceux de la plateforme Java aussi. peu documentées ? mdr. Qui est-ce qui se plaint tout le temps que la MSDN est imbittable parcqu'il y a trop d'info ? Elle demande un temps d'adaptation, mais quand on sait où est quoi, il y a des tonnes d'infos, bien plus que sur le site de Sun. Sans parler des sites de programmeurs autre que MS (idem pour Java). Là on parle plus particulièrement du framework .NET, et la documentation est très très complète, avec de nombreux exemples, toutes les spécifs, etc. Et ça ne change pas du tout sans préavis comme tu dis : il n'y a qu'une révision par an en gros, avec comme partout des avertissements (deprecated) et principalement des ajouts, histoire d'assurer une compatibilité.
Pour Wine, c'est la couche bas-niveau des API Windows qu'ils copient, ce n'est pas du tout pareil. Il y a 2 ou 3 trucs qui ne sont pas documentés parcque non destinés à être utilisés (ou alors jsute par Word et Outlook ;) ) Sinon le reste ne bouge strictement pas, la plupart des vieilles applications tournent toujours sous XP, même s'il faut mettr un mode d'émulation, ceci étant due à des différence d'architecture plutôt qu'à des différences d'API.
Bref tu dis vraiment n'importe quoi.
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 1.
J'oublie rien du tout. Vu sur le site Mono.
http://www.mono-project.com/about/licensing.html(...) (Q131)
Mono dans sa version actuelle n'implémente que le minimum du framework .Net soit les core class couverte par la norme ECMA + qq autres. C.a.d trés peu. Impossible de faire tourner une appli Win.Forms.
> Et ils vont plutôt vite
J'espère pour eux... car y a du boulot.
> Il y a 2 ou 3 trucs qui ne sont pas documentés parcque non destinés à être utilisés (ou alors jsute par Word et Outlook ;) )
C'est justement pour ça que j'ai pas trop confiance en M$...
> Bref tu dis vraiment n'importe quoi.
Je pense que je suis pas seul ici dans ce cas...
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben voyons. J'ai comme l'impression que tu n'as absolument aucune idée de l'étendue du framework .NET, pourtant c'est un peu de la même ordre de taille que le J2EE... Enfin bref, ASP.NET est 100% compatible par exemple, permet de migrer facilement des applications, tu en fais quoi ?
C'est justement pour ça que j'ai pas trop confiance en M$...
si c'est juste parcqu'ils ont oublier de documenter 2 ou 3 fonctions dans des vieux APIs, voilà quoi...
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 2.
>> C'est justement pour ça que j'ai pas trop confiance en M$...
>si c'est juste parcqu'ils ont oublier de documenter 2 ou 3 fonctions dans des vieux APIs, voilà quoi...
Je te trouve un peu naif sur ce coup la :-)
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
Euh, toi tu me dis qu'il manque la plupart des trucs.
Pourtant si tu regardes le volume d'API supportés, ben en gros il manque que System.Windows.Forms, et encore, il est implémenté en partie. Alors dire qu'ils sont loin d'arriver au bout voilà quoi...
Je te trouve un peu naif sur ce coup la :-)
C'est juste que je trouves vraiment petit d'accuser MS de mal documenter ses APIs, alors que dans l'ensemble je trouve ceux de .NET largement plus documentés que ceux de Java.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
Comme je l'ai déjà dis, c'est possible comme dans Mono, mais dans un cas c'est encouragé (avec toutes les facilités qu'offre C# pour, cad la notion de structure, de pointeur, de stack, etc.) et dans l'autre cas c'est déconseillé, avec un JNI inbittable. Heuresement qu'il y a des alternative, mais ce n'est pas du tout la même philosophie entre les 2 plateformes.
[^] # Re: A comparer plutot au C#
Posté par Pierre Tramonson . Évalué à 2.
Pff franchement c'est pas très compliqué par rapport à d'autres aspects de la prog Java, il suffit d'écrire un wrapper.
Bien sur ça n'est pas aussi simple que réutiliser une lib sans rien avoir à faire, mais cela reste abordable.
Tu attaques la plate-forme J2EE sur cet aspect mono-langage, alors que c'est un choix délibéré à l'origine, même s'il y a eu des ouvertures vers d'autres langages depuis, via des APIs en plus.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
Ce que je veux dire, c'est que .NET est moins limitant, C# offre tous les outils adéquate, libre aux développeurs de faire leur choix stratégique, dans tous les cas ça se fera avec pas mal de confort.
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 3.
> le code à réutiliser et on y gagne en portabilité.
C'est un gag ou quoi :-)))
Si pour toi la portabilité consiste en une réécriture du code alors là je comprends mieux tes arguments...
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
C'est ce que je reproche à Java : il faut souvent tout réécrire pour tout réutiliser.
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 2.
C'est de toi trois posts plus haut :
C'est pas du tout la même philosophie que .NET, celà a des inconvénients, que j'ai cité, mais ausis des avantages : ils forcent le portage sur la plateforme en réécrivant le code à réutiliser et on y gagne en portabilité.
et maintenant :
C'est ce que je reproche à Java : il faut souvent tout réécrire pour tout réutiliser
Comprenne qui pourra !!!
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
Ce qui ne contredis pas du tout ma 2ème partie : Il faut souvent passer par cette étape pour réutiliser, même si le critère de portabilité n'est pas un objectif. Avec la solution .NET c'est plutôt : fais comme tu l'sens, on te donne tout ce qu'il faut pour que ce soit portable (donc réécriture, ou parfois quand c'est possible simple recompilation grâce aux nombreux compilateurs), et on te donne tout ce qu'il faut pour réutiliser (notions dans le langage C#), à toi de voir. Tu peux même mixer les 2 si tu veux que la transition soit plus douce, notamment avec le compilo C++ qui mixe à merveille les 2. Un switch à la compilation et je passe du mode natif au mode managed. C'est carrement la classe.
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 2.
La je comprends plus trop, M$ et consorts s'emmerdent à batir le framework .Net pour encourager l'appel de fonction natives. Ils sont masos ces mecs !!!
> l'autre cas [java] c'est déconseillé
Déconseillé, mais possible. (c'est trés différent)
> avec un JNI inbittable
Il ya des générateurs de stub JNI trés bien fait. De plus si tu utilises gcj tu peux toujours te rabattre sur CNI à la fois plus simple et plus performant.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
Comme je vais encore me répéter : là je parles de réutiliser l'existant !!! Je ne vois absolument pas ce qu'il y a de maso de proposer un framework qui permet de réutiliser facilement l'exsistant sans le recoder sur la plateforme, soit en le recompilant si le langage est supporté, soit à travers les possibilités d'appels natifs.
Déconseillé, mais possible. (c'est trés différent)
Et alors ? J'ai dis le contraire peut être ? Effectivement CNI est mieux pour celà, mais il oblige à utiliser gcj non ? Ce n'est pas un peu très limitatif ?
Chez Microsoft ils ont préférer appeler un chat un chat et mettre les pointeurs dans C# quand c'est nécessaire, sans passer par un truc intermédiaire qui cache la réalité mais pas du tout leurs conséquences.
[^] # Re: A comparer plutot au C#
Posté par Pierre Tramonson . Évalué à 3.
[^] # Re: A comparer plutot au C#
Posté par Croconux . Évalué à 5.
Ca n'est pas vraiment le cas. Seuls les namespaces de base sont implémentés. Pour le reste on repassera. Du côté des implémentations libres de java on a un peu plus de choses de dispo.
De toutes façons microsoft enrichira au fur et à mesure le framework. Mono aura toujours un train de retard sur le framework MS, idem pour java vs classpath.
performante
Euh... tu as fait joujou avec Mono? Les performances du JIT sont loin d'être fabuleuses pour le moment. Ce n'était pas la priorité des devs jusqu'à présent.
Tout ça pour dire que je ne comprends pas l'engouement subit pour Mono et surtout le Java-bashing qui l'accompagne. Toutes les avantages que l'on trouve à Mono sont aussi valables pour les implémentation libres de Java, de même que les inconvénients.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Bon, faut voir le bon coté des choses, étant donné le java bashing et le mono bashing.. je pense que ces deux plateformes ont de l'avenir !!!
Je suis à chaque fois étonné de voir le nombre de gens qui adorent poster des "java c'est lent", "java, c'est pas libre", "java, c'est nul", "java, c pas sérieux"....
Ca prouve que les gens sont envieux et donc que ces deux plateformes ont de l'avenir :)
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par TazForEver . Évalué à 2.
Donc oui, Mono est plus complet que tout ce que je peux avoir et ne sacrifie pas les performances.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
je n'utilise jamais la JRE de SUN, celle de BEA ou de IBM et je n'ai pas de problème pour lancer des applis Java.
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par TazForEver . Évalué à 2.
Quand on dit qu'on peut pas faire du Java sérieusement sans le truc de Sun, vous affirmez que si. OK, alors comment ? dis-moi comment sans le JRE de Sun je fais tourner Jext (ou tout autre application graphique (et si t'es chaud NetBeans / Eclipse)) ?
SI C'EST POSSIBLE ALORS EXPLIQUE COMMENT, STP !
[^] # Re: A comparer plutot au C#
Posté par Croconux . Évalué à 2.
Muine je suppose?
un IDE
Monodevelop?
Pas étonnant ces logiciels ont été conçu pour Mono et servent de vitrine technologique. On peut dire la même chose pour Java. Les logiciels qui ont été conçus en n'utilisant que ce qui implémenté dans classpath tournent impecablement.
et si t'es chaud NetBeans / Eclipse)) ?
La comparaison n'est pas très fair play. Essaie de faire tourner une applic conçue pour le framework de MS sur Mono, genre une appli de MS. Tu as le même problème.
[^] # Re: A comparer plutot au C#
Posté par TazForEver . Évalué à 1.
En attendant, ce sont des applications dignes de ce nom, libres et qui fonctionnent sur un FrameWork libre. Je ne peux pas faire la même chose avec Java, quelque soit la mouture que j'utilise.
Je suis pas fair-play ? mais on ne m'a toujours pas dit comment faire tourner ce genre d'application ?
Mono, ça marche.
[^] # Re: A comparer plutot au C#
Posté par zeSixty4Douille . Évalué à 1.
[^] # Re: A comparer plutot au C#
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Au moins pour le bloggeur, le lecteur de mail et les players multimedia.
Je vais me renseigner car je suppose que tu veux utiliser jext ?
J'ai plutot tendance à utiliser JRockit de BEA qui n'est pas libre ;)
http://about.me/straumat
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 1.
http://klomp.org/mark/gij_eclipse/(...)
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . Évalué à 2.
http://www.gnu.org/software/classpath/classpath.html(...)
[^] # Re: A comparer plutot au C#
Posté par Emmanuel Hugonnet (site web personnel) . Évalué à 2.
Parce que franchement les exceptions non checkees en C# ben jamais je m'y ferai
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 1.
Ce que je trouve vraiment dommage avec ce Java5, c'est qu'ils se sont contenter d'ajouter des fonctionnalités de C#, sans les reprendre toutes (poutant il y en a encore des intéressantes, peut être pour Java7 ?), et surtout sans rien ajouter d'innovant. Le pire, c'est qu'ils ont préférer sortir directement les generics dans une implémentation plus que contestable, hors ce genre de choix ne se fait pas à la légère, puisque difficile modifiable... ( http://www.artima.com/intv/generics.html(...) ) Franchement je trouve celà dommage, j'aurai largement préférer une saine émulation entre les 2 concurrents.
Enfin longue vie tout de même à cette plateforme, qui a comme gros avantage une certaine maturité et une communauté très active, autour de projets fédérateurs comme Eclipse.
[^] # Re: A comparer plutot au C#
Posté par Emmanuel Hugonnet (site web personnel) . Évalué à 1.
Je ne considere pas la 'verbosite' (desole pour l'anglicisme) comme un handicap pour la code. Et j'adore ecrire tous ces catch en cascade :P
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
Les concepteurs de C# se sont basé la plupart du temps sur des constats fait auprès d'utilisateurs/ddéveloppeurs, notamment Java. Pas seulement sur de jolis principes théoriques, qui dans ce cas précis n'est pas spécialement joli car empêche par exemple de déclencher de nouvelles exceptions à travers une interface, où laisse carrement des "trous" en cas de changement de version d'une classe sans recompilation de la classe utilisatrice.
[^] # Re: A comparer plutot au C#
Posté par zeSixty4Douille . Évalué à 1.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par Quentin Delance . Évalué à 2.
1) C# n'existerait probablement pas sans Java ; sans rire regarde un peu le nombre d'idees repompees sur Java par le C#. Alors oui aujourd'hui c'est Java qui reprend des choses mais ce n'est qu'un juste retour des choses
2) SUN ne surfe pas sur la mode C# Tout simplement parce que si l'adoption de C# se fait petit a petit je ne sens pas une grande mode. Au debut oui avec les effets d'annonce de M$ mais depuis la mode retombe un peu. On se rend compte que c'est une plateforme prometteuse mais qui n'a definitivement pas le niveau de maturite de Java et encore moins la meme communaute derriere (Eclipse, Tomcat, Hibernate, JBoss)
[^] # Re: A comparer plutot au C#
Posté par Quentin Delance . Évalué à -2.
Allez moinser moi tout ca :(
[^] # Re: A comparer plutot au C#
Posté par Gabriel . Évalué à 4.
Je ne vois pas au fond les immenses différences dans les langages c# et java - à quelques détails près, mais on fait avec ou sans, enfin bon on fait ce qu'on peut. Je n'arrive pas non plus à considérer que l'implémentation du forEach est une révolution.
Niveau architecture il y de belles différences, entre la jvm et .net, d'accord, on en parle souvent. J'avoue ne toujours pas tout à fait me décider pour savoir si mono est une solution viable ou pas. Tout semble en théorie à peu près carré mais j'imagine trop bien que quand m$ voudra mettre à mort mono il aura des prises, qu'il n'a pas sur java. Et l'idée d'être lié à une plateforme... c'est plus simple, plus "on va pas s'embêter" mais je ne crois pas que de faire une solution qui marche partout-mais-surtout-sur-windows soit une idée sur laquelle on peut s'appuyer : si mono se targue de réimplémenter c#, windows aura beau jeu de dire "mais vous voyez avec telle librairie native ça ne marche pas" et hop, mono est déconsidéré (mais je dis cela simplement d'intuition! je saurais incapable de soutenir mon propos devant des bateleurs.) Bref je trouve c# un langage comme il faut mais l'idée de l'implémenter sous linux c'est une excellente idée masochiste.
Tout cela pour dire que vous avez oublié un truc, le truc à mon avis de c# : sa plateforme de dev. Avec Visual Machin vous pouvez faire des applis tranquilles avec la souris. Et cela ne s'adresse pas à la crème de la crème, tous ces purs et durs qui viennent mouler ici, mais aux "développeurs corporates" comme disait Craig Mac Clanahan, c'est à dire à 50% des développeurs qui sont assez bon pour faire leur job tranquillement mais qui ne veulent pas ou ne peuvent pas peaufiner.
En cela mettre à dispo un langage qui a l'aura de java et une capacité à faire des petites applis, c'est...pas mal , non?.... Et ok l'architecture après est pas terrible. Mais ça, pour les petites applis rien de critique. Au contraire, les données s'articulent facilement avec la façon de le présenter: le bonheur! Tu veux voir tes données, elles se mettent toutes seules dans un tableau. Ton chef est content, tu fais du c# et tu rentres tôt.
A quand une plateforme de dev de petites applis jetables sous linux et/ou en java?
Creator? Les jsf?
# nouvelle API de programmation //
Posté par TazForEver . Évalué à 2.
ça me fait bien marrer : je compte plus les fois où je me suis fait rembarrer parce que n'arrivais à faire ce que je voulais avec synchronized. Notemment les mutex récursifs. On m'enguirlandait comme quoi je pensais mal, que j'avais une conception pourrie, etc ...
Ben là, c'est la claque, Sun m'explique maintenant que leur nouvelle API est trop puissante et trop bien pensée ... qu'elle va augmenter ma productivité. Moi je prends à l'envers, je ne pouvais pas faire ce que mes pthread me permettent partout ailleurs.
Idem pour les enum, etc
Ça vaut aussi pour d'autres points : on nous rabat les oreilles pendant des années que c'est fabuleux, mais cette nouvelle mouture de Java est une grosse claque, un bon vieux retournement de veste ...
[^] # Re: nouvelle API de programmation //
Posté par Johann Heymes . Évalué à 2.
J'ai moi même déjà codé des mutex récursifs et je suis loin d'être un demi-dieu...
[^] # Re: nouvelle API de programmation //
Posté par ctof . Évalué à 5.
Java est une formidable reussite et un tres bon outil de developpement.
Java (et par incidence C#) ne serait pas a ce niveau si au depart java n'avait pas ete simple et facile d'utilisation. cela ne veut pas dire qu'on ne peut pas faire n'importe quoi, mais c'est moins facile qu'en C++/C (j'ai moi meme developper 3 anc en C++ en salle des marches).
Cette simplicite n'est pas synonyme de perfection mais d'accessibilte a tous.
La consequence de facto est une multiplication des developpeurs free ou non (mais c surtout les free qui sont importants). c'est ainsi que le monde java est arrive a maturation avec des projects free de qualite professionnel (je pense qu'on peut faire rapidement l'inventaire en C++ ou la comptatibilite entre les compilo etait juste supportee, je ne parle meme pas des template ou c'etait l'enfer, genre entre gcc et celui de sun ....).
On passe aussi les editeurs (meme si je reste fidele a emacs, mais qui demeure mois facile d'acces pour les newbies) qui place les editeurs pre-java au oubliettes (petite exception pour delphi tout de meme).
Bref on ne compte plus les projets GPL ou derives utilisable dans des environement de productions (jakarta*, maven, hibernate, .......) et je ne parle d'une pauvre librairie dans son coin, bugger de partout .
Il est donc normal qu'en touchant plus de personne, les evolutions du langage java se sont fait sentir (surtout apres le pompage de microsoft).
Je ne suis absolument pas sur que java aurait eu un tel succes si la premiere version etait sortie avec les fonctionnalites de la 5.
enfin on peut reprocher a sun ce qu'on veut, c'est aussi une societe commerciale qui doit vivre et je ne pense pas qu'on tarde a voir des jvm free. classpath est en bonne voie et il existe d'autre jvm (nous utilisons par ex JRockit sur linux/i386 qui est plus veloce).
pour parler de java.util.concurrent je presice que ce package est une integration des classes de doug leas deja dispo en jdk1.3
ma seule crainte est que malheureusement face au monstre microsoft (il y a aussi des chose interessante dans C#) et sa puissance en terme de communication/implentation, ce n'est qu'une question de temps ... j'espere me tromper.
Mon discours n'est pas pro-sun ou anti-microsoft mais j'avoue avoir tendance a m'opposer aux situations de monopole quand cela se justifie.
Christophe
[^] # Re: nouvelle API de programmation //
Posté par bmc . Évalué à 1.
[^] # Re: nouvelle API de programmation //
Posté par Anomaly . Évalué à 4.
L'intérêt du mutex récursif, c'est de protéger une ressource dans plusieurs fonctions, mais certaines de ces fonctions peuvent s'appeler entre elles et donc re-verrouiller la même ressource.
[^] # Re: nouvelle API de programmation //
Posté par wismerhill . Évalué à 1.
Plus exactement, un même thread peut acquérir plusieurs fois un lock sur le même objet.
Voir http://java.sun.com/docs/books/jls/second_edition/html/statements.d(...)
[^] # Re: nouvelle API de programmation //
Posté par VACHOR (site web personnel) . Évalué à 1.
Le problème c'est que trop de gens jugent sans savoir. Ils feraient mieux d'étudier un peu le langage avant de crier que c'est nul.
# Mise au point
Posté par Romain Guy . Évalué à 8.
Premièrement les generics ne correspondent pas aux templates du C++ même si leur syntaxe y fait penser. Renseignez-vous sur ce sujet, notamment en lisant les critiques formulées par Bruce Eckel, et vous constaterez que les generics servent principalement à l'autoboxing et pas à grand chose d'autre.
Ensuite concernant le paquet java.util.concurrent il ne s'agit pas d'une initiative de Sun, mais de Doug Lea qui a proposé cette extension en créant une JSR au sein du Java Community Process (voir http://www.jcp.org(...)). Puisque la communauté l'a soutenu, car il est vrai que le modèle d'accès concurrents n'était pas terrible malgré le synchronized, on retrouve ça dans le SDK.
Java 5 n'est pas révolutionnaire car on y trouve surtout des raccourcis syntaxiques. Le problème vient du fait que beaucoup essayent d'y voir une révolution, comme les fameux generics, quand il ne s'agit que d'améliorations censées accélérer un peu le développement sans pour autant le bouleverser. La seule chose réellement novatrice que l'on retrouve dans Java 5 est, à mon avis, le concept des metadata, bien qu'il ne soit pas du tout spécifique à Java. D'ailleurs Python 2.4 propose la même chose :-)
[^] # Re: Mise au point
Posté par ChrisJ (site web personnel) . Évalué à 4.
Par exemple, pour faire un vecteur de chaînes, on devait auparavant créer un vecteur d'Object, et transtyper chaque élément au moment de son utilisation. S'assurer de la correction du programme au moment de sa rédaction était assez difficile, car la vérification de type se faisait au moment de l'exécution.
Avec la possibilité de déclarer un Vector< String >, cette vérification se fait au moment de la compilation !
Pour moi, c'est de nature à permettre l'écriture de programmes plus robostes, ou tout simplement à faciliter le débogage: on passe d'un bug en runtime à un programme qui ne compile même pas, c'est pas rien :-) Sans parler de l'amélioration de la lisibilité avec la disparition de bien des transtypages...
[^] # Re: Mise au point
Posté par Romain Guy . Évalué à 1.
Malheureusement les generics, sous une apparente simplicité, cachent de nombreuses subtilités qui ne seront pas forcément toutes aisément assimilables par les débutants (le fameux joker ?).
[^] # Re: Mise au point
Posté par Pierre Tramonson . Évalué à -1.
[^] # Re: Mise au point
Posté par TazForEver . Évalué à 2.
Moi je vois le JRE de Sun comme un prérequis pour faire tourner Jext : est-ce que tu as déjà fait tourner Jext sur autre chose que la JRE de Sun ? Le Java-trap décrit par RMS
Si oui, comment ? Moi je suis très intéressé de faire tourner Jext sur mon GNU/Linux@PPC32.
Si non, c'est donc Jext n'est pas utilisable librement, ni multiplateforme aujourd'hui. Le problème étant donc Java et Sun.
[^] # Re: Mise au point
Posté par Stéphane Traumat (site web personnel) . Évalué à 0.
http://about.me/straumat
[^] # Re: Mise au point
Posté par Yusei (Mastodon) . Évalué à 2.
Depuis quand l'imperfection de quelque chose est un argument pour prôner plus d'imperfection ? Si je fais tourner un logiciel non libre sur ma machine, alors c'est un argument pour me convaincre d'en faire tourner plusieurs ?
Il est effectivement difficile de faire tourner une machine sans firmware propriétaire à ce jour. Par contre il est très facile de trouver une plateforme de développement d'au moins aussi haut niveau que Java, au moins aussi portable, et complètement libre. Il y a certainement des arguments pour utiliser Java, mais ceci n'en est pas un.
[^] # Re: Mise au point
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
l'imperfection n'est pas un argument pour proner plus d'imperfection mais l'imperfection devrait appeller à la tolérance et à la curiosité plutot qu'aux critiques non constructives.
http://about.me/straumat
[^] # Re: Mise au point
Posté par Yusei (Mastodon) . Évalué à 2.
Pour ma part, je n'aime pas le langage Java, mais j'aime bien la plateforme (on peut développer pour une JVM en eiffel, par exemple), donc quand je fais cette critique, ce n'est pas pour flamer...
[^] # Re: Mise au point
Posté par Romain Guy . Évalué à 1.
[^] # Re: Mise au point
Posté par TazForEver . Évalué à 0.
J'ai vu l'histoire de gcj/gij pour eclipse, franchement, y a pas plus disuasif. Faut être réaliste.
Et si même des gens qui font des logiciels libres en Java, en ont rien à secouer, ça vaut vraiment pas la peine ...
[^] # Re: Mise au point
Posté par Romain Guy . Évalué à 7.
Quant au vieux débat, cher à RMS, qui consiste à dire qu'un logiciel libre ne peut l'être s'il tourne pas sur une JVM libre... mais pourtant personne ne trouve à redire quand je créer un logiciel libre compilé sous Windows avec Visual C++ 6 non ? Et même si quelqu'un arrive à le compiler avec GCC, il reste lié à Windows, une plateforme non libre. Alors je propose que l'on soit cohérent : un logiciel libre ne peut pas être développé sous Windows s'il n'est pas aussi porté sous Linux.
Bref, ne le prend pas pour toi, au contraire, mais parfois ça devient vraiment fatiguant : on donne du temps pour les logiciels libres et on doit en plus se justifier, etc. C'est triste à dire mais j'ai de plus en plus envie de délaisser les licences type GPL/LGPL.
[^] # Re: Mise au point
Posté par TazForEver . Évalué à 2.
Sans parler d'intégrisme, j'ai la JVM de Sun sur mon PC : certes je subis, mais au moins quand je tombe sur un soft en Java, je peux le faire tourner. Seulement quand tu sors du monde bisounours de Sun avec ses 5 plateformes supportées, gage de portabilité, ben tu te retrouves comme beaucoup d'entre-nous : pas de JVM de Sun, pas de logiciels. Et là je t'assure, que tout de suite, ce qui te paraissait un point de détail (la license Sun), tu te mets à la haïr et là tu te rends compte que le logiciel libre c'est important. Tu te retrouves aux sources du problème d'il y a 20ans : l'impossibilité de faire fonctionner un programme à tes conditions. Ça je crois que y a beaucoup de personne qui ne le saisissent pas : là on ne parle pas de redistribution ou autre, on dit juste qu'on est confronté à l'impossibilité technique de faire fonctionner. Il ne s'agit de l'habituel "chouette c'est sous GPL, je peux avoir mon programme et le triturer". Sorti de ces 5 plateformes, le logiciel libre tu le vies autrement.
De mon expérience, Java est le seul à poser problème.
Tout ça pour expliquer notre mauvaise humeur et notre agacement vis à vis de Java : nous sommes tout simplement exclus.
[^] # Re: Mise au point
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Mise au point
Posté par TazForEver . Évalué à 3.
j'ai pris la JVM de IBM pour ses pseries, c'est la seule que j'ai trouvé et tout ce qui est interface graphique NE FONCTIONNE PAS !
FAUT TE LE DIRE COMMENT ? j'espère qu'en criant tu vas comprendre : sur tout le sujet on est plusieurs à réclamer et se fait tous moinser ... mais vas-y donne des liens ! Y a personne ici qui fait un retour d'expérience sur une plateforme orpheline !
Moi les JVM je peux pas les inventer quand même !
Et pourquoi aucune distribution ne fournit ça ?
[^] # Re: Mise au point
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
C t plus haut
http://about.me/straumat
[^] # Re: Mise au point
Posté par TazForEver . Évalué à 2.
[^] # Re: Mise au point
Posté par Romain Guy . Évalué à 2.
[^] # Re: Mise au point
Posté par dguihal . Évalué à 0.
ftp://ftp.oleane.net/pub/java-linux/JDK-1.3.1/ppc/FCS-02c(...)
Bon c'est du 1.3.1, mais j'ai pas trouve mieux
[^] # Re: Mise au point
Posté par TazForEver . Évalué à -1.
le JDK 1.3, c'est même pas Java2 ... alors t'es vraiment dans les choux avec
[^] # Re: Mise au point
Posté par allcolor (site web personnel) . Évalué à 2.
Euh si le jdk 1.3 c'est Java2... de même que le jdk 1.2... c'est d'ailleurs de celui-ci que Java2 vient... après java 1.0 et 1.1, le jdk 1.2 a introduit des changements dans la vm, notamment le classloading. Et jave est devenu Java2 (en référence au 1.2) comme cette nouvelle version s'appelle désormais Java5.
# Pas libre
Posté par gallenza . Évalué à -7.
[^] # Re: Pas libre
Posté par Gniarf . Évalué à 2.
# Performance
Posté par cedbor . Évalué à 3.
Y a-t-il toujours autant d'écart de réactivité entre les JVM linux et windows?
Quelle est la meilleure JVM actuelle sous linux? et les classpath?
[^] # Re: Performance
Posté par Anonyme . Évalué à 5.
C'est probablement pas très significatif mais le prog compilé et exécuté avec le SDK 1.4.2 est presque deux fois plus lent que lorsque je compile et exécute avec la version 5.
bon c'est fait avec un "time java Main", j'ai beau être en faible charge, j'ai des petits doutes, mais 4/5 exécution dans chaque cas m'ont donné des résultats équivalents.
Donc à priori le java 5 est plus rapide.
[^] # Re: Performance
Posté par Bertrand Florat (site web personnel) . Évalué à 3.
[^] # Re: Performance
Posté par Flipo . Évalué à 1.
Pour se convaincre que Swing version 5 est bien plus rapide que Swing version 1.4 sur Tux, il suffit de lancer une appli "tout swing" comme jEdit ou NetBeans. La différence est assez surprenante, en tout cas sur ma machine (AMD2500, 512Mo, Mdk10).
Même un simple System.out.println() est plus rapide. Le temps de chargement de la JVM est presqu'inperceptible. Bravo Sun!
Au fait, je vous conseille d'essayer NetBeans 4, il n'a plus rien à voir avec les version antérieures. Il utilise ant comme système de build interne, il intègre des outils comme Tomcat ou jUnit. Une vraie merveille. Actuellement en beta2.
# Java Generics vs. C++ Templates
Posté par michael_acreall . Évalué à 4.
Pas seulement, les templates ont ouvert la méta-programmation "statique" à C++.
En C++, il est possible de créer des types "statiques" conditionnels, C.f. la bibliothèques BOOST sur boost.org, ou le parseur Spirit qui permet ainsi de faire le même boulot que Lex/Yacc directement au moment de la compilation.
L'emprunt partiel des template à C++, fait par Java ne permet pas de faire les choses suivantes:
#include
/**
* Structure permettant le calcul d'une factorielle lors de la compilation
* Calcule récursivement la valeur de la factorielle
* Le code final ne contiendra que le résultat final (un entier)
*/
template <int N>
struct Fact {
static const int m_Value = N * Fact< N - 1 >::m_Value;
};
/**
* Condition d'arret du calcul de la factorielle
*/
template <>
struct Fact<0> {
static const int m_Value = 1;
};
/**
* Exemple de fonction IF en méta programmation
* On peut remplacer les types de A et B par des classes voire d'autres templates
* Ici on traite le cas True
*/
template <int A, int B, bool BOOL>
struct IF {
static const int m_Value = A;
};
/**
* Traite le cas False
*/
template <int A, int B>
struct IF<A, B, false> {
static const int m_Value = B;
};
int main() {
int fact10 = Fact<10>::m_Value;
std::cout << fact10 << std::endl; /* fact10 est remplacé par 3628800 lors de la compilation */
static const bool VAL_TRUE = true;
static const bool VAL_FALSE = false;
std::cout << IF<2,3, VAL_TRUE>::m_Value << std::endl; /* IF<2,3, VAL_TRUE> est remplacé par 2 */
std::cout << IF<2,3, VAL_FALSE>::m_Value << std::endl; /* IF<2,3, VAL_TRUE> est remplacé par 3 */
return 0;
}
[^] # Re: Java Generics vs. C++ Templates
Posté par boubou (site web personnel) . Évalué à 0.
Pas seulement, les templates ont ouvert la méta-programmation "statique" à C++.
Les deux affirmations ne sont pas contradictoires. Les templates du C++ sont effectivement un mécanisme ultra puissant et un peu mystérieux (qui aurait pensé qu'on pourrait faire des expressions templates lors de la création de ceux-ci ?) qui ressemble à une forme de macro-processeur. Ce qui est amusant dans le truc de Sun, c'est de dire que leur système est mieux alors qu'il est assez merdique en fait, en particulier en terme de performances.
[^] # Re: Java Generics vs. C++ Templates
Posté par michael_acreall . Évalué à 2.
Dans l'état actuel, je n'ai pas regardé si le fait d'instancier un template génère un fichier .class correspondant à la nouvelle classe, ou si comme j'ai l'impression il ne s'agit que d'une bidouille de la JVM.
Quelqu'un sait comment ils ont impléménté ce bidule??
[^] # Re: Java Generics vs. C++ Templates
Posté par boubou (site web personnel) . Évalué à 2.
Oui c'est de l'erasure bien porc. Dans ton code, tu écris List, et naïvement, tu crois que le code engendré n'est pas List. Raté, c'est exactement ça. Le type disparaît (de façon intelligente, quand même). L'avantage, c'est que c'est backward compatible (qu'est-ce qu'on s'en fout !), mais c'est bien le seul. Parce qu'au niveau perf, c'est une catastrophe. En C#, il y a bien des spécialisations du code quand c'est utile, le tout au vol par le CLR.
[^] # Re: Java Generics vs. C++ Templates
Posté par TImaniac (site web personnel) . Évalué à 2.
Comment il fait ? Ben, il ajoute des opérations de castings partout, exactement comme tu l'aurais fait, et il met le type "object" partout dans le code de ta classe. Où est l'intérêt ? Si si il y en a un, le compilateur peut otut de même faire une vérification statique de type, alors que si tu l'avais fait toi même, tu aurais du vérifier à la patte tous tes casts. Dans tous les cas, à l'exécution, tous les types primitifs se font boxés et déboxés car transformés en "object", et bien sûr par introspection tu es incapable de savoir que ta classe est une classe générique et tu ne peux bien entendu pas en tirer partie. Autre avantage : il n'ont pas eu besoin d'ajouter d'instruction dans la JVM.
En C#, le compilateur génère une classe qui contient le code, mais avec des attributs indiquant que c'est une classe générique. Déjà lors de l'exécution, tu peux savoir que c'est une classe générique. Lorsque tu demandes une instance de ta classe générique, le compilateur génère une nouvelle version (sauf bien entendu si tu as déjà demandé cette classe avec le même type en paramètre) en y "collant" ton nouveau type : il n'y a aucun cast, les types primitifs ne sont pas boxé (question perfs c'est pas plus mal, surtout quand on sait que les classes génériques sont souvent utiliser pour gérer des collections), et tu n'as rien perdu des possibilités d'introspection.
[^] # Re: Java Generics vs. C++ Templates
Posté par Romain Guy . Évalué à 2.
# Pour deboguer
Posté par petit_bibi . Évalué à 3.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getAl(...))
Elle est très utile pour connaitre la trace d' un thread qui coince.
En gros tu fais un thread/demon qui surveille les autres, et quand il y en a un qui
traine des pieds, tu affiches sa stacktrace et tu sais immediatement dans quelle (stream, boucle, synchronize deadlock....) il est coincé...
[^] # Re: Pour deboguer
Posté par gc (site web personnel) . Évalué à 0.
# Pour en finir avec le FUD autour de Java ...
Posté par Hive Arc . Évalué à 5.
http://www.jcp.org/en/jsr/detail?id=176(...)
Ensuite, il faut rappeler que cette version va être la première à bénéficier du nouveau JSPA qui intègre les demandes de l'Apache Group. Celles-ci rendent possible une implémentation opensource tout en conservant le nom "Java" et assure la compatibilité de l'ensemble gràce à la mise ) disposition gratuite pour les organisation à but non-lucratif de l'outil "couperet": le TCK.
Merci à l'Apache Group pour son super travail sur ce sujet :)
Maintenant, si tout le monde se bouge le c*l et va aider le projet GNU Classpath, au lieu de faire du FUD encore et encore sur la soit-disante impossibilité d'avoir du Java libre, alors GNU Classpath pourrait assez rapidement être la premère VM qui soit opensource et 100% Compatible :)
Au passage : Ici réside la grande différence avec des tentatives style mono, qui ne seront jamais que des essais de duplication de fonctionalités d'une plateforme non-spécifiées et dont on ne pourra jamais assurer l'exactitude et le niveau de compatibilité réel tant du fait que MS garde l'ensemble des specs bien au chaud sous son coude, sauf quelques miettes qui ont été données à la "plèbe" via l'ECMA histoire de mettre un semblant de teinte d'ouverture à leur solution, qui n'a aucune prétention d'etre multi-OS (càd foncitonner sur autre chose que les OS MS), dixit les pontes de MS.
Bien sur ça suppose que Classpath reçoive un peu plus de soutiens des principaux acteurs de la FSF... aller un petit effort Mr RMS, il manque juste ça et on à la solution 100% libre souhaité par tous les adeptes de la GPL.
Pour finir, si vous voullez un truc en Java et sous GPL qui "trou le c*l", pour moi, c'est Looking Glass
https://lg3d.dev.java.net/(...)
Là aussi ya pleins de trucs cool à faire ....
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par mosfet . Évalué à 0.
En ce qui concerne .NET/mono tu as raison lorsque tu dis qu'il ne s'agit pas d'une vrai plateforme qui offre une compatibilité entre OS par contre ce que je vois c'est qu'elle enrichit les possibiltés de developpement.
Pour le moment tant qu'on utilise pas de librairies specifiques M$ on peut tres bien faire tourner la meme appli sur win ou sur linux.
Maintenant imaginons que Billou décide de modifier .NET et de ne pas publier les modifs et bien rien n'empechera mono de continuer à exister et à évoluer car la base technique est saine.
Sinon ce que j'aime dans Mono/.Net c'est le fait que ce soit pas du Java ;-)
Non sérieusement j'aime l'idée que tu puisses choisir ton langage
de developpement ce qui n'est pas possible en Java (enfin je crois).
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par Romain Guy . Évalué à 6.
[^] # Question naive
Posté par Lionel Draghi (site web personnel) . Évalué à 2.
C'est stupide comme objectif, ou ca pose des pbs techniques insolubles?
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par Gabriel . Évalué à 5.
Tu me rappelles exactement cette partialité qu'on trouve dans les docs microsoft : cette manière de dire :"avec Nous vous allez pouvoir faire ça ça ça c'est fantastique." C'est bon, laisse les gens juger par eux-mêmes, s'il te plaît.
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben tout simplement parcque la personne à laquelle j'ai répondu répondait elle-même à la possibilité de choisir son langage avec Mono/.NET. Cette personne a voulu montrer que en Java aussi c'était possible, j'ai juste voulu expliquer la différence. Je suis effectivement enthousiaste comme tu l'as remarqué, mais depuis le début, si tu relis tous mes posts, c'est jamais moi qui est commencé à parler de .NET. Je l'ai juste ramené quand le sujet était là, et là c'est le cas ;)
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par Romain Guy . Évalué à 2.
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par Marc Perron (site web personnel) . Évalué à 2.
N'est-ce pas aussi le cas pour .Net? Si on bricole un compilateur C# qui ne respecte pas le CLI on tombe dans le même piège il me semble.
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Vive le marketing !
Posté par Hive Arc . Évalué à 5.
MS .net ne permet PAS d'avoir les languages de son choix. Si on nomme les languages de .net des "flavor" ce n'est pas pour rien.
Ok, je m'explique: Les languages supportés par la CLR (je parle ici de code managed bien sur), ont tous un parent en commun, et sa plus fidèle incarnation est C#. Ceci est dû au fait que tous fonctionnent sur des bases communes : utilisation de la CLR et les classes de références (structuration et comportement).
En clair, tous les flavor de languages sont C#ifiés. Pour preuve il suffit de regarder le VB à la sauce .net: non comptent d'avoir introduit une centaine de changement majeur dans le language on a maintenant un langage : orienté objet, utilisant les classes de .net et disposant de fonction de ramasse miète, ....
Et on peut faire la même analogie pour tous les autres languages "soit disant" portés sur .net. Dans la pratique, comme ils font tous contraint à un commun dénominateur, ils ont tous semblables et n'ont plus rien à voir avec les originaux.
Si tu n'est toujours pas convaincu, va voir du cobol sauce .net et discute ça avec un coboliste.
Alors clairement, le multilanguage dans ces conditions n'a aucun interret. D'ailleur le fait est qu'il est que c'est bien C# qui est utilisé pour développer la majorité des applications, et qu'il existe des outils qui permettent de passer d'un langage à un autre ...
Enfin, techniquement parlant la plateforme de base de .net la plateforme Java sont quasiment identique tant en fonctionalité qu'en comportement. Alors je ne vois pas en quoi, l'un permetrait plus d'implementer un language que l'autre ne permet pas.
Et si c'etait le cas pourquoi pense tu qu'il existe une JSR intitullé "JSR 45: Debugging Support for Other Languages" ?
http://www.jcp.org/en/jsr/detail?id=45(...)
En fait languages, il y en a clairement largement plus qui existent sur Java que que .net :
http://www.robert-tolksdorf.de/vmlanguages.html(...)
La plus part sont également des "flavors", mais certains ont ajoutés suffisament de concepts pour que l'on puisse les considerer comme indépendants : Kiev ou OpenJava par exemple.
En conclusion, oui, désolé, mais il faudrait peut être sortir des publications comerciales de MS ;-)
[^] # Re: Vive le marketing !
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais il ne faut pas oublier non plus de sortir des préjugés et à priori.
Tu te bases sur l'exemple de VB.NET et de Cobol pour démontrer que tous les langages sont des "flavors".
Alors pourquoi ne prends tu pas d'autres exemples de langages comme Prolog, Caml ou C++ ? Autant le dernier langage a été modifié, autant il permet tout de même de porter facilement du code existant en C++ (exemple moteur de Quake2), comme quoi c'est qu'il respecte assez la sémantique originale du langage. Pour Prolog (P#) et Caml (CamIL), la syntaxe n'a clairement rien à voir avec C#, et pourtant celà fonctionne. Je ne te parlerais même pas du support du langage Eiffel.
Faut arrêter de généraliser comme ça, c'est pas parcque VB.NET a fortement évolué (de toute façon il en avait besoin, il n'était même pas objet), et que Cobol a été modifié (ben oui mais bon, tu trouves toi que la dernière version de Cobol ressemble beaucoup plus au premier cobol du nom ?) que c'est le cas pour tous les langages de la plateforme !
J'oublies sûrement d'autres implémentation, mais tu vas sûrement me trouver des contre exemple. Je pense t'avoir trouvé suffisament de langages aux concepts pourtant très différent qui ne sont pas de simples flavors comme tu dis.
De nombreux langages sont supportés par la plateforme Java... N'ont-ils pas tous un dénominateur commun encore plus fort que .NET ? Ne manque-t-il pas UN langage qui faciliterait pourtant des centaines de migrations ? Allez je te laisse deviner...
Comme je l'ai déjà dis quelques part dans cette page, dans la théorie tu peux faire la même chose sur les 2 plateformes, mais .NET a le mérite de définir une CLI (Common Language Interface) et des types de bases qui définissent le niveau d'interopérabilité entre les langages. C'est clairement ce qu'il manque à la plateforme Java, et l'intégration entre les différents langages dépend fortement de leurs implémentation, parfois la compatibilité n'est possible que dans un sens, parfois que dans l'autre, etc.
En conclusion, non désolé, faudrait peut-être arrêter de généraliser.
[^] # Re: Vive le marketing !
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Mais sur la forme, je redis que le multi langage est excactement ce que tous mes clients ne veulent pas voir ;)
Ca ne les interesse pas. Les anciennces appli, on les maintient et on développé les nouvelles dans le langage choisi...
De plus, les méthodes de dev d'il y a 5 ans et celle de today ont tellement changés que je ne pense pas que ce soit une bonne idée de réécrire.
http://about.me/straumat
[^] # Re: Vive le marketing !
Posté par TImaniac (site web personnel) . Évalué à 2.
Je suis d'accord avec tout ce que tu dis.
Pour les vieilles applis, autant les utiliser telles qu'elles sont : .NET est fort pour celà, il te facilite le travail de réutilisation, que ce soit en supportant le langage d'origine de l'appli, soit à travers des faciliter d'appels natifs (c'est le cas pour tout ce qui concerne les wrappers d'API natifs comme GTK ou autre). Sun à l'opposer te propose plutôt de réécrire ou de te taper JNI mais il ne te le conseille pas.
Pour mélanger les différents langages, je suis bien d'accord avec toi, du moment que l'on reste dans des considérations internes à un projet ou une équipe. Par contre si telle société préfère tel langage, mettons Eiffel, et souhaites vendre ses composants, en ciblant la plateforme .NET, elle permet à ses clients d'utiliser le langage qui leur chante, C# ou VB.NET par exemple : d'ailleur le client n'a aucune idée du langage utilisé lors du développement des composants achetés.
# Deux nouveautés oubliées
Posté par Romain Guy . Évalué à 6.
- la possibilité d'écrire des flottants sous forme hexa
- la possibilité de changer le type de retour d'une méthode surchargée si le nouveau type est un descendant de celui d'origine. En clair une classe Voiture pourra enfin avoir une méthode clone() retournant une Voiture et non plus un Object. Pratique pour éviter d'autres transtypages fastidieux :)
# A propos du concept "tout est objet"
Posté par Lionel Draghi (site web personnel) . Évalué à 2.
"pure objet" n'était pas une qualité, c'est juste une caractéristique.
La grande erreur des années 80, ca a été justement de croire que tout était classe et objet. Je le reconnai : ramener tout à une poignée de concepts simples et universels, c'est tentant. Quelle "conceptual integrity"!
D'un point de vue marketing aussi, c'était intéressant : tout truc qui n'est pas "full quelque chose" semble louche d'emblée, avant même que l'on sache de quoi il retourne.
J'invite les passionnés à lire le papier http://acmqueue.com/modules.php?name=Content&pa=showpage&pi(...)
Il explique comment les langages C++ et Java se sont tirés une balle dans le pied en confiant les prérogatives des modules et des classes aux seules classes. [1]
Smalltalk, Ada, Modula ou OCaml n'ont pas eu à souffrir de la limitation "tout est objet" (que les spécialistes respectifs confirment), et ne s'en portent pas plus mal. [2]
Ce phénomène n'a pas tappé qu'au niveau langage, UML (à travers OMT) en a fait les frais également. Quelle absudité par exemple que ces classes ayant le stéréotype "utility", dont la principale caractéristique est de ne pas être des classes.
Tout ca pour dire qu'il n'y a pas de quoi conclure sur la supériorité d'un langage "pure objet". Trop souvent, il serait mieux caractérisé par "seulement objet".
PS pour David : un bon mail se fait en deux temps :
[1] tu énerves ceux qui sont déja là, et
[2] tu fais venir les autres! :-)
# à chacun sa famille?{impératif,fonctionnel,déclaratif}x{objet,non objet}
Posté par Guillaume Vauvert (site web personnel) . Évalué à 5.
Ce deuxième type d'argument dépend d'abord de ce qu'on veut exprimer, et donc du projet, de l'analyse et de la conception, mais aussi de l'interprétation du mot "naturellement". Ces arguments dépendent donc beaucoup de la culture de chacun, de sa méthodologie de conception et de sa façon d'aborder l'informatique. Pour ma part, j'ai appris l'informatique avec Pascal, où tout est assez propre (mais on n'est parfois obligé de soulever le capot pour optimiser le code); alors j'ai trouvé un grand plaisir avec Eiffel. J'imagine que ceux qui ont commencé avec l'assembleur, puis C n'y trouveront pas leur compte. Quant à ceux qui adorent les langages fonctionnels, l'impératif doit leur paraitre tordu (c'est réciproque, idem avec les langages déclaratifs).
Il y a des endroits où on enseigne le fonctionnel (ou le déclaratif) avant l'impératif, d'autres où l'on enseigne l'objet avant./en même temps que la base du langage. Je pense que ça doit influencer la façon de voir les autres langages.
Et pour vous ?
[^] # Re: à chacun sa famille?{impératif,fonctionnel,déclaratif}x{objet,non ob
Posté par Romain Guy . Évalué à 3.
[^] # Re: à chacun sa famille?{impératif,fonctionnel,déclaratif}x{objet,non ob
Posté par Marc Perron (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.