Java 2 Standard Edition version 5.0

Posté par  (site Web personnel) . Modéré par Amaury.
Étiquettes : aucune
0
3
oct.
2004
Java
Après quelques pré-versions, la version finale de J2SE version 5 (auparavant appelée version 1.5) est enfin disponible. Comme l'indique le saut dans les numéros de versions (1.4 à 5 !), il s'agit d'une version majeure du langage Java.

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

  • # Livre

    Posté par  . Évalué à 3.

    Java 5.0 est tellement une révolution par rapport a Java 1.4 qu'il est dommage qu'il n'existe pas un livre pour parler juste des différences entre ces deux langages... Avec des exemples, comment metre en pratique, des "tips", etc.

    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
  • # révolutionnaire !

    Posté par  (site Web personnel) . Évalué à -2.

    C'est vraiment révolutionnaire Java 5.0 d'après la news.

    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...
    • [^] # Re: révolutionnaire !

      Posté par  (site Web personnel) . Évalué à 9.

      ca me fait chier de répondre car c'est un post un peu ridicule mais allons y...

      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  . Évalué à 9.

        >> Ah non, juste, les utilisateurs n'auront pas la machine virtuelle adéquate...
        > 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  (site Web personnel) . Évalué à 1.

          Disons quy'en développant en java, je vais pouvoir le faire tourner sur un maximum de plateforme... on a jamais dit toutes :)

          http://about.me/straumat

          • [^] # Re: révolutionnaire !

            Posté par  . Évalué à 5.

            Ouai donc moi en cours de java avec mon ibook je fais comment ? j'utilise java 1.3 par ce que c'est la derniere de chez Sun qui connait meme pas les regexp...

            Si le maximum de plateformes c'est 5 je glousse doucement.

            TRAUMAT => tramo ? :-)
            • [^] # Re: révolutionnaire !

              Posté par  (site Web personnel) . Évalué à 6.

              TRAUMAT = TRAUMAT :)

              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  (site Web personnel) . Évalué à 8.

                Ceci dit c'est un fait, la portabilité de Java reste depuis des années tout à fait théorique, car les implémentations de JVMs ne suivent pas. Pas assez vite pour certaines plate-formes, pas du tout pour d'autres. Java serait 100% portable "si" il y avait une JVM dans la version qui va bien pour chaque plate-forme. Le problème c'est que ce n'est pas le cas... Compare le nombre de plate-formes qui supportent actuellement, aujourd'hui, maintenant, Perl 5.8 ou Java 1.4, y'a pas photo, mais alors vraiment pas.

                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  (site Web personnel) . Évalué à 2.

                  Depuis des années on a du FUD comme ça... Java n'a jamais promis la portabilité sur toutes les plateformes du monde, java a juste dit, vous allez pouvoir développer indépendament de la plateforme et vous allez ensuite pouvoir déployer sur n'importe quelle plateforme qui a une machine virtuelle....

                  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  (site Web personnel) . Évalué à 4.

                    > Java n'a jamais promis la portabilité sur toutes les plateformes du monde, java a juste dit
                    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  (site Web personnel) . Évalué à 3.

                      WORA... signifie que tu peux développer sur n'importe quelle plateforme ( style moi sous linux ) et déployer sans soucis sur n'importe quelle autre ( comme moi sous windows ).

                      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  . Évalué à 4.

                        «Enfin, ca, vieux, c le jeu de l'évolution [...] faut du temps.»

                        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  (site Web personnel) . Évalué à 2.

                          pas du tout d'erreur de raisonnement...

                          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  . Évalué à 3.

                            Pourquoi Toto n'aura jamais le même âge que son grand père ? Parce que pendant qu'il grandit, son grand-père continue de vieillir aussi.

                            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  (site Web personnel) . Évalué à 2.

                              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+).
                              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  . Évalué à 0.

                                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.

                                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  (site Web personnel) . Évalué à 4.

                                  ok... donc

                                  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  . Évalué à 0.

                                    Tu persistes et j'ai 5 minutes pour te répondre, pas facile ;)

                                    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  (site Web personnel) . Évalué à 3.

                                      Ce qui m'intéresse, c'est de savoir si dans le monde réel, cette techno est acceptable.
                                      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  . Évalué à 2.

                                        «Ce n'était pas ton propo au début mais admettons.»

                                        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  . Évalué à 3.

                                          Je vais m'insérer dans cet discution privée et dire :
                                          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  . Évalué à 2.

                                            (ce n'est pas une discution privée, et ça fait du bien de voir une bonne argumentation. Je précise ma pensée une dernière fois parce que j'ai des Xp à perdre ;)

                                            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  . Évalué à 2.

                                        Ah, j'avais oublié de lire un passage

                                        «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  . Évalué à 4.

                                          En gros, la solution pour que les JVMs soient vraiment portable serait l'ouverture du code par Sun, ce qui permettrait des portages pour les plateformes plus rares, et ça permettrait à tout le monde d'utiliser la même JVM...
                                          • [^] # Re: révolutionnaire !

                                            Posté par  . Évalué à 1.

                                            Et d'après ce que j'ai lu dans le dernier Login qui parlait de la conférence JavaOne, les specs sont publiques et le code source de l'API et la JVM librement consultable.

                                            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  . Évalué à 2.

                      >Java n'a jamais promis la portabilité sur toutes les plateformes du monde, java a juste dit
                      write once, run anywhere 8-)

                      je crois que java a dit un peu plus :
                      compile once, run anywhere
                • [^] # Re: révolutionnaire !

                  Posté par  (site Web personnel) . Évalué à 5.

                  Je me joins aux réponses de ce commentaire, et je précise que contrairement a Perl, ils considèrent plus de choses que le simple fait que ça mache sur une parteforme pour dire qu'elle est supportée...
                  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  . Évalué à 7.

      Oui, il est certain que malgré le ton de la news, la lecture des nouveautés donne la forte impression que Sun a créé un Java/C(++) et clame qu'il s'agit d'une innovation révolutionnaire alors qu'un grand nombre d'argument de Sun visait auparavant à discréditer ces mêmes concept qu'ils remettent aujourd'hui dans leur langage... Assez surprenant je trouve même si les fanatiques de Java vont surement m'expliquer que si je trouve un goût C++ de plus en plus prononcé à Java c'est uniquement parce que je suis un parfait ignorant et que tous ces concepts sont des révolutions... Ah si, y a la boucle foreach qui est pas dans le C++ (encore que Qt propose une solution avec le préprocesseur qui mime parfaitement le comportement de ce type de boucle) même si dans le genre révolutionnaire on fait mieux (cf les langages de scripts comme Perl ou PHP par exemple qui ont ça depuis fort longtemps).

      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  . Évalué à 10.

        Ca n'a rien de révolutionnaire à mon goût : pour les types génériques ca me fait penser à ADA (j'ai plus fait d'ADA que de C++, ya peut être de ça). Il me semble d'ailleurs que beaucoup de fonctionnalité sont implémentées dans le compilateur et non pas dans la JVM.

        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  . Évalué à 1.

          Et un avantage de Java qu'on ne peux nier, qu'on soit partisan ou pas est que des technologies émergantes ont bien souvent tendance à être implémenter en Java avant d'autres langages comme le C et le C++.

          Par exemple, les APIs XML et les webservices.
      • [^] # Re: révolutionnaire !

        Posté par  . Évalué à 9.

        alors qu'un grand nombre d'argument de Sun visait auparavant à discréditer ces mêmes concept

        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  . Évalué à 10.

        La plupart des nouveautés proviennent des JSR émises au sein du JCP. Lorsque j'avais interviewé James Gosling, l'un des pères de Java, au sujet de Java 5 il m'avait bien précisé qu'il n'aimait pas du tout l'autoboxing ou les generics.

        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  (site Web personnel) . Évalué à 7.

          Pourquoi n'aime-t-il pas l'autoboxing ?

          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  . Évalué à 4.

            Pour pleine de bonnes raisons.

            * 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  . Évalué à 2.

              Donc il faudrait:

              - 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  . Évalué à 2.

            Je pense que c'est le coté "caché" de la chose qu'il n'aime pas..

            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  (site Web personnel) . Évalué à 2.

              C'est un peu le problème de l'autoboxing : il faut plus ou moins réfléchir avant de l'utiliser, le problème c'est qu'on ne s'en rend pas toujours compte. Heuresement, l'impact sur les perfs est négligeable, sauf dans les boucles... J'ai un peu du mal à expliquer parfois à des programmeurs qu'il faut parfois l'éviter :)
              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  (site Web personnel) . Évalué à 1.

          Sun a un droit de veto dans le JCP, donc si Sun n"avait pas voulu de l'autoboxing, il n'y en aurait pas eu. Il ne faut pas confondre Sun et Gosling.
      • [^] # Re: révolutionnaire !

        Posté par  (site Web personnel) . Évalué à 3.

        Moi, je ne vois que deux trois fonctionnalités du C et du C++... on est quand même très loin de ça... On a toujours pas de pointeurs, on a un garbage collector, une API commune, une machine virtuelle.... vous allez quand meme pas dire que Java est proche du C / C++.

        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  (site Web personnel) . Évalué à 4.

          l'informatique évolue très vite et si les gens ont des idées, pkoi ne pas les utiliser ?
          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  (site Web personnel) . Évalué à 3.

            Ils ne font pas que copier.. les métas data tels qu'ils les utilsent, ca vient quand même beaucoup de XDoclet qui est une innovation du monde Java...

            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  (site Web personnel) . Évalué à 2.

              inventer des nouvelles choses dans les langages, tu fais pas ça tous les jours..
              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  . Évalué à 2.

                > jedirais même que leur implémentation des generics
                > 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  (site Web personnel) . Évalué à 2.

                  Euh, une implémentation comme celle-ci est forcement gravée dans la pierre, parcque là Sun n'a pas juste choisi une implémentation, il a aussi choisi une sémantique associée aux generics... ca ne se modifie pas comme celà, au risque de tout voir péter.
                  • [^] # Re: révolutionnaire !

                    Posté par  . Évalué à 2.

                    Non, pas dans ce cas la. Une implémentation des génériques à la C# entrainerait, je l'ai déja dit un changement de byte code, (comme cela a été le cas pour C#) mais pas d'incompatibilté majeure.
                    • [^] # Re: révolutionnaire !

                      Posté par  (site Web personnel) . Évalué à 2.

                      Si si je t'assure, celà changerai aussi la sémantique, notamment à l'exécution : un programme qui fait de l'introspection ne verra pas du tout la classe de la même manière selon l'implémentation choisie. Si celà ne posait pas de problème d'incompatibilité majeure, alors pourquoi ils n'ont pas choisie l'implémentation de C# ?
                      • [^] # Re: révolutionnaire !

                        Posté par  . Évalué à 2.

                        Dans le cas de l'introspection tu aurais une classe dérivée au lieu de ta classe de base. Je ne pense pas que cela soit bien grave...

                        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  (site Web personnel) . Évalué à 2.

                          Dans le cas de l'introspection tu aurais une classe dérivée au lieu de ta classe de base.
                          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  . Évalué à 2.

          on a un garbage collector

          Pour le C et le C++: http://www.hpl.hp.com/personal/Hans_Boehm/gc/(...)
          • [^] # Re: révolutionnaire !

            Posté par  (site Web personnel) . Évalué à 2.

            AH serait ce le moment de dire "ouais, C++ , ca va devenir du java.. on va enfin pouvoir faire des trucs concrets avec... " :)

            Mais non :)

            http://about.me/straumat

            • [^] # Passez à l'Objective-C !!!

              Posté par  . Évalué à 4.

              Passez à l'Objective-C, c'est surpuissant et ultra simple...

              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  . Évalué à 6.

        Je vais me risquer à essayer de résumé l'intérêt de Java en rapport à ses spécificités de base :

        - 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  (site Web personnel) . Évalué à 2.

          Perso, l'objet m'interesse sutout pour masquer la complexité des traitements et la réutilisation.
          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  . Évalué à 9.

          «Le language en lui même est pure objet»

          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  . Évalué à -5.

            Enormité ? Pas vraiment, peut-être que oui pour les puristes, mais pour moi ce n'était juste qu'une simple hyperbole servant à appuyer mes propos.
            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  . Évalué à 9.

            Smalltalk est completement objet. Tout ce qu'on pouvait manipuler aves Smalltalk était indirectement instance d'une sous classe de Object : les entiers, les classes, les métaclasses, les booléens (true et false sont les deux instances uniques de la classe Boolean), l'objet vide, nul (instance de la class Null)...

            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  . Évalué à 3.

              Je trouvais ce langage assez génial pour le concept "tout est objet" (pour ajouter le foreach de java, ce n'est pas bien long et modification du compilateur, de la VM ou autre). Par contre il y a une chose qui m'avait supris :
              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  . Évalué à 1.

                Patcher la méthode < de la classe Integer, c'est rigolo, mais ça risque quand même de faire planter tout le reste du code, y compris le code des classes smalltalk existantes.

                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  . Évalué à 2.

              j'ai entendu parler de squeak. comme un petit-fils de smalltalk ? non ?

              http://www.squeak.org(...)
          • [^] # Re: révolutionnaire !

            Posté par  (site Web personnel) . Évalué à 1.

          • [^] # Re: révolutionnaire !

            Posté par  (site Web personnel) . Évalué à 2.

            Pourquoi "presque" pour Ruby ?
            • [^] # Re: révolutionnaire !

              Posté par  . Évalué à 2.

              Il y a certaines choses dans Ruby qui ne sont pas des objets, comme les structures de contrôle ou (je crois) les classes. C'est suffisant pour qu'il ne soit pas pur objet, mais il en est assez proche pour que ça ne m'ait jamais dérangé.
              • [^] # Re: révolutionnaire !

                Posté par  (site Web personnel) . Évalué à 2.

                Les classes sont des objets suivant cette démo (ou alors je n'ai pas compris le principe) :

                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  . Évalué à 2.

                  Oui, pour les classes je me suis trompé, c'est peut-être les méthodes qui n'en sont pas, faudra que je vérifie où j'avais trouvé cette idée (fausse :).

                  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  . Évalué à 0.

                    Ben en ruby les methodes aussi sont des objets, des "chuncks", de la classe Proc.
                    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  (site Web personnel) . Évalué à 4.

          Hum ... Smalltalk ?

          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  (site Web personnel) . Évalué à 2.

            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
            En quoi C# est-il pauvre ?
            • [^] # Re: révolutionnaire !

              Posté par  (site Web personnel) . Évalué à 5.

              Quelques exemples :
              - 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  (site Web personnel) . Évalué à 2.

                pas de généricité contrainte.
                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  . É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  . Évalué à 2.

                    >>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.

                    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  (site Web personnel) . Évalué à 1.

                    En faisant simple, c'est de pouvoir contraindre un parametre générique à n'etre que d'un certains type,
                    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  . Évalué à 4.

                      >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.

                      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  (site Web personnel) . Évalué à 2.

                        Ca n'a absolument pas le même but.
                        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  . Évalué à 1.

                          Il y a un mécanisme appelé par le mot-clef external qui permet de réutiliser du code écrit dans un autre langage. J'ai déjà ainsi recyclé du code C en l'encapsulant dans du code Eiffel. Ca fonctionne bien et c'est facile à utiliser. Ca marche aussi pour le C++ et, je crois, le Fortran.
                        • [^] # Re: révolutionnaire !

                          Posté par  (site Web personnel) . Évalué à 1.

                          A t'on vraiment vraiment la même définition de covariance ?
                          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 :

                          class Number
                          add (other: Number): Number
                          end

                          class Integer <: Number
                          add (other: Integer): Integer
                          end

                          Bien sûr, avec la généricité, si elle le permet, on peut se permettre une écriture à la F-Bound:

                          class Number [ T <: Number [T] ]
                          add(other: T): T
                          end

                          class Integer [ T <: Integer [T] ] <: Number [ T <: Number [T] ]
                          end


                          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  (site Web personnel) . Évalué à 4.

                            Sinon, il apparaitrait que C# 2.0 intégrera la généricité contrainte
                            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  . Évalué à 1.

                              Garder la syntaxe VB en VB.net ok, mais passer à l'objet.
                              Ce qui de toutes façons demande 6 mois-un an.
                            • [^] # Re: révolutionnaire !

                              Posté par  (site Web personnel) . Évalué à 2.

                              Heu, non Eiffel est un langage des années 80 qui s'est affirmé dans les années 90 !
                              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  (site Web personnel) . Évalué à 2.

                                Merci pour cet historique de Eiffel, je ne le connaissais pas.

                                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  (site Web personnel) . Évalué à 3.

                                  Je suis d'accord avec toi sur l'ensemble.

                                  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  . Évalué à 1.

                "pas de généricité contrainte."

                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  (site Web personnel) . Évalué à 1.

                  Par rapport à la généricité contrainte, elle doit faire partie de C# 2 qui n'apparaitra qu'avec Visual .NET 2005 qui doit être encore en version beta sauf si je me trompe. Je parlais de la version 1.1. Autrement dit celle utilisée actuellement et pour lequel plein de petits développeurs Microsoftiens s'extasient (ce n'est pas péjoratif, attention !).

                  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  . Évalué à 0.

                    Ca fait en effet partie de C# 2.0 en beta 1 pour le moment... (en fait toute les fonctionnalité présentée font partie de C# 2.0 et/ou .NET 2.0). J'aurais du le préciser dans mon post.

                    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  (site Web personnel) . Évalué à 3.

                      le café ? Si Java :)
                      (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  . Évalué à 1.

                        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.

                        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  . Évalué à 2.

          "Le language en lui même est pure objet"

          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  (site Web personnel) . Évalué à 2.

            J'avais plus envie de participer ( trop de discution tue la discution ) mais la, c'est vraiment n'importe koi.

            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  . Évalué à 1.

              "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. "

              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  (site Web personnel) . Évalué à 1.

      ploum, je te laisse imaginer le jour de fete que cela sera quand on pourra faire de la bonne 3D avec de la vrai geometrie dedans ...

      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  (site Web personnel) . Évalué à 4.

        à tous ceux qui m'ont moinsi ...

        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  (site Web personnel) . Évalué à 2.

          J'ai fait un petit peu de 3D et je ne me rappelle pas qu'on faisait les choses de cette façon la.. mais c'était du OpenGL, les choses ont du évolué depuis non ?

          http://about.me/straumat

        • [^] # Re: sortez couvert de certitudes, ca evite d'attraper la maladie du dout

          Posté par  . Évalué à 2.

          C'est un peu simplique comme exemple... Le choix des classes et des objets est un gros travail, et ce n'est pas parce qu'on manipule des cassés et des rectangles qu'on doit forcément avoir une classe Carre et une classe Rectngle.

          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  (site Web personnel) . Évalué à 2.

            un mamifere invertébré ? ouch ! ca existe ?

            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  (site Web personnel) . Évalué à 4.

              On m'a expliqué qu'en Java on doit faire un minimum d'héritage. En théorie on doit juste faire des interfaces et quand on a besoin d'une fonctionnalité on aggrège un objet dans la classe au lieu d'en hériter, et on accède plutôt à lui par appel de méthode sur cet objet. Ca permet une meilleure indépendance des objets qui sont "aggregeables" de n'importe où et sans se poser les questions qui arrivent forcément lorsque l'arbre d'héritage devient gros. Il paraît qu'il est instructif de regarder le code de Tomcat ou Eclipse. Je l'ai pas encore fait.

              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  (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  (site Web personnel) . Évalué à 3.

                  Plutôt que d'ajouter une interface à tous les objets, t'as pas pensé à ajouter la méthode à la classe Object ?
                  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  . Évalué à 3.

                    Ou utiliser les classes UI* des look n' feel ? C'est fait pour ça entre autres.
                    • [^] # Re: cachez ce sein que je ne saurai voir

                      Posté par  (site Web personnel) . Évalué à 3.

                      Gni ? Il parle d'interface au sens objet, pas d'interface graphique :)
                      • [^] # Re: cachez ce sein que je ne saurai voir

                        Posté par  . Évalué à 2.

                        [quote]pour faire du "rendu SWING"[/quote]

                        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  (site Web personnel) . Évalué à 1.

                    Ajouter la methode à la classe Object ... tu peux expliquer plus precisement ? parce que j'ai peur de comprendre ( elle me semble etre dans la liste )
                    • [^] # Re: cachez ce sein que je ne saurai voir

                      Posté par  (site Web personnel) . Évalué à 2.

                      J'ai bien mis la ligne d'après "Plus sérieusement" ;)
                      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  (site Web personnel) . Évalué à 1.

                        oki ;)

                        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  (site Web personnel) . Évalué à 2.

                          les métas-datas ne peuvent pas répondre à tes attentes ? (d'ailleur comment as-tu résolu le problème ?)
                          • [^] # Re: cachez ce sein que je ne saurai voir

                            Posté par  (site Web personnel) . Évalué à 1.

                            j'ai resolu avec la methode "lourde" ... :/

                            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  . Évalué à -1.

    Mouais pour simplifier on peut dire qu'ils sont en train de nous pondre un deuxième C# et je trouve ca plutot nul comme attitude.
    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  . Évalué à 10.

      J'ai failli repondre "trop gros passera pas" mais vu le ton presque serieux du message je vais faire une vraie reponse.

      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  . Évalué à -1.

        sauf qu'avec Mono, on a une implémentation complète, libre, multiplateforme, performante et on ne dépend pas du bon vouloir de Sun
        • [^] # Re: A comparer plutot au C#

          Posté par  (site Web personnel) . Évalué à 6.

          Mais qui depend du bon vouloir et des brevets de M$ ;-)
          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  . Évalué à 1.

            sauf qu'en attendant, Mono fonctionne partout. Y a une version PPC avec JIT. Et les autres architectures ne sont pas en reste, mint permet l'interprétation stricte, ce qui te permet de faire du Mono où tu veux. Fais un sondage : les gens qui roulent sur autre chose que x86, tout fonctionne sauf Java
            • [^] # Re: A comparer plutot au C#

              Posté par  . Évalué à -1.

              Ouais, c'est clair Java ne fonctionne probablement pas sur les Sparc utilisant Solaris, faut pas déconner non plus.
            • [^] # Re: A comparer plutot au C#

              Posté par  . Évalué à 1.

              Bof ! Dans ma boite, on a du PC x86 (linux et Windows), du Mac OS X et du Solaris et Java fonctionne trés bien sur ces plate-formes. (Je pense que j'aurais pris ma retraite quand .Net pourra supporter toutes ces machines... :-)

              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  (site Web personnel) . Évalué à 5.

          > sauf qu'avec Mono, on a une implémentation complète, libre, multiplateforme, performante et on ne dépend pas du bon vouloir de Sun

          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  . Évalué à 1.

            peut-être mais ça n'est pas le cas. Mono est bien plus jeune, mais fonctionnel. Donc en attendant, un programme en Java, fut-il libre, tu ne peux rien en faire ça la bazar de Sun.
            • [^] # Re: A comparer plutot au C#

              Posté par  (site Web personnel) . Évalué à 2.

              je saisis pas ?
              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  . Évalué à 6.

                C'est vrai en théorie, mais en pratique il n'y a pas de solution autre que celle de Sun qui soit fonctionnelle sans avoir quelques années de retard (les JVM d'IBM étant les meilleures du lot), et aucune solution libre qui implémente toute la bibliothèque livrée en standard par Sun.

                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  (site Web personnel) . Évalué à 1.

                  je développe avec BEA et blackdown et j'ai pas de probleme !

                  http://about.me/straumat

                  • [^] # Re: A comparer plutot au C#

                    Posté par  (site Web personnel) . Évalué à 0.

                    1- blackdown c'est la jvm de sun (faites à partir des sources de la jvm de sun), donc c'est pas libre non plus.
                    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  . Évalué à 2.

                  Tu pourrais rétorquer que ce n'est pas la faute de Sun si la communauté du libre ne propose rien de compatible[...]

                  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  (site Web personnel) . Évalué à 6.

                    > du fait de la licence imposée par Sun, il est impossible de proposer une mise en ouvre alternative de Swing (que cette alternative soit libre ou non).

                    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  . Évalué à 0.

                      Expliques moi en quoi Sun rends impossible une implementation de JVM/Swing en libre ?

                      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  (site Web personnel) . Évalué à 3.

                        Dans le doc de Debian, 2 notions bien differentes sont melanges:
                        - 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  . Évalué à 2.

                  il n'y a pas de solution autre que celle de Sun qui soit fonctionnelle sans avoir quelques années de retard

                  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  . Évalué à 2.

                    J'me rappelle pas avoir dit que c'était différent pour .NET. En général quand on me demande mon avis sur le choix d'une plateforme de développement je propose Ruby ou Python.
                  • [^] # Re: A comparer plutot au C#

                    Posté par  (site Web personnel) . Évalué à 0.

                    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é.
                    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  . Évalué à 3.

                      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.
                      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  (site Web personnel) . Évalué à 2.

                        tu comprends rien à ce que je dis : je dis juste que la portabilité à un coût, ce n'est pas une chose qui s'acquiert pif paf poum comme ça. Par fois il est plus facile de s'appuyer sur un existant, parfois non portable, quand le besoin de portabilité ne se fait pas sentir. Et il y a pleins de cas où il ne se fait pas sentir : il est de toute façon toujours possibler plus tard de résoudre ce problème en faisant ce travail supplémentaire, mais l'avantage c'est qu'on est pas obligé de le faire directement.
                        • [^] # Re: A comparer plutot au C#

                          Posté par  . Évalué à 2.

                          Pour un nouveau projet, il est beaucoup plus interessant de partir à priori sur une technologie portable et à effectuer le minimum en natif. (un peu comme le C vs Asseembleur) et non pas le contraire.

                          > 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  (site Web personnel) . Évalué à 2.

                            Moi je fonde mon raisonnement sur la réutilisation du réexistant, et toi t'essai de me contredire en partant d'un nouveau projet... Celà a au moins le mérite de se compléter à défaut de s'opposer :)
                    • [^] # Re: A comparer plutot au C#

                      Posté par  (site Web personnel) . Évalué à 3.

                      attends... je rêve, on ne réinvente pas la roue en Java, quand je code, j'utilise les API qui me permettent de tout faire ? qu'est ce que tu racontes encore ?

                      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  (site Web personnel) . Évalué à 3.

                        mais vas pas dire qu'en Java on réinvente à chaque fois la roue
                        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  (site Web personnel) . Évalué à 2.

                          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.


                          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  (site Web personnel) . Évalué à 1.

                            sauf que Delphi cible maintenant .NET dans sa dernière version.
                            Ç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  . Évalué à 3.

                              Désolé mais dans tous les cas que j'ai pu rencontrer, la migration d'applications existantes vers .NET s'est aussi accompagnée de la réécriture complète du code en C#.
                              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  (site Web personnel) . Évalué à 2.

                                Ben moi j'ai pris un exemple où y'avait pas besoin, qui mettait justement en évidence l'utilité du multi-langage d'un point de vue réutilisation. Même si ce n'est pas toujours possible, c'est parfois un gain de temps non négligeable, et voulir ignorer ce facteur pour pouvoir comparer "équitablement" revient à vouloir masquer les différences entre les plateformes, et donc les avantages. C'est comme si je voulais comparer une ferrari et une 2 chevaux, mais que pour pas voir de différence je les brides à 50km/h, comme ça personne ne pourra me dire que ma 2 chevaux va moins vite.
        • [^] # Re: A comparer plutot au C#

          Posté par  (site Web personnel) . Évalué à 1.

          Le plateforme Java ne dépend pas du bon vouloir de SUN mais plutot du JCP ou, meme toi, tu peux participer :)

          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  (site Web personnel) . Évalué à 1.

            meme toi, tu peux participer :)
            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  . Évalué à 3.

              Non c'est faux. Le commité exécutif est composé de 15 sièges, dont un réservé à Sun. Ce commité est élu régulièrement (chaque année jusqu'à 5 sièges sont élus). Si tous votent contre Sun crois bien que la décision sera appliquée. Tu devrais lire les différents documents présentant le JCP sur le site officiel.
              • [^] # Re: A comparer plutot au C#

                Posté par  (site Web personnel) . Évalué à 3.

                Sun a un droit de veto pour les décisions qui touchent au jdk lui même dans ses diverses décisions (cf le point A.5.9 du JCP, http://www.jcp.org/en/procedures/jcp2(...)). Seuls 5 sièges sont élus en tout. Les autres sont désignés par le PMO (lui-même nommé par Sun) et approuvés par un vote, ce qui n'est pas une élection.

                C'est ouvert, mais Sun garde le contrôle...
                • [^] # Re: A comparer plutot au C#

                  Posté par  . Évalué à 1.

                  Mea culpa, je me repends derechef pour cette grossière erreur. A trop ouvrir sa bouche on finit par dire des conneries ^^
                  • [^] # Re: A comparer plutot au C#

                    Posté par  (site Web personnel) . Évalué à 1.

                    grossière erreur

                    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  (site Web personnel) . Évalué à 3.

                Tu devrais lire les différents documents présentant le JCP sur le site officiel.
                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  . Évalué à 2.

                  Je me suis laissé emporter, pardon. Ceci dit Sun aura du mal à trouver de bonnes raisons pour refuser la participation de quiconque :)
            • [^] # Re: A comparer plutot au C#

              Posté par  . Évalué à 3.

              J'ai lu un jour le témoignage d'un développeur dans une jcp (je ne sia splus laquelle : jdo?)
              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  (site Web personnel) . Évalué à -1.

              On se rtrouve timaniac, on avait déja eu une conversartion ou je disais que tu parlais sans connaître.. une fois de plus, c'est vérifié !

              http://about.me/straumat

        • [^] # Re: A comparer plutot au C#

          Posté par  . Évalué à 3.

          Alors qu'avec kaffe et GNU classpath...

          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  . Évalué à 2.

            Ils sont pas plus en retard sur la réimplementation de ce que je vais appeler le "Framework" que ce que l'est Mono.

            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  (site Web personnel) . Évalué à 2.

              il n'y a pas que le langage... ce qui est interessant, c'est la plateforme.

              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  (site Web personnel) . Évalué à 2.

                Vous essayer de démontrer quoi là ? Que il faut un certain temps pour porter un API ? Que celà prend plus de 2 jours ? Clap clap clap.
                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  . Évalué à 4.

                  Mono implémente une VM, plus les 3 librairies de base que M$ à gentiment standardisé pour faire plaisir au bon peuple. Donc il est relativement facile de sortir Mono en même temps que M$. Sauf que ça n'a absolument aucun sens au niveau de la portabilité entre les environnements. A partir du moment ou les environnements ne sont pas compatibles (et ne le seront sans doute jamais), je vois pas vraiment l'intérêt de copier commes des bénets M$, avec tous les risques que cela comporte.

                  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  (site Web personnel) . Évalué à 2.

                    Mono implémente une VM, plus les 3 librairies de base que M$ à gentiment standardisé pour faire plaisir au bon peuple.
                    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  . Évalué à 1.

                      > tu oublies la pile "Microsoft" dans les API de Mono
                      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  (site Web personnel) . Évalué à 2.

                        + qq autre. C.a.d trés peu.
                        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  . Évalué à 2.

                          Ne fais pas exprês de ne pas comprendre. Je viens de dire plusieurs fois que le framework .Net était énorme et que justement que Mono n'était pas près d'en venir à bout (si'il y arrive un jour). En tout cas dans la version actuelle, il en est trés loin.

                          >> 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  (site Web personnel) . Évalué à 2.

                            Ne fais pas exprês de ne pas comprendre.
                            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  (site Web personnel) . Évalué à 2.

                    Maintenant, comme dans Mono, rien n'empêche une appli Java d'appeler des fonctions natives,
                    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  . Évalué à 2.

                      JNI imbittable ?
                      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  (site Web personnel) . Évalué à 2.

                        Pour faire du conseil pour des sociétés de développements, je sais que pour eux changer de langage facilement n'est pas un avantage... au contraire, changer de langage est un challenge, des emmerdes et un cout important.

                        http://about.me/straumat

                        • [^] # Re: A comparer plutot au C#

                          Posté par  (site Web personnel) . Évalué à 2.

                          Tout à fait. Alors quand un langage supporte une nouvelle plateforme comme .NET, même s'il y a 2 ou 3 différences, c'est quand même beaucoup plus appréciable comme transition. Je pense notamment au C++ managed qui permet de combiner code natif et code managé, y'a rien de spécial à faire et ça marche : après ils peuvent commencer à utiliser les nouveaux API, écrire le nouveaux code avec, et intégrer facilement l'existant. Pareil pour J# qui propose d'importer un projet Java, avec il est vrai une limitation quand au framework supporté (Java 1.3 seulement pour le moment)
                      • [^] # Re: A comparer plutot au C#

                        Posté par  (site Web personnel) . Évalué à 2.

                        Je n'attaque pas spécialement J2EE là dessus, je dis juste que c'est le choix philosophique de la plateforme Java : limiter les possibilités de réutilisation de code existant (pour moi JNI est ce qu'on peut appeler l'opération de dernière chance, ou alors quand il n'y a pas vraiment le choix comme par exemple OpenGL qui peut difficilement être codé en plus haut niveau sans avoir accès aux drivers). 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é.
                        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  . Évalué à 3.

                          > ils forcent le portage sur la plateforme en réécrivant
                          > 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  (site Web personnel) . Évalué à 2.

                            Comme précédemment, je parle toujours et encore de réutilisation de l'existant. Je penses que là tu comprends mieux mes arguments...
                            • [^] # Re: A comparer plutot au C#

                              Posté par  . Évalué à 2.

                              Si pour réutiliser l'existant tu doit réécrire tout le code, c'est effectivement un avantage ERNORME.
                              • [^] # Re: A comparer plutot au C#

                                Posté par  (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  . Évalué à 2.

                                  Tu te relis pas ou t'es de mauvaise foi.

                                  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  (site Web personnel) . Évalué à 2.

                                    non non, je me suis relus, et je ne suis pas de mauvaise foi :) par contre je me suis peut-être la exprimé ou tu m'a mal compris :). Dans ma première citation je dis qu'ils forcement la réécriture, mais on a comme avantage la portabilité.
                                    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  . Évalué à 2.

                      > c'est possible comme dans Mono, mais dans un cas c'est encouragé
                      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  (site Web personnel) . Évalué à 2.

                        Ils sont masos ces mecs !!!
                        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  . Évalué à 3.

          Avec une API pas encore assez mature qui dépend du bon vouloir de Microsoft. Chacun son goût.
        • [^] # Re: A comparer plutot au C#

          Posté par  . Évalué à 5.

          une implémentation complète

          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  (site Web personnel) . Évalué à 3.

            D'accord avec toi.

            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  . Évalué à 2.

            en attendant, je fais tourner des vrais logiciels avec Mono et avec JIT sur PPC. Avec Java, c'est 3 bricoles d'étudiants en lignes de commande. Sans la JRE de Sun, point de salut. Ah si, y a bien la JRE de IBM pour ses pseries ... vachement bien, sauf qu'elle bouffe des SIGILL des qu'elle veut lancer un truc graphique et qu'elle n'a pas de JIT.

            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  (site Web personnel) . Évalué à 1.

              C'est koi tes vrais logiciels ? ( URL ? )

              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  . Évalué à 2.

                en graphique ? avec Mono, je vais tourner des players multimedia, un IDE, une éditeur de blog, un gestionnaire d'album photo, un navigateur de documentation, un petit logiciel d'astronomie, etc ... on peut faire une très longue liste.

                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  . Évalué à 2.

                  je vais tourner des players multimedia
                  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  . Évalué à 1.

                    Ça fonctionne que sous Mono ? Peut-être, mais où le problème puisque Mono fonctionne partout, LUI ? Mono travaille activement à la compatibilité et elle est déjà très grande. Les personnes qui portent leurs applic C# vers Linux pourront te confirmer que la migration se fait très rapidement. Et la situation va en s'améliorant.

                    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  (site Web personnel) . Évalué à 2.

                  J'aimerais si possible avoir les urls des applis car ca pourrait interesser des gens que je connais.
                  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  . Évalué à 1.

                  Te faches pas :-(, voici l'url :

                  http://klomp.org/mark/gij_eclipse/(...)
      • [^] # Re: A comparer plutot au C#

        Posté par  (site Web personnel) . Évalué à 2.

        Moi je dirai plutot que Sun (d'ailleurs il me semble qu'il n'y a pas que Sun la dedans, vu que c'est un ensemble de JCP) a pris la mesure du danger de C# et a réagit en adoptant les parties intéressantes qui faisaient raler depuis pas mal de temps (tel l'autoboxing et les génériques).
        Parce que franchement les exceptions non checkees en C# ben jamais je m'y ferai
        • [^] # Re: A comparer plutot au C#

          Posté par  (site Web personnel) . Évalué à 1.

          Pour les exceptions non checkées, tu peux lire l'avis du concepteur de C# sur le sujet : http://www.artima.com/intv/handcuffs.html(...) . On aime ou on aime pas, mais ses choix sont justifiés, et il faut reconnaître que celà pose pas mal de problème en Java les exceptions, même si le principe est louable.

          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  (site Web personnel) . Évalué à 1.

            J'avais lu et je n'en suis toujours pas convaincu. Franchement la solution de Java a ce niveau la n'est pas excellente mais c'est moins pire. Je preferre un truc qui me dit qu'il risque de peter a attrapper toutes les exceptions en haut. Mais c'est mon avis perso, je concois que ca en gene certains.
            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  (site Web personnel) . Évalué à 2.

              La verbosité est un handicap quand elle n'apporte aucune sémantique. C'est le cas quand la plupart des développeurs l'utilise n'importe comment, en méettant par exemple throws Exception devant toutes les méthodes, ou en catchant systématiquement.
              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  . Évalué à 1.

                je pense qu'il vaut mieux imposer une recompilation au cas ou tu declenches des exceptions non prevues. Cela impose un traitement rapide des exceptions qui me semble souhaitable (ça peut etre tres porcale la gestion des exceptions avec certains codeurs qui en abuse vraiment).
    • [^] # Re: A comparer plutot au C#

      Posté par  . Évalué à 2.

      J'ai failli repondre "trop gros passera pas" mais vu le ton presque serieux du message je vais faire une vraie reponse.

      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  . Évalué à 4.

      juste pour ajouter 2 centimes à la discussion.
      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  . Évalué à 2.

    " - le package java.util.concurrent fournit de nouveaux outils pour synchroniser des threads, par exemple des sémaphores"

    ç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  . Évalué à 2.

      Euuh les fonctionnalités du package java.util.concurrent ne sont pas issus de nouveauté de la JVM. C'est juste de nouvelles classes Java dans un nouveau package.
      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  . Évalué à 5.

      je ne comprends pas tout cette polemique autour de java.
      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  . Évalué à 1.

      Qu'est-ce que ça peut bien être un mutex récursif ? Je sais qu'un mutex est un sémaphore d'exclusion mutuelle, permettant de garantir l'accès exclusif à une partie de code (et par extension si on le désire à des variables) à un thread donné à un moment donné, mais un mutex récursif ?
      • [^] # Re: nouvelle API de programmation //

        Posté par  . Évalué à 4.

        Je ne sais pas si c'est la même chose dans Java, mais dans les mutex POSIX, un mutex récursif est un mutex qui peut être verrouillé plusieurs fois au sein d'un même thread sans provoquer de deadlock.

        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.
  • # Mise au point

    Posté par  . Évalué à 8.

    Il y a deux choses que j'aimerais mettre au clair après lecture de la news et des commentaires.

    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  (site Web personnel) . Évalué à 4.

      Je n'ai pas encore lu les commentaires de Bruce Eckel, mais il me semble quand-même que les generics apportent un surcroît de fiabilité.

      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  . Évalué à 1.

        Oui je suis d'accord pour la question de fiabilité avec la vérification à la compilation. En fait ce problème est rarement abordé dans tous les documents que j'ai pu lire car, et mon expérience me l'a prouvé, il est finalement assez rare de se tromper de type dans une liste. Bien évidemment ça arrive et c'est mieux de le voir à la compilation :) Mais tu le dis toi-même, ce sont principalement les transtypages qui disparaissent, rendant le code bien plus clair.

        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  . Évalué à -1.

          Je suis assez d'accord, cela rend le code plus lisible, mais franchement je vois pas trop comment c'est possible de se planter dans le type d'objet d'une liste. Ca veut dire qu'on mélange des choux et des carottes. En général on s'en aperçoit à la compilation ou à la première exécution !
    • [^] # Re: Mise au point

      Posté par  . Évalué à 2.

      pour faire clair : ton Jext est de très bonne facture et sous licence GPL. Tu m'arrêtes si je me trompe : Jext à pour vocation d'être un éditeur de code libre et multiplateforme.

      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  (site Web personnel) . Évalué à 0.

        Je suis très interessé par faire tourner mon linux sans aucun firmware propriétaire, comment je fais ?

        http://about.me/straumat

        • [^] # Re: Mise au point

          Posté par  . Évalué à 2.

          Je trouve un peu déplacée ta manière d'accuser les gens qui critiquent Java de FUD et d'envie (cf. plus haut), et de rétorquer avec ce genre de non arguments (à chaque fois en plus).

          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  (site Web personnel) . Évalué à 1.

            beh en fait, je réplique à chaque fois de la même façon dont on me replique...

            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  . Évalué à 2.

              Mais c'est une critique argumentée, le "java trap" de RMS, si tu le traites comme du FUD ça ne convaincra personne. C'est une vérité indiscutable que le libre est à la traîne en matière de JVM, et que ça ne va pas s'arranger avant longtemps. Donc c'est un argument contre l'usage des versions récentes de Java pour des projets libres. Accepter et discuter de cet argument ne veut pas dire qu'on rejette en bloc toutes les qualités de Java. Je suis persuadé que si Sun libérait Java, les gens qui font cette critique seraient satisfaits.

              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  . Évalué à 1.

        Malheureusement je dois avouer que je n'ai jamais essayé car la VM de Sun m'a toujours suffit. Je sais par contre que des utilisateurs s'en servent sous NetWare par exemple, et je ne pense pas que Sun fournisse une telle JVM. D'autres s'en servent sous MacOSX... ce n'est pas Sun qui s'occupe de cette VM (même si ils ont aidé), etc. Soyons honnête, c'est surtout la VM de Sun qui est utilisée mais ce n'est pas impossible de s'en passer, juste chiant ^^
        • [^] # Re: Mise au point

          Posté par  . Évalué à 0.

          que ça soit chiant ou impossible, ça ne change rien pour l'utilisateur final : je ne __peux__ pas utiliser Jext sur ma plateforme.

          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  . Évalué à 7.

            Je comprends que cela te gêne mais je n'en ai rien à secouer dans le sens où j'ai envie de faire des logiciels libres en Java et pas de la politique. Je compte des milliers d'utilisateurs ravis et il y en a d'autres, malheureusement, que je ne peux pas satisfaire. Non pas que je ne le veuille pas, mais c'est parfois impossible et 5 ans dans l'univers du logiciel libre/open source m'ont assez fatigué. Les exigeances et les discussions "politiques" ou "religieuses" au bout d'un moment ça lasse. Personnellement je veux faire des logiciels, pas des JVM, à d'autres de s'en occuper.

            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  . Évalué à 2.

              Je ne te blâme pas, et je trouve Jext très sympa. Le fait que tu l'ai écris en Java permet une certaine portabilité. Tu regarderas dans la communauté, beaucoup de développeurs utilise Jext (ou JEdit pour parler du concurrent) et sous Windows et sous Linux/x86.

              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  (site Web personnel) . Évalué à 1.

                On a déja expliqué plus haut qu'il y avait bien plus de 5 plateformes supportées.

                http://about.me/straumat

                • [^] # Re: Mise au point

                  Posté par  . Évalué à 3.

                  MAIS PUTAIN VAS-Y FILE MOI UN LIEN !
                  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  . Évalué à 2.

                Ca tombe bien j'ai décidé de passer au Mac, je vais donc moi aussi pouvoir râler parce qu'aucun logiciel ne fonctionnera :)
      • [^] # Re: Mise au point

        Posté par  . Évalué à 0.

        tu peux toujours essayer cette JVM :

        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  . Évalué à -1.

          déjà essayé, la pluspart de logiciels veulent la version 1.4. Minimum ... avec la sortie de la 1.5, c'est même pas la peine d'y penser.

          le JDK 1.3, c'est même pas Java2 ... alors t'es vraiment dans les choux avec
          • [^] # Re: Mise au point

            Posté par  (site Web personnel) . Évalué à 2.

            le JDK 1.3, c'est même pas Java2 ... alors t'es vraiment dans les choux avec

            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  . Évalué à -7.

    JAVASAPUCPASLIBRE non?
  • # Performance

    Posté par  . Évalué à 3.

    Je ne vais pas troller sur les performances du langage (surprenant que ce soit pas encore parti...), mais il me semble que SUN avait parlé d'accélération de la JVM linux, notamment concernant la GUI.
    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  . Évalué à 5.

      Bah j'ai fait un mini test (ouverture d'une fenètre avec toolbar et autre) puis exit directement à la fin de la création.
      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  (site Web personnel) . Évalué à 3.

      Pour mon projet (Jajuk) qui fait une utilisation intensive de Swing, j'ai -30% CPU sous windows entre le JRE 1.4.2 et le JRE 1.5 de Sun et des gains de 10% sous Linux. Ca vient en partie d'une nouveauté qui ne semble pas avoir été citée dans la news : le garbage collector qui a été completement reécrit et qui libère la memoire de facon plus efficace et moins gourmande en CPU. Au niveau de la réactivité de l'interface, je pense qu'on peut dire maintenant qu'avec le JRE 1.5 et une machine actuelle (2 Ghz+), il n'y a aucune difference d'affichage entre une appli Swing ou SWT et une appli native Windows ( à part à l'affichage initial peut être ).
      • [^] # Re: Performance

        Posté par  . Évalué à 1.

        D'après les tests "à la louche" que j'ai effectués, j'obtiens à peu près les mêmes résultats que toi.
        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  . Évalué à 4.

    Sur le site de Sun on peut lire "A C++ template on the other hand is just a fancy macro processor;"
    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  (site Web personnel) . Évalué à 0.

      Sur le site de Sun on peut lire "A C++ template on the other hand is just a fancy macro processor;"
      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  . Évalué à 2.

        Je me demande si Java pourra (dans Java 6 ;-) ) prendre en compte les paramètres par défaut des templates (ex: template<int A = 0> ... ) et les spécialisations (ex: la seconde structure Fact du code d'exemple).
        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  (site Web personnel) . Évalué à 2.

          Quelqu'un sait comment ils ont impléménté ce bidule??

          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  (site Web personnel) . Évalué à 2.

            Pur être plus précis, le compilateur Java ne génère qu'une seule représentation du code de la classe générique.

            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.
  • # Pour deboguer

    Posté par  . Évalué à 3.

    Moi ce que j' aime c' est cette methode static pour le debogage.
    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é...
  • # Pour en finir avec le FUD autour de Java ...

    Posté par  . Évalué à 5.

    Voici la récérence sur la JSR concernant cette sortir du "tigre" (nom de code de la version 1.5 de la plateforme J2SE ).

    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  . Évalué à 0.

      Je croyais que Classpath etait un ensemble de bibliothèque qui implementait les librairies Java donc je vois pas, meme si on se bouge le cul , comment on aura la premiere VM opensource.
      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  . Évalué à 6.

        Ce n'est pas vrai. Tu peux utiliser la plateforme Java en Python, en Ruby, en Prolog, en LISP, en BASIC, en SmallTalk, en Eiffel, etc. Voici une belle liste regroupant tous les langages connus pour fonctionner sur la plateforme Java : http://www.robert-tolksdorf.de/vmlanguages.html(...) Il s'agit soit d'interpréteurs, soit de compilateurs. Bref ne confondons pas le langage Java avec la plateforme Java :)
        • [^] # Question naive

          Posté par  (site Web personnel) . Évalué à 2.

          Ca fait longtemps que je me demande pourquoi la JVM n'est pas un simple backend de gcc, au meme titre qu'un autre processeur?
          C'est stupide comme objectif, ou ca pose des pbs techniques insolubles?
        • [^] # Re: Pour en finir avec le FUD autour de Java ...

          Posté par  (site Web personnel) . Évalué à 2.

          A la grosse différence près que là il n'y a aucun protocole qui défini comment doivent intéragir les langages entre eux, quel format doivent avoir les données. C'est tout l'intérêt de .NET : il y a la CLI qui est clairement définie (Common Language Interface) avec un autre acronyme pour spécifier le format des données à échanger. La plateforme Java n'a pas du tout été conçue avec cet objectif, et même s'il est possible d'implémenter pleins de langages au dessus de la plateforme Java, on est loin de l'interopérabilité qu'offre la plateforme .NET.
          • [^] # Re: Pour en finir avec le FUD autour de Java ...

            Posté par  . Évalué à 5.

            Pourquoi tu ramènes cela à .net? Dans les 2 derniers posts auquel tu réponds, on n'en parlait pas. Tu ramènes toujours tout à .net. Ok tu es enthousiaste mais je crois qu'on a compris.
            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  (site Web personnel) . Évalué à 2.

              Pourquoi tu ramènes cela à .net?
              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  . Évalué à 2.

            Je ne vois pas le problème : la plateforme Java dispose d'un bytecode clairement défini dans les spécifications de Sun et si ton langage s'y conforme, tout langage peut utiliser tout bytecode généré par tout langage.
            • [^] # Re: Pour en finir avec le FUD autour de Java ...

              Posté par  (site Web personnel) . Évalué à 2.

              Sauf que ton compilateur peut très bien faire les appels de méthodes comme il le sens avec les instructions qui lui plait, implémenter un type de base avec une taille de données qui l'amuse, sans parler de sa définition de classe qui ne sera peut-être pas la même, etc. Bref, tu pourras effectivement réutiliser du bytecode, mais le programmeur va devoir faire en sorte que son compilateur respecter toutes les règles de Java, à défaut d'un sous-ensemble plus "friendly" et bien défini. Rien ne vaut des conventions écrites, et un bytecode conçu avec cet objectif (histoire de ne pas non plus limiter les possibilités et/ou les perfs)
              • [^] # Re: Pour en finir avec le FUD autour de Java ...

                Posté par  (site Web personnel) . Évalué à 2.

                tu pourras effectivement réutiliser du bytecode, mais le programmeur va devoir faire en sorte que son compilateur respecter toutes les règles de Java

                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  (site Web personnel) . Évalué à 2.

                  Non avec .NET tu es obligé de respecter seulement la CLI. La CLI a été définie pour faciliter la réutilisation d'API en spécifiant certains concepts et méthodes permettant d'assurer l'interopérabilité, mais reste assez limitée pour ne pas contraindre trop l'implémentation de nouveaux langages. Evidemment il reste des contraintes : il faut que le langage soit procédural (ou tout de moins ce qu'il expose) et objet c'est pas plus mal (s'il veut réutiliser). Mais les règles sont bien définies, c'est tout l'intérêt d'un protocole : suffisament précis pour faciliter les communications et suffisament général pour ne pas trop contraindre leur utilisation.
          • [^] # Vive le marketing !

            Posté par  . Évalué à 5.

            Désolé, mais il faudrait peut être sortir des publications comerciales de MS.

            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  (site Web personnel) . Évalué à 2.

              Oui il faut effectivement sortir des considérations publicitaires de MS.
              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  (site Web personnel) . Évalué à 2.

                Je ne vais pas discuter sur le fond ( surtout que peut etre que personne ne lit plus :) )
                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  (site Web personnel) . Évalué à 2.

                  meuh si moi je lis toujours :) (au fait t'en dis quoi du droit de veto de Sun là-où-tu-sais ?)

                  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  . Évalué à 6.

    N'oublions pas deux nouveautés assez sympa (surtout la seconde) :
    - 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  (site Web personnel) . Évalué à 2.

    Je sais, c'est énorme ce que je vais dire, mais je trouve qu'une news sur les langages qui ne s'enflamme pas à plus de 300 mails, c'est un peu faiblard : -)

    "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  (site Web personnel) . Évalué à 5.

    Parmi les arguments utilisé pour comparés deux langages, il y a les arguments fondés qui permettent de comparer objectivement et il y a les arguments qui disent "dans tel langage, je peux exprimer plus naturellement ce que je veux".
    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  . Évalué à 3.

      A chaque langage son application. J'ai appris à programmer en impératif et je commence tout juste à découvrir sérieusement le déclaratif/fonctionnel. Conséquence, j'ai du mal à démarrer, formatté que je suis par mes habitudes, mais j'adore ça et j'aperçois des choses extrêmement puissantes qui me seront sûrement utiles pour résoudre certains problèmes. Bref, j'ai bien envie d'embarquer un interpréteur déclaratif/fonctionnel dans mes applications Java pour traiter certains algos :))
      • [^] # Re: à chacun sa famille?{impératif,fonctionnel,déclaratif}x{objet,non ob

        Posté par  (site Web personnel) . Évalué à 1.

        Je suis d'accord que chaque language à son utilitée. À la job on développe en C++ (en essayant de maintenir une méthode orientée objet). D'ailleurs il y avait quelque fois où j'aurais voulu implémenter quelques algos en Prolog (question d'être plus simple); mais de pouvoir les intégrer de façon portable dans notre logiciel...bon ce n'est pas évident. Peut-être qu'on devrait bricoler un compilateur Prolog (Lisp/Scheme/ml etc.) qui génère du bytecode?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.