Légende urbaine : un alligator dans le ramasse-miettes

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes : aucune
0
5
juin
2003
Java
Ou comment couper court à certaines idées reçues sur les performances de Java. Un article paru dans le IBM developerWorks fait le point sur trois légendes urbaines très répandues sur la rapidité des applications écrites en Java : la synchronisation, les méthodes et classes déclarées final et les objets immuables. (PS : quelqu'un a une traduction plus heureuse pour immutable ?).

Aller plus loin

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  . Évalué à -7.

    attention chérie, ca va troller :)

  • # Objets immuables

    Posté par  . Évalué à 1.

    Objets persistants ?

    • [^] # Re: Objets immuables

      Posté par  (site web personnel) . Évalué à 4.

      Mutable et immutable sont des termes français.
      Persistant est un contre-sens par contre: ce n'est pas parce qu'un objet persiste qu'il ne change pas.

      • [^] # Re: Objets immuables

        Posté par  . Évalué à 2.

        invariant alors ?

        • [^] # Re: Objets immuables

          Posté par  . Évalué à 8.

          immutable = non mutable = un fois l'objet crée, il est non modifiable. Le modifier revient à le remplacer par un objet. C'est le cas des String en java.

          objet persistant = objet dont on peut enregistrer l'état et ainsi réactiver ultérieurement.

          • [^] # Re: Objets immuables

            Posté par  (Mastodon) . Évalué à 3.

            Pour information :

            immutable (in "Webster's Revised Unabridged Dictionary")

            \Im*mu"ta*ble\, a. [L. immutabilis; pref. im- not + mutabilis mutable. See Mutable.] Not mutable; not capable or susceptible of change; unchangeable; unalterable.

            Le Robert contient la définition suivante :

            IMMUTABLE [i(m)mytabl] adj.
            - Rare et littér. Qui ne peut changer. - Immuable (plus cour.)

            Alors en se la pétant rien qu'un peu, on peu utiliser ce terme tel quel (lequel a donné l'autre : l'Anglais, ou le Français ?)

      • [^] # Re: Objets immuables

        Posté par  . Évalué à 1.

        Dis moi, tu pourrais m'expliquer le "and now, comething completly different" sur ta page ?
        j'avais un prof de java qui nous mettait ca a chaque cours on a jamis compris pourquoi !

        (oui, vous pouvez moinsser, mais attendez svp qu'il réponde c important)

        • [^] # Re: Objets immuables

          Posté par  . Évalué à 6.

          ben parce que c'est lui, ton prof de Java ?

        • [^] # Re: Objets immuables

          Posté par  . Évalué à 3.

          C'est un spectacle des monty python, non ?

          • [^] # Re: Objets immuables

            Posté par  . Évalué à 1.

            c'est en effet ce qu'on m'a dit mais on a jamais été capable de me dire lequel

            • [^] # Re: Objets immuables

              Posté par  . Évalué à 3.

              c'est une transition dans le monty python flying circus, entre
              les sketchs, on voyait john cleese apparaitre et déclarer :
              "and now for something completly different".

              cf le splash screen de la demo de wxpython par exemple :-)

              La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

            • [^] # Re: Objets immuables

              Posté par  . Évalué à 7.

              <Culture Monty Python>
              Ce n'est pas un spectacle des monty python, mais une phrase récurrente de l'emission 'Monty Python Flying Circus' que John Cleese, assis derrière un bureau, déclamait en dehors de tout contexte (comme d'habitude chez les Pythons).
              C'est une phrase très connue outre manche (et chez les anglophones) au point qu'une publicité (je ne sais plus pour quel produit) s'en ait servi. De nombreux comiques l'utilisent également comme référence culturelle....
              </Culture Monty Python>

              • [^] # Re: Objets immuables

                Posté par  . Évalué à 2.

                C'est effectivement une transition récurrente dnas la série des Monty Python, mais c'est également le titre original de leur premier film sorti en france sous le titre Pataquesse, qui est une compilation de leurs meilleurs sketchs retournés pour le cinéma.
                Il est à noter que la véritable citation est, comme dit plus haut, "And now, for something completely different".

        • [^] # Re: Objets immuables

          Posté par  . Évalué à 3.

          Parfois, entre deux sketch du Monty Python Flying Circus (LA serie des Monty Pyhton sur la BBC entre 1969 et 1974), une voix off dit : "And now for something completely different !". En effet, les sketchs des Monty Python s'enchaine sans aucun lien entre eux :)

          Voilaaaaa

        • [^] # Re: Objets immuables

          Posté par  . Évalué à 0.

          et bien merci pour ces qqs explications attendues pendant tout un semestre :)

          et maintenant moinssez moi ca ;)

  • # perfs de java

    Posté par  (site web personnel) . Évalué à 10.

    mais non java n'est pas lourd !
    on fait même des serveurs X avec !

    http://www.jcraft.com/weirdx/(...)
    (il supporte même la transparence, bien avant les hacks de XFree)

    Malheureusement la plupart des programmes pour java sont lourds, eux :-(

    • [^] # Re: perfs de java

      Posté par  . Évalué à 4.

      et bien c pourtant simple : il faut abandonner Swing / AWT au profit des bindings GTK/GNOME pour java, abandonner la JVM au profit de GCJ ( je sais, ce n'est pas complet, mais on a toujours plus de possibilites qu'avec du c de base...), et ensuite, java c'est seulement YAPL (Yet Another Programming Language) :p
      et hop, pas plus lourd que le reste, avec l'avantage en prime d'avoir un beau code ...

      sam

      • [^] # Re: perfs de java

        Posté par  . Évalué à 6.

        Mais non mais non, SWING a reçu un régime dramatiquement amaigrissant depuis le JDK1.3 (avec des gains de perfs d'au moins 20%). Par contre _évidemment_ si on passe son temps à créer/supprimer des containers/objets graphiques dans tous les sens dans son application, elle sera évidemment plus lente et mal fichue.

        IMHO ca dépends plus de la façon de développer l'appli.

        Maintenant y'a toujours le probleme de la grosse consommation de mémoire qui contribue sur les systèmes un peu faiblots à faire couler les performances (e.g. si obligé de swapper ou si XP).

        Maintenant y'a aussi un probleme de chargement initial de la JVM (hmm je sais pas trop a quoi c'est dû, ptet kil alloue par défaut une certaine quantité mémoire de base au lancement).

        • [^] # Re: perfs de java

          Posté par  . Évalué à 0.

          Ah j'allais oublier, a défaut d'alligator on peut toujours faire confiance a son chameau : OCaml Power !

          • [^] # Re: perfs de java

            Posté par  . Évalué à 0.

            Ah non le chameau c'est Perl !

            • [^] # Re: perfs de java

              Posté par  . Évalué à 4.

              Erreur, c'est un dromadaire pour Perl (une seule bosse !).

              • [^] # Re: perfs de java

                Posté par  . Évalué à 0.

                Pourtant on parle assez facilement du camel book en parlant du joli O'Reuilly sur Perl.
                Une erreur courrement faite on dirait :).

                • [^] # Re: perfs de java

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

                  Non, c'est simplement que les américains n'ont pas de mot pour dromadaire. Pour eux, un chameau et un dromadaire sont des camels. Comme lobster qui désigne à la fois le homard et la langouste...

                • [^] # Camelidés (fut: Re: perfs de java)

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

                  Pourtant on parle assez facilement du camel book en parlant du joli O'Reuilly sur Perl.
                  Une erreur courrement faite on dirait :).

                  Les clopes Camel aussi ont pour emblème un dromadaire.

                  Les anglophones désignent par camel n'importe quel camélidé. Le dromadaire étant le dromedary et et la chameau le bactrian camel.

        • [^] # Re: perfs de java

          Posté par  . Évalué à -1.

          menfin bon, de ttes facons swing c moche, et meme avec le theme gtk ki va bientot etre ajoute, ca reste pas integre a mon bureau favori :)

          alors vive les applis java/gnome en gcj, qu'on puisse un peu oublier le c....


          (a quand le kernel linux en java gcj ? lol)

          sam

        • [^] # Re: perfs de java

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

          D'ailleurs moi il y a quelque chose qui m'ennuie un peu avec les JVM... C'est leurs optimisation douteuse sous linux.

          Je ne sais pas si vous avez testé la plateforme de développement eclipse, mais sa vitesse n'a compètement rien à voir entre windows et linux. Je n'irai pas jusqu'à dire que sous windows ça tourne à fond, mais au minimum 2 fois plus vite que sous linux. En tout cas pour la réactivité d'affichage des fenetres, y'a pas photos.

          Je ne sais pas trop qu'elle en est la cause (peut-être XFree)... Mais je trouve ca un peu dommage.

          Enfin, de toute manière ça ne m'empeche pas de l'utiliser sous linux même si ca ramouille un peu parce que c'est tout de même bien pratique :)

          • [^] # Re: perfs de java

            Posté par  (site web personnel) . Évalué à 4.

            je ne crois pas que ça vienne uniquement d'xfree !
            j'avais posté un journal a ce sujet, mais il semble que pour la jvm de sun, ils aient fait un gros effort sur la version windows, avec un garbage collector performant, et une bonne répartition de charge. Sur un bi-pro, avec une appli multithreadée, les deux procs sont utilisés a fond, et si l'appli ne l'est pas, les deux procs sont bien utilisés aussi, par la jvm, alors que sous linux c'est catastrophique
            est ce que c'est volontaire ? probablement !

            d'un autre coté, la jvm de blackdown a l'air plus optimisée que les autres, alors a quand une jvm totalement libre ? ça aiderai sûrement, non ?

            • [^] # Re: perfs de java

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

              J'ai trouvé ça dans une des sections explicatives des améliorations pour la version 3 d'eclipse : http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0(...)

              Proposed Items (Eclipse Platform subproject, Responsive UI theme)

              The following work items are being actively investigated, but we are not yet able to promise any solution for this release:

              ( new) Address platform-specific UI performance problems. There is a noticable UI performance and responsiveness difference between Eclipse running on Windows and Eclipse running on Linux GTK, Linux Motif, or QNX Photon, all on the same hardware, with Windows clearly outperforming the others. Improvements made to SWT alone have not reduced this "performance gap" enough. In order to improve Eclipse performance in the other operating environments, we need to make a concerted effort to determine the root causes (suspects include low-level thread scheduling and synchronization), and then take steps to address them. [SWT, Platform UI] [Theme: Responsive UI]

              • [^] # Re: perfs de java

                Posté par  . Évalué à 1.

                Je me demande ce que donneraient les résultats avec un kernel 2.6 et une jvm tunée pour ce kernel (qui a des améliorations au niveau scheduler/threads).

          • [^] # Re: perfs de java

            Posté par  . Évalué à 1.

            mmmh, bien déja windows est beaucoup plus réactif que XFree au niveau
            des fenetres. c'est flagrant ...

            Un début d'explication a été donné sur le site www.javagaming.org ... le mec en question dirigait la team Swing/Java2D chez sun, et son explication
            au problème était que la conception d'XFree rendait très délicate l'implémentation de composants GUI speed. [ je n'ai pas retrouvé ce passage, le site a été updaté il y a un an et le forum a été perdu , dsl ].

            Peut etre que les raisons avancées ne sont que les prémices d'un beau
            troll dans le but de masquer leur incompétence, mais c'est néanmoins la seule explication qu'il a donné .

            L'équipe de sun a fait aussi beaucoup d'efforts sur les libs relatives au développement de jeux vidéos [ xbuffering, page swapping, stockage des données en ram video, vrai fullscreen .... etc ] , et malheureusement à ma connaissance ces fonctionnalités ne sont disponibles que sous plateforme win.

            A l'heure actuelle je ne vois que l'association gcj/swt pour construire des gui speed ... c'est bien dommage :'((

            • [^] # Re: perfs de java

              Posté par  . Évalué à 2.

              Java Technology on Linux
              October 15, 2002

              Guest Speakers: Calvin Austin, Hui Huang, and Juergen Kreileder
              Moderator: Edward Ort (MDR-EdO)

              http://developer.java.sun.com/developer/community/chat/JavaLive/200(...)

              extrait :

              " The biggest issue with Linux is the number of threads and the thread overhead."

            • [^] # Re: perfs de java

              Posté par  . Évalué à 0.

              je crois qu'à ce niveau, c'est X le problème.

              (et non, ce n'est pas un troll)

              • [^] # Re: perfs de java

                Posté par  . Évalué à 1.

                Il n'existe pas une distribution linux dont le l'affichage et le bureau serait fait en java? (ma mémoire me jouerait-elle des tours?)

                Sinon est-ce que ce ne serait pas un remède à la lenteur du X et de libérer aussi la mémoire X pour la machine virtuelle Java qui en bouffe pas mal?

          • [^] # Re: perfs de java

            Posté par  . Évalué à 1.

            >D'ailleurs moi il y a quelque chose qui m'ennuie un peu avec les JVM... C'est leurs optimisation douteuse sous linux.

            Yep. On remarquera également l'absence sous linux d'une version officielle de l'API Java de communication (javax.com), permettant entre autres l'accès à un port série/parallèle. Il existe bien une alternative (la classe "gnu.io.RXTXCommDriver", par Kevin Hester) mais celle-ci prend en compte uniquement les ports séries...

            • [^] # Re: perfs de java

              Posté par  . Évalué à 2.

              L'implémentation libre de javax.comm qui est donc RXTX marche très bien avec les ports parallèles aussi.

              De plus cette implémentation n'est pas seulement disponible que sous Linux mais aussi sous Windows, SparcSolaris et MacOs me semble-t-il.

              http://www.rxtx.org(...)

              • [^] # Re: perfs de java

                Posté par  . Évalué à 1.

                >L'implémentation libre de javax.comm qui est donc RXTX marche très bien avec les ports parallèles aussi.

                Ooops, effectivement, je m'était basé sur le site de Kevin
                (http://www.geeksville.com/~kevinh/linuxcomm.html(...)):
                >There is no parallel port support. If you'd like to add this support, please join the RXTX development effort.

                L'information date un peu, apparement :)

          • [^] # Re: perfs de java

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

            Oui, la partie graphique est en général plus lente sous linux, mais bon, pour le reste, ce n'est pas si clair. Voir par exemple le volanomark (http://www.volano.com/report/index.html(...)) ou linux se défend bien. La conclusion du dernier test de volano est d'ailleurs un must...

      • [^] # Re: perfs de java

        Posté par  . Évalué à 2.

        Les versions 1.4.2 et 1.5 du jdk de Sun permettent l'utilisation de GTK . Sinon il reste SWTd'eclipse qui permet aussi de générer des interfaces GTK ( qt est à l'étude ).

      • [^] # Re: perfs de java

        Posté par  . Évalué à 1.

        avec l'avantage en prime d'avoir un beau code ...

        Ça c'est ton point du vue ... et personnellement, je n'aime pas du tout lire/relire du code en java !

      • [^] # Re: perfs de java

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

        abandonner la JVM au profit de GCJ

        Bof. Rien ne prouve qu'un code compilé en natif soit plus efficace qu'un code compilé en JIT (tu me diras qu'on pourrait avoir du JIT dans GCJ (on est d'ailleurs obligé pour faire du vrai Java), mais bon, ça devient n'importe quoi). En "regardant" un code java tourner, on peut faire des optimisations très sioux qui ne peuvent pas être faites statiquement...

        • [^] # Re: perfs de java

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

          Rien ne prouve qu'un code compilé en natif soit plus efficace qu'un code compilé en JIT

          Une fois "jitté" certes ! Mais il faut bien que le compilo JIT fasse son boulot alors qu'avec un compilo classique c'est déjà fait.

          Le régime permanent est similaire dans les deux cas mais l'une des deux solutions crée un régime transitoire beaucoup plus important ce qui se traduit par un manque de réactivité.

          Moralité :
          Si tu as une appli qui ne s'arrête jamais le code compilé en natif n'est pas plus efficace qu'un code compilé en JIT.
          Si tu as une appli utilitaire que tu n'arrêtes pas de lancer et d'arrêter, là le code natif est meilleur.

          • [^] # Re: perfs de java

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

            Nous nous sommes mal compris. Le code natif obtenu par le JIT peut être meilleur qu'un code compilé statiquement, par exemple en inlinant certaines méthodes alors qu'a priori (en analyse statique) on pouvait croire que ça ne valait pas le coup, en supprimant au vol certains tests (sur les bornes d'un tableau par exemple), etc. Les analyses statiques sur un code sont très coûteuses et beaucoup de compilateurs ne peuvent pas se permettre de les faire. Quand tu interpètes du code, faire une analyse en même temps ne coûte pas énormément plus, ce qui permet de faire des choses difficiles à envisager en statique.

          • [^] # Re: perfs de java

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

            Oups, j'ai oublié la moitié de ma réponse. Quand tu compiles ATLAS, la meilleure bibliothèque de calcul matriciel actuelle, ça prend en gros 2 heures (même sur une machine très récente), parce que le code est optimisé avec des techniques typiques des JIT (chronométrages de boucles, tests sur l'empreinte mémoire, etc.). Or, ATLAS ne fait rien, en terme de fonctionnalités : ça se limite à des produits de matrices. Imagines le temps de compilation pour une grosse appli.

          • [^] # Re: perfs de java

            Posté par  . Évalué à 3.

            un régime transitoire beaucoup plus important ce qui se traduit par un manque de réactivité.

            A condition bien sur que le passage par le regime transitoire ne permette pas de recuperer le temps perdu.

            Il n'est pas rare du tout que le retour sur investissement en JIT se fasse des le deuxieme passage dans une zone de tests. Un compilateur JIT est capable de determiner si la realisation d'un test est susceptible de changer ou pas, et si il y a des portions du tests qui seront toujours fausses. De la il peut parfaitement optimiser le compile.
            Au premier passage on aura Evaluation de la zone de test+compilation+evaluation optimisee du resultat, des le deuxieme on aura directement evaluation optimisee du resultat. Un language pur compile est incapable de faire ca. Sur des tests "lourds" l'overhead de java est negligeable au premier passage, et le gain au deuxieme est souvent monstrueux.

            Moralite :
            Si il y a des portions de ton programme qui servent plus d'une fois lors d'une utilisation standard, le JIT peut reserver des surprises.

            Kha

      • [^] # Re: perfs de java

        Posté par  . Évalué à 0.

        Seulement YAPL...
        oui mais c'est interprete donc c'est forcement plus lent que ce qui est compile...
        Pour des langages interpretables et compilables et independant de l'OS (toutes les librairies Java ne sont pas compilables!):

        Le langage OCaml (francais)

        http://caml.inria.fr(...)

        Le langage Scheme (americain)

        http://www.swiss.ai.mit.edu/projects/scheme/index.html(...)

        Pour etre sur une bonne fois pour toute que "JAVA EST BIEN UNE USINE A GAZ"
        (le lien qui suit est un comparatif de la plupart des langages)

        http://www.bagley.org/~doug/shootout/(...)

        Java se fait ramasser dans la plupart des tests...par OCaml par exemple.

        Mon avis perso: Java ce n'est bien qu'une mode et seule la puissance commerciale
        de SUN en est la cause...

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  . Évalué à 3.

    immuable ?

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . Évalué à 10.

    J'ai le rêve doux qu'un jour, les gens comprendront que Java en soi n'est pas lent. Malheureusement, c'est assez difficile de faire comprendre aux gens, même avec des benchs, que Java est aussi rapide qu'un autre langage. Pourquoi ?
    Parce que la plupart du temps, les programmes sont codés avec des méthodes assez sales, inspirées des fameux "débuter Java en 21 jours" et autres âneries qui proposent l'utilisation des classes anonymes, internes et autres stupidités qui ont pour but unique de créer un maximum d'objets, alors que ça n'a aucun sens.
    Malheureusement, pour qu'un développeur comprenne ça, il lui faut beaucoup de temps, et beaucoup de codes qui sont déja utilisés sont faits alors que le développeur ne le sait pas. Du coup, tout le monde croit que Java est lent, lourd, et tout ce qu'on veut.
    Mais pourtant, Java est utilisé dans les nouvelles générations de portables, qui ne sont pas des foudres de guerre. Pourquoi ?
    Parce que Java est sûr, facile à développer, et dispose de performances largement au niveau des autres langages.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 1.

      Tout a fait d'accord avec toi sur l'ignorance des gens à propos de java. Maitriser java [ le langage, l'utilisation de l'api, l'implémentation de l'api, la vm , le gc , les modèles de conception ... ] est un processus tres long...

      Je voulais juste préciser que l'utilisation en soi de classes anonymes ou internes n'est pas une stupidité ... c'est leur mauvaise utilisation - ie la gestion de la création d'objet - qui peut poser problème.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  . Évalué à 1.

        Maitriser java [ le langage, l'utilisation de l'api, l'implémentation de l'api, la vm , le gc , les modèles de conception ... ] est un processus tres long...

        C'est le principal problème de Java. Maîtriser Perl ou PHP, ça prend trois jours (allez, une semaine pour Perl). Java est le pain-bénit des charlatans qui vendent de l'"expertise" et du "consulting" à tout va à de pauvres gens dupés par la propagande des magazines informatiques.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  (Mastodon) . Évalué à 5.

          Oh ? Moi j'aime beaucoup Perl, mais alors je suis très très loin de le maîtriser, même après plus d'une semaine...

          Disons que je le maîtrise assez pour pouvoir écrire mes programmes, mais pas assez pour pouvoir comprendre à coup sûr ce que fait le programme de quelqu'un d'autre... Les joies du "Il y a plusieurs manières de le faire" :-)

        • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

          Posté par  . Évalué à 5.

          comme partout il faut du temps pour connaitre un langage et ses spécificités. Idem pour l'utilisation des libs. Pour java on peut noter qu'il
          n'y a qu'une api majeure qui réalise bon nombre de choses. C'est selon
          moi un gros [+]. Pas besoin de se prendre la tete à comparer les Xmilles libs dispos qui font la meme chose, plus ou moins différement.

          Tu dis que maitriser PHP prend 3 jour, maitriser perl prendrait 1 semaine. Bon la c'est net tu n'es pas sérieux :) Tous les gens qui font du php on fait au minimum 3 jour de php ... pourtant tout le monde n'est pas un php
          guru ... et a regarder de plus pres du code php on observe qu'il a ceux qui
          savent [ bien ] coder du php et les autres ... idem pour perl .... ne connaissant que peu perl et si j'avais a en faire, l'expertise d'un guru perl me semblerait la bienvenue.

          • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

            Posté par  . Évalué à 0.

            Est-ce qu'on peut parler français ? Pour moi un gourou ("guru") c'est un type qui lance des incantations ;)

            Sérieusement. Je n'ai pas parlé de devenir un "gourou", mais d'être capable de programmer correctement. PHP est à peu près le langage le plus beginner-friendly à l'heure actuelle ; Java est à l'opposé. Trouve-moi un doc aussi concis, simple, accessible que le manuel officiel PHP pour se mettre le pied à l'étrier en Java. Pour programmer correctement, tu n'as pas besoin de connaître l'API par coeur ; il suffit de connaître le langage et de s'être familiarisé avec la structure de l'API (à condition d'avoir une doc correcte à disposition, ce qui est le cas pour PHP).

            Pas besoin de se prendre la tete à comparer les Xmilles libs dispos qui font la meme chose

            Je n'ai pas parlé des XWindowseries, j'ai parlé de PHP et Perl. Les principaux modules de PHP sont livrés dans la distribution standard. Pour Perl, il y a CPAN. Je ne connais pas Python mais j'imagine qu'il y a ce genre de choses aussi.
            Quant à Java, l'API est centralisée mais elle est mammouthesque.

            et a regarder de plus pres du code php on observe qu'il a ceux qui
            savent [ bien ] coder du php et les autres

            Qu'est-ce que tu essaies de démontrer ? Ce n'est pas parce qu'un langage est plus facile qu'un autre qu'il n'y a pas de mauvais programmeurs. Ce n'est pas parce qu'on arrive pas à lire un programmer Perl mal foutu qu'on n'est pas capable de programmer correctement en Perl.

            • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

              Posté par  . Évalué à 1.

              et en francais, "beginner-friendly", ca donne quoi ?

            • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

              Posté par  (site web personnel) . Évalué à 4.

              pas begginer friendly, goret friendly

              90% du code php c'est programmé rapide et mal (voir le support objet de php..)

              • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

                Posté par  (site web personnel) . Évalué à 7.

                Entièrement d'accord avec toi.

                Ce langage qui semble si attrayant quand on le découvre alors qu'on sort du C/C++ se montre vite assez ignoble.

                Tu parles du support objet bancal, mais il y a aussi les inconsistances dans le nommage des fonctions... même au sein d'une seule "lib" ( http://www.php.net/manual/en/ref.strings.php(...) ), certaines fonctions agglutinent, d'autres utilisent le _ pour séparer les mots : stripslashes() vs. strip_tags() par exemple.

                Sans oublier que « c'est tellement facile » qu'on se retrouve avec un source où structure HTML et instructions php se mélangent allègrement...

                Vous l'aurez compris, je n'aime plus ce langage :)

                • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

                  Posté par  . Évalué à 7.

                  Je suis d'accord avec toi que PHP manque un peu de structure (nom des fonctions, codage en pseudo-objet, etc.) mais cela devrait être remis à plat lors de la nouvelle version (PHP 5).

                  Rappellons également que PHP est un language très jeune, 7/8 ans pas beaucoup plus AMHA.

                  Ses performances, ses "libertés" de programmation (tu peux faire des choses très vite fait et mal codées mais qui fonctionnent ou faire du code très propre) sont des atouts très interressants pour des developpements (web) qui évoluent en permanance. PHP est bien fait pour ce genre de chose. Le p'tit stagiaire va pouvoir faire sa page web sans trop de problème et rapidement être motivé pour faire la suite.

                  Java, c'est un gros bouzin dont les fonctionnalités sont énormes (et interréssantes) mais qui necessite une expertise pointue (de l'experience et des connaissances). Les projets qui utilisent java pour faire du java, on en voit trop souvent et on voit bien dans le code qu'ils ne profitent en rien des suptilités du language (objet qui ressemble à une grosse bibliothèque de methodes).
                  Java, pourquoi pas ? ou plutôt Java ! Pourquoi ?

                • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

                  Posté par  . Évalué à -4.

                  « c'est tellement facile » qu'on se retrouve avec un source où structure HTML et instructions php se mélangent allègrement...

                  C'est marrant tous les gens qui sont allergiques au mélange code/HTML. C'est pourtant un des avantages d'un langage comme PHP. Note : personne ne t'oblige à mélanger code et HTML ; mais tu en as la possibilité et c'est très bien comme ça (sauf pour les intégristes fatigants de la programmation élitiste qui voudraient bien forcer les autres à ne programmer que d'une manière standardisée).

                  Et si le programmeur est mauvais ou paresseux, ce n'est pas le langage qu'il faut remplacer.

              • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

                Posté par  . Évalué à -2.

                J'adore ce genre d'arguments. Personnellement les rares fois où j'ai dû débugger du code Java c'était écrit avec les pieds (et bonjour le casse-tête quand la conception objet est foireuse : du genre confusion encapsulation / héritage). Comme quoi, les anecdotes, on peut leur faire dire ce qu'on veut, et n'importe quel langage aux mains d'un programmeur peu soigneux peut devenir une horreur (mais Java a l'avantage de la constance sur ce point :-)).

                voir le support objet de php.

                Ca ne gêne que ceux qui ne jurent que par l'objet et ne comprennent pas le bénéfice de la simplicité. PHP a au moins l'intérêt de proposer de l'objet en plus du procédural, alors que Java ne connaît pas le procédural, ce qui oblige à faire de la conception lourde pour la moindre petite appli. Remarque, c'est bien, ça gonfle le prix des prestations, ce qui rejoint mon propos du départ.

                • [^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes

                  Posté par  . Évalué à 3.

                  "Ca ne gêne que ceux qui ne jurent que par l'objet et ne comprennent pas le bénéfice de la simplicité."

                  J'ai vu du C plus agreable que du java. L'inverse aussi. Depend des codeurs et du lecteur, pas du langage. L'objet est supposé se rapprocher de la façon dont l'Homme apprehende les choses.

                  "Java ne connaît pas le procédural"

                  J'ai vu des methodes de 300 lignes en java... je crois que l'on est loin de l'objet avec son identité, son comportement et son état... ou d'une conception compliquée: y en a pas.

                  "ce qui oblige à faire de la conception lourde pour la moindre petite appli"

                  cf plus haut.

                  "ce qui rejoint mon propos du départ."

                  L'histoire des charlatans ? C'est pareil dans tous les secteurs, pour toutes les technos.

                  "les intégristes fatigants de la programmation élitiste qui voudraient bien forcer les autres à ne programmer que d'une manière standardisée"

                  Ou qui voudraient simplement faire passer des moulinettes dans le code ? Qui voudraient que les gens puissent se comprendre et travailler efficacement ensemble ?

                  Il y a de vrais integristes fatiguants quelle que soit la techno.

                  "Ca ne gêne que ceux qui ne jurent que par l'objet et ne comprennent pas le bénéfice de la simplicité"

                  Ceux qui ne comprennent rien à l'objet, pensent que c'est plus compliqué que du procedural.

                  Enfin bon, je te sens aigri avec Java. Perso, je m'en fiche. C'est un langage comme un autre et je pensais que ca allait troller plus sur l'article qui a lui seul vaut dejà 150 commentaires, mais qui auraient été probablement plus interessant que ton troll de petit joueur.


                  Bref, je te rejoins que sur un seul truc. Java, c'est proprio.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

          allez, une semaine pour Perl

          Quel humour ! Tu maîtrises les regexp Perl en une semaine ? Tu maîtrises la sémantique délirante de Perl en une semaine ? Tu peux relire un programme évolué en Perl en une semaine ? Quel pipo lamentable.

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

            Posté par  . Évalué à -1.

            Quel pipo lamentable

            Je te donne un mois pour Perl si ça te chante ;-) Ca ne change rien au fait que c'est dix fois moins que pour Java.

            (quand même, pour répondre : les regexps, ça existe en-dehors de Perl, même si celles de Perl ont plus de fonctionnalités ; la "sémantique délirante", je vois pas, toutes les structures classiques sont très compréhensibles, les machins exotiques étant superflus pour l'écriture d'un programme normal ; "relire un programme évolué", oui, s'il est bien écrit, et je dirais même plus qu'en Java : ce n'est pas ma faute si certains programmeurs Perl sont des amateurs d'obfuscation, et ça ne change rien à l'utilisabilité du langage en lui-même)

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

              Posté par  . Évalué à 1.

              entièrement d'accord, Perl est beaucoup plus simple à utiliser que java, la "learning curve" est beaucoup plus rapide, même si on n'est pas un kador de Perl en un mois ou une semaine, on peut faire des choses fonctionnelles très rapidement, et la sémantique n'est pas délirante, elle est juste très pratique une fois qu'on a capté mais surtout, on peut si on veut l'écrire complètement classiquement tellement que ça ressemble à du javascript (mais c'est dommage de se passer de l'utilisation implicite de $_ par exemple).
              Perl c'est vraiment bien :)

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 3.

      je suis pas convaincu que les classes internes et anonymes soient responsables de pertes de performances. En effet, une classe interne est compilé dans un fichier ClasseMere$ClasseInterne.class et une classe anonyme dans ClasseMere$1.class
      Ce sont des classes commes les autres une fois compilées.
      Je vois pas pourquoi elle pourraient ralentir le programme...

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  (Mastodon) . Évalué à 3.

        C'est plus une pratique de programmation qui encourage à multiplier les classes. Le chargement de classes et la créations d'objet est un processus plus long qu'un appel de méthode (surtout si la méthode peut être "inlinée"), donc au final, ça alourdit le programme. Mais je ne sais pas si c'est vraiment si sensible que ça.

        Personnellement je n'aime pas le langage Java (et pourtant je m'en suis assez bouffé pour programme relativement proprement... enfin autant que possible, en Java), donc que les implémentations soient rapides ou pas, c'est la même chose.

        Pour le type de programmes que je fais, par exemple, Ruby est bien plus rapide, alors que c'est un langage (interprété) réputé lent. Pour ce que je fais, il est plus rapide en temps de développement, et (au feeling) plus rapide à l'exécution... Mais je ne fais pas des calculs scientifiques avec, par exemple, je ne prétend pas être un benchmark vivant :-)

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

          surtout si la méthode peut être "inlinée"

          Oui, enfin, les classes anonymes et internes, c'est fait pour implémenter des pointeurs sur fonction objets, alors dans ce genre de cas, l'inlining est par définition impossible. Donc ça ne change rien. D'autre part, je ne suis pas sûr du tout que le chargement des classes prennent vraiment du temps en Java et de toute manière, c'est négligeable sur un programme qui tourne plus de quelques secondes.

          Ceci étant, si le sens de ton post est de dire qu'il manque des pointeurs sur fonction en Java, c'est un point de vue qui se défend, mais un tel ajout demanderait la modification de la JVM, alors bon...

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

            Posté par  (Mastodon) . Évalué à 1.

            «Ceci étant, si le sens de ton post est de dire qu'il manque des pointeurs sur fonction en Java»

            Non, je ne trouve pas que ça manque. D'ailleurs je ne faisais qu'expliquer ce que voulait dire le monsieur plus haut, en précisant que moi même je doutais que ça soit réellement sensible niveau performances.

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

            Il y a d'autres métthodes que ces horreurs pour implémenter ces pointeurs sur fonctions, mais le débat n'est pas là. Ce n'est pas seulement le chargement de classes qui est long,c 'est aussi le fait qu'à chaque appel de la méthode définissant la classe, on crée une nouvelle instance. Et ça, c'est long.

            Quant aux pointeurs sur fonctions, ils sont disponibles beaucoup plus facilement en utilisant correctement les interfaces. On appelle çàa du design by contract ;-)
            Et pour les vrais porcs, il y a aussi l'objet Method qui, lui, est un vrai pointeur sur fonction, ou plutôt pointeur sur méthode.

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

              J'ai la désagréable sensation que tu ne comprends pas trop de quoi tu parles.

              Ce n'est pas seulement le chargement de classes qui est long,c 'est aussi le fait qu'à chaque appel de la méthode définissant la classe, on crée une nouvelle instance. Et ça, c'est long.

              Je ne vois pas en quoi les classes anonymes changent quelque chose à ça. Pour programmer une classe anonyme, il faut se baser sur une interface. Si tu n'implémentait cette interface par une classe anonyme, tu le ferais par une classe normale et tu aurais exactement le même nombre de chargement de classe et de création d'instance, sauf si tu programmes comme un porc, ce qui n'a rien à voir avec les classes anonymes.

              Quant aux pointeurs sur fonctions, ils sont disponibles beaucoup plus facilement en utilisant correctement les interfaces. On appelle çàa du design by contract ;-)

              Oui, donc tu n'as rien compris. Parce que pour faire une classe anonyme, il faut une interface...

              Et pour les vrais porcs, il y a aussi l'objet Method qui, lui, est un vrai pointeur sur fonction, ou plutôt pointeur sur méthode.

              Les pointeurs sur fonction obtenus grâce aux classes anonymes sont typés statiquement, ce qui n'est pas le cas des appels par l'objet Method. De plus, celui-ci nécesite aussi un création d'objet et, étant basé sur l'api de réflexion, il rame. Bref, tu racontes vraiment n'importe quoi.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

        Elles le sont, par le simple fait que, à chaque passage dans la méthode qui crée l'instance, on recrée une nouvelle instance de cette classe alors qu'on aurait en général très bien pu utiliser l'ancienne instance. Ca, c'est pour les classes anonymes.
        Pour les classes internes, écris-en une sous Eclipse qui accède aux données de la classe encapsulante et regarde le message d'erreur.
        En clair, il dit qu'il doit créer une méthode accesseur, et passer de fait la visibilité de private à protected, juste pour ta pauvre classe interne. Tu aurais très bien pu coder toi-même une seconde classe, non interne, dans le fichier, qui fasse la même chose. Tu aurais alors nettement gagné en propreté des accès, et en évolutivité, puisque tu peux alors beaucoup plus facilement séparer tes deux classes.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 1.

          Je signale juste que les erreurs et warnings à la compil sont réglables (prefs/java/compiler). Pour mes classes internes, je n'ai pas de problèmes, j'accède aux variables de la classe principale depuis les classes internes sans soucis.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

          Oui, enfin, quand tu utilises une classe anonyme pour implémenter un listener, tu ne crèe qu'une seule instance, donc je ne vois pas où ça rame.

          Sinon, je suppose que tu décris un bug d'Eclipse, parce qu'une classe interne accède directement à tout le contenu de la classe englobante, même aux variables privées. C'est d'ailleurs un des intérêts des classes internes, par exemple pour implémenter des itérateurs.

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

            Oui, enfin, quand tu utilises une classe anonyme pour implémenter un listener, tu ne crèe qu'une seule instance, donc je ne vois pas où ça rame.

            On parle bien de la même classe anonyme, là ?
            Celle que tu définis avec un 

            
addListener(new WindowListener() {
            
public void windowClosed() {
            
// je ne fais rien
            
}
            
// etc, ad nauseam
            
});


            Celui-là, ?
            Et bien dans ce cas, à chaque appel de la méthode où tu as ce code, tu crées une nouvelle instance de ta classe, par définition. Et donc, tu ralentis ton code.

            Sinon, je suppose que tu décris un bug d'Eclipse, parce qu'une classe interne accède directement à tout le contenu de la classe englobante, même aux variables privées. C'est d'ailleurs un des intérêts des classes internes, par exemple pour implémenter des itérateurs.
            Non, je décris le message d'information que peut te renvoyer Eclipse, avec une compilation un peu stricte, lors de l'utilisation de telles classes. Tout simplement parce que la création de l'accesseur synthétique est la seule méthode pour accéder à ces champs private.

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

              Et bien dans ce cas, à chaque appel de la méthode où tu as ce code, tu crées une nouvelle instance de ta classe, par définition. Et donc, tu ralentis ton code.

              Et ça t'arrive souvent de faire des "addListeners()" en boucle toi ? Bien sur que ça crée une instance de la classe, il faut bien qu'il y en ait une. Ou est le problème ?

              • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

                Et ça t'arrive souvent de faire des "addListeners()" en boucle toi ? Bien sur que ça crée une instance de la classe, il faut bien qu'il y en ait une. Ou est le problème ?

                Ca arrive lorsque, par exemple, les boutons ne sont pas recyclés, ou le code est généré, ou le développeur n'est pas très malin.
                En gros, oui, ça arrive, et plus souvent qu'on ne croit.
                Et pour parler d'autre chose que des listeners, on le fait souvent aussi lorsqu'on crée un FileFilter dans une méthode, et que cette méthode charge un ensemble de fichiers plusieurs fois dans l'application.
                Enfin bref, il y a tout un tas de contextes où ça peut arriver, et surtout où ça risque d'arriver plusieurs fois dans la vie de l'application. Et si c'est à chaque fois qu'un bouton est affiché dans l'interface, ça peut monter très haut, et générer énormément d'instances, alors que l'utilisation d'un Listener codé dans une classe séparée est plus propre, et permet en outre de gérer ce pattern singleton.

                • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

                  En gros, oui, ça arrive, et plus souvent qu'on ne croit.

                  Je ne vois pas comment ça peut causer un pb de perfs. Pour chaque listener il y a un objet derrière (disons un bouton), donc bien avant que la création des listeners eux-mêmes puisse poser un pb, la création de ces objets va en poser un bien plus immédiat.

                • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

                  Ca arrive lorsque, par exemple, les boutons ne sont pas recyclés, ou le code est généré, ou le développeur n'est pas très malin.
                  C'est problème de développeur, pas de langage.
                  Dans tous les langages on peut commettre de telles horreurs sous-optimisées.

                  générer énormément d'instances, alors que l'utilisation d'un Listener codé dans une classe séparée est plus propre, ...
                  Tu peux générer autant d'instances si ta classe est séparée que si c'est une classe interne (anonyme ou non). Ce sont deux notions parfaitement orthogonales.
                  Et moi ça ne me parrait pas nécessairement plus propre de créer un fichier juste pour y mettre une classe d'une seule méthode dont le corps fait trois lignes à tout casser.

                  Dans le cas où le code de la classe interne doit accéder aux attributs ou aux méthodes de la classe externe (ce qui est fréquent pour un event listener), il faudrait fournir une instance de l'ex-objet externe à l'ex-objet interne, et probablement augmenter inutilement la visibilité de certains attributs/méthodes de l'ex-classe externe.

                  ...et permet en outre de gérer ce pattern singleton.
                  1. il y a des cas qui se prettent pas naturellement au pattern singleton
                  2. on peut faire un sigleton avec une classe interne aussi bien qu'avec une classe dans un fichier séparé
                  3. avec une classe anonyme on peut faire la même chose :
                  static private WindowListener listener = new WindowListener() {
                  
    public void windowClosed() { /* blah blah */ }
                  
});

                  et ensuite : addListener(listener);

                  Après, si le développeur ne sait pas réutiliser des objets, ... (en gros qu'il ne sait pas faire de prog objet correctement), il ne faut pas mettre ça sur le dos du langage...

                  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

                    Après, si le développeur ne sait pas réutiliser des objets, ... (en gros qu'il ne sait pas faire de prog objet correctement)

                    Ah, parce que réutiliser des objets c'est de la programmation objet "correcte" ? Il me semble au contraire que c'est parce qu'il est toujours trop couteux en Java de créer des objets qu'on est obligé de les réutiliser.

                    C'est clairement un des points ou Java a totalement échoué : la façon "instinctive" d'utiliser le langage fait écrire du code pas performant. Il faut apprendre des techniques pas du tout triviales pour éviter ça, et ça complexifie d'autant l'écriture des programmes. C++ a le même problème mais pas sur la création d'objet (plutôt sur les affectations, la manière "instinctive" de faire induit des plantages ou des fuites de mémoire).

                    Après, évidemment les "experts" disent "ah mais oui si tu fais comme ça c'est que tu sais pas coder". Non, c'est faux. C'est le langage qui est mal conçu.

                    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

                      Ah, parce que réutiliser des objets c'est de la programmation objet "correcte" ?
                      Suivant les cas, oui.

                      Il me semble au contraire que c'est parce qu'il est toujours trop couteux en Java de créer des objets qu'on est obligé de les réutiliser.
                      La création d'un objet nécessite une allocation mémoire, c'est une opération coûteuse dans tous les langages.

                      C'est clairement un des points ou Java a totalement échoué : la façon "instinctive" d'utiliser le langage fait écrire du code pas performant. Il faut apprendre des techniques pas du tout triviales pour éviter ça, et ça complexifie d'autant l'écriture des programmes.
                      Tous les langages et toutes les méthodes de programmation nécessitent un apprentissage...

                      Après, évidemment les "experts" disent "ah mais oui si tu fais comme ça c'est que tu sais pas coder". Non, c'est faux. C'est le langage qui est mal conçu.
                      Ah ? Tous les langages dans lesquels le premier venu peut coder comme un goret sont des langages mal conçus ? Il ne doit pas y avoir des masses de langages bien conçus alors...

                      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

                        Suivant les cas, oui.

                        A part les cas où c'est nécéssaire pour des raisons de performances, à quels cas penses-tu ?

                        La création d'un objet nécessite une allocation mémoire, c'est une opération coûteuse dans tous les langages.

                        Non. En C++, si tu crée un "petit" objet sur la stack, ça n'est pas très couteux...

                        Tous les langages et toutes les méthodes de programmation nécessitent un apprentissage...

                        Tu n'as pas compris : si tu apprends la programmation objet, en général la réutilisation des objets ne sera pas présenté comme un concept de base, bien au contraire. Ça sera plutôt dans la section "trucs et astuces si votre programme rame vraiment trop".

                        Ah ? Tous les langages dans lesquels le premier venu peut coder comme un goret sont des langages mal conçus ? Il ne doit pas y avoir des masses de langages bien conçus alors...

                        Je ne parle pas du "premier venu". Ceci dit, oui, il n'y a pas beaucoup de langages bien conçus sur ce plan là (je ne connais que Python et Ruby qui s'en sortent).

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

        Ta bien raison de ne pas être convaincu, parce que c'est une grosse connerie.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 3.

      Mais ces fameux programmes rapides écrits en Java, où sont-ils !?!

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

      >autres âneries qui proposent l'utilisation des classes anonymes, internes et autres stupidités

      Ben ok, mais tous les tutoriels utilisent ces anneries, et si tu as des liens vers des tutoriels qui s'en dispensent je suis preneur.

      En particulier pour les listenners sur un evennement.

      Swing est une usine à gaz à lui tout seul, et tu fais 50 copier/coller pour gérer les évenements d'une fenêtre.
      C'est peut être trés jolis au niveau conceptuel, mais relire un programme swing tient plus du jeu de labyrinthe ou il faut se rappeller de tous les embranchements qu'autre chose.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

        Je n'ai évidement pas de liens, pusique comme tu le dis, tous les tutoriels abusent de ces errements du langage.
        Cependant, si tu essayes de coder sans, tu te rendras compte que le code est plus lisible, et donc plus maintenable et plus rapide (puisqu'il est plus facile d'optimiser quelque chose qu'on peut lire, et qu'en plus on ne crée pas une instance à chaque appel de méthode, la plaie de Swing).

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 2.

      Ce n'est peut-etre pas tres lent mais alors qu'est-ce que ca bouffe comme memoire:
      http://www.bagley.org/~doug/shootout/lang/java/(...)

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

        C'est intéressant comme remarque car ça soulève un vrai point du Java. Ce qui est lourd en mémoire, c'est la machine virtuelle. Et personnellement, ça ne me surprend pas trop. En effet, cette machine virtuelle est un gros programme qui va transformer à la volée ton code. Tu t'attends vraiment à ce que ce soit léger comme code ?
        Pas moi. Il est clair que si tu disposais d'un processeur Java, l'encombrement mémoire de tes programmes serait nettement moins lourd, puisque par exemple les classes System et compagnie ne seraient pas des émulations interrogeant la machine physique.
        En l'occurence, ce n'est pas le cas, et il faut faire avec.
        Cependant, la JVM 1.5 va apporter un début de réponse avec le mode serveur, qui permettra de lancer tous les programmes dans la même VM, plutôt que d'en lancer une par instance de JEdit ;-)

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 1.

          en fait il est actuellement possible de lancer tous les programmes dans la meme jvm ... mais ca reste malheureusement de la "bidouille" :(

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 2.

          Je suis d'accord qu'un programme basé sur une VM va forcément consommer plus de CPU/RAM. Mais ce dont on parle dans ce thread c'est bien des performances du langage, et pour cela il faut le comparer aux autres. Que ce soit utile, cross-platform, facile à apprendre, souple et tout ce qu'on veut soit, je dis juste que c'est une belle pompe à RAM comparé à Perl par exemple (même si ce n'est pas tout à fait comparable).

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

            Je suis d'accord qu'un programme basé sur une VM va forcément consommer plus de CPU/RAM. Mais ce dont on parle dans ce thread c'est bien des performances du langage, et pour cela il faut le comparer aux autres.

            Et comment tu le compares aux autres sans utiliser la machine virtuelle ? Pour ma part, une comparaison de deux langages sous machine virtuelle serait une erreur, puisque ça correspond plus à une proof of concept qu'à une vraie utilisation. La seule comparaison qui vaille réellement est celle dans un environnement réel, en l'occurence ton OS préféré.

            Que ce soit utile, cross-platform, facile à apprendre, souple et tout ce qu'on veut soit, je dis juste que c'est une belle pompe à RAM comparé à Perl par exemple (même si ce n'est pas tout à fait comparable
            Donc tu compares avec la machine virtuelle, ce qui est normal puisqu'il s'agit d'un tout. Tu peux difficilement dissocier le langage de Java de sa plateforme et de ses bibliothèques.
            Et au final, on est d'accord.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 2.

          C'est vrai cà, que sont devenus tous ces projets de processeurs Java genre Javachip et compagnie ? C'est tombé à l'eau ou est-ce qu'on a encore une chance de les voir un jour dans nos téléphones portables ?

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  . Évalué à 8.

    Autres légendes urbaines :

    - Linux est difficile à prendre en main pour les débutants
    - Windows n'est pas fiable
    - Perl permet de faire facilement du code illisible
    - Les BSDistes sont des trolleurs

    Comme quoi, dans les légendes, y a toujours une part de vrai ;)

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

    On peut me dire ce que l'on veut sur la rapidité du Java : je veux bien le croire que c'est aussi rapide que du CPP, mais tu as la machine virtuelle dernière et c ça qui fait chier à mon avis (une fois qu'elle est lancée l'exécution peut être rapide).

    En plus c bien beau de le dire mais si on prend deux exemple simple pour comparer Java et CPP :
    Borland C++ Builder et Boland JBuilder, deux IDE propriétaires développés par la même boite (donc a priori la même rigueur de développement et de gestion de projet), il faudra alors m'expliquer pourquoi est ce que C++ Builder est bien plus "légé" et bien plus utilisable sur une machine équivalente que JBuilder.

    Je peux prendre beaucoup d'exmple comme ça : pourquoi JEdit est une baleine (car s'en est une pour un éditeur texte), il a plein de fonctionnalité, mais bon.

    Alors je le laisse bien la faute va retomber sur SWING, mais Java étant tout pourris au niveau UI sans SWING : rien de propre et d'intégré dans le JDK, pour faire un afficher correct en mode texte par exemple, ils sont ou les ncurses et autre termcap en Java pur !!!, on à pas le choix c SWING.

    Quand a SWT, autant faire directement du CPP avec wxWindow, car pour c pas du java pur.

    Enfin pour finir et pour dire que malgé tout j'aime bien JAVA, je viens d'essayer gcj-3.3 avec le support de SWING et AWT en compilation native, et là ouais le JAVA c bien :)

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

    Je ne sais pas si cela fera avancer la discussion.... mais il y a ce document
    http://www.internalmemos.com/memos/memodetails.php?memo_id=1321(...)

    Mon avis personnel.... j'ai vu plus de machines enterrées à cause de Java qu'à cause de C, C++, Cobol.

    Sinon au niveau programmation :

    - Tjs utiliser le niveau max de warning (-Wall sur gcc) ..... si le compilo ns jette c'est qu'en général on n'est pas assez clair dans le code écrit (à priori le compilateur gcc est plus carré que le compilateur cc d'HPUX semble-t-il)

    - Essayez l'Ada.... une fois que le programme compile (il est plus que carre le compilateur à ce niveau)....il y a de très forte chances pour que le programme fonctionne comme désiré.... C'est pas comme en C où le compilateur ne gueule pas et où on se mange un segmentation fault dans la tete de temps en temps parce que l'on a oublie de reserver de la memoire (c un peu pour ca que l'Ada est utilise sur Ariane) et regardez ce lien pour s'en convaincre http://www.adaic.org/whyada/ada-vs-c.html(...)

    Sinon au niveau programmation Java :

    - Pensez à catcher les exceptions correctement et pas juste mettre les instructions try & catch minimum pour que le compilo ne gueule pas

    Et je précise que je n'aime pas la programmation c'est bien pour ca que j'ai choisi le métier d'inge systeme (meme si je suis de temps oblige de remettre les mains ds le camboui de temps en temps)

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 1.

      C'est vrai que Ada a l'air quand meme carrement plus fort que Java, C, C++... Il semble dans "la cour des grands", celle des langages pensés pour de l'ingénierie logicielle de grande envergure, pas pour des petits programmes sur un coin de table.

      Par contre, la base d'utilisateur est quand meme faible, et la conséquence n'est-t-elle pas un manque cruel de librairies ?

      Ceux qui connaissent bien Ada, y a-t-il des librairies OO pour les UI portables par exemple ? (genre bindings GTK ou QT ou wxWindows) ?

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 0.

      > j'ai vu plus de machines enterrées à cause de Java qu'à cause de C, C++, Cobol.

      java vis a vis de c /c++ c'est comme le proprio face au libre : dans le libre , c'est parfois plus dur a mettre en place , mais on a un controle total sur ce qu'on fait, sur les evolutions.... alors que le proprio impose ses choix, son timming,...

      en c/c++ on a un control total, avec java on depend , entre autres, de la VM

      perso , je n'ai rien contre le language java , mais je ne peux pas blairer la presence de la VM. La VM Java c'est la reponse des annes 90 de l'industrie au pb de la fragmentation des Unix . Avec linux tournant sur toutes sortes de machines, cela n'a pas d'interet.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  . Évalué à 3.

        Avec linux tournant sur toutes sortes de machines, cela n'a pas d'interet
        Si tu veux faire tourner une appli sur une machine dont tu ne connais pas l'architecture (c notre cas, on code pour un serveur Linux mais ce pourrait très bien devenir un windows dans le futur), tu codes en Java. La présence de linux sur "toutes" les archis ne change pas le problème du client qui ne veut pas changer d'OS (à cause d'une appli proprio par ex).

        (au fait, java très bien, merci =>[])

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 2.

          Si tu veux faire tourner une appli sur une machine dont tu ne connais pas l'architecture (c notre cas, on code pour un serveur Linux mais ce pourrait très bien devenir un windows dans le futur), tu codes en Java.

          Moi je voudrais qu'on m'explique un truc, c'est l'omniprésence de Java dans les projets d'applis cross-platform. ça fait un an maintenant que je me suis mis à Python, et j'ai de plus en plus de mal à trouver des avantages à Java. Avec Python, j'ai la même portabilité, les mêmes possibilités (web services, XML, connection SGBD, applications web, GUI, appel de libs C ou autres très facile - en tout vachement plus simple que JNI, des bindings à foison - OpenGL etc...), du code vachement moins verbeux, une emprunte mémoire bien plus petite et une vitesse d'exécution a priori équivalente, du moins pour ce que j'ai fait jusque là.

          Je veux bien qu'il y ait tout le marketing Sun derrière (alors que les pythoniens ont une culture d'aimables farceurs qui AMHA peut les desservir), mais ça n'explique pas tout.

          (et oui, ça ressemble à un troll, mais je m'en fous du moment que j'ai des réponses constructives...)

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

            Posté par  . Évalué à 1.

            De mon point de vue (qui n'engage que moi), la visibilité n'est pas du tout la même. Java est poussé par une équipe de marketeux très forts et est plûtot répandu tandis que Python est plus un langage nettement plus confidentiel et lié au Libre (ce qui est plutôt un désavantage dans la tête des décideurs(tm)).

            Je ne dénigre pas les qualités de Python, langage que je connais très peu (je dois bien l'avouer) et que j'aimerais connaitre plus (si j'avais du temps bien sûr), mais la mode est à Java en ce moment.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  (Mastodon) . Évalué à 1.

        Mais comme on ne [pv]eut pas "imposer" Linux (ou plutôt la Glibc et équivalents), l'utilisation d'une machine virtuelle permet de travailler sur un ordinateur "parfait" qui sera identique partout. Coder en Java, c'est coder pour cette architecture là. En fait que la machine soit virtuelle ou pas, peu importe, c'est la même chose.

        C'est juste un peu plus lent sur une machine virtuelle que sur une machine matérielle (ce qui pousse à compiler au vol), et il n'y a pas assez de marché pour produire des ordinateurs donc l'architecture matérielle est celle de Java (la plateforme).

        En Java, on dépend de la VM, en C/C++ on dépend de la MM (machine matérielle ), donc c'est à mon avis un mauvais argument.

        Moi je rêve d'une JVM libre qui tourne partout, même s'il est peu probable que je code en Java (le langage) pour cette JVM.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

        Parce que le libre n'a pas de contrôloe sur l'évolution de Java ? Tu connais le JCP ? (http://www.jcp.org(...))
        C'est un comité ouvert qui détermine les évolutions du langage. Et après, tu me parleras de la machine virtuelle, et je te répondrai qu'il en existe plusieurs pour chaque plateforme. Sun, IBM, Weblogic, et autres proposent des machines virtuelles, il n'y a donc pas trop de problèmes de ce côté-là.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 2.

      L'Ada est en effet un langage très agréable à l'utilisation, et surtout, pour le peu que j'en ai fait, très pratique pour des applications temps réel (le système des RDV est à tomber par terre tellement il est simple et performant)

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

      Au fait un truc que j'ai pas précisé....gcc inclus le support d'Ada (avec un grand A pour les puristes ;-) ).... Donc normalement avec votre distrib linux actuelle vous pouvez faire de l'Ada.

      Et le code sources de vos programmes Ada est portable !!! Donc en général une simple compilation est nécessaire pour changer de plateforme...

      Que dire encore.... regardez la beauté des possibilités des "generique'" et comme le fait remarque qq d'autre le traitement des rdz-vous

      Bref un grand langage pas assez utilisé

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  . Évalué à 1.

        C'est a dire que les conditions de sa naissance (appel d'offre du darpa - Defense Advanced Research Projects Agency americain) et ses premieres applications (embarque dans des satellites ou des chars ;) n'ont pas reellement aide a rendre populaire ce langage.

        Maintenant, si tu travailles dans la defense ou l'aerospatiale, ya pas de probleme, t'en verra, des gens qui utilisent ada...

        C'est juste que c'est pas exactement la meme communaute d'utilisateurs, pas les memes priorites et pas le meme marketing.

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  . Évalué à 2.

    L'idée de pouvoir développer des applications indépendantes de la plateforme est séduisante. Mais à quel prix ? Quand je vois le nombre de personnes qu'il est nécessaire de mettre sur un projet Java comparé à des environnements plus traditionnels (souvent un rapport 2 à 3), je m'interroge sur les gains in fine, en terme de gestion de projet, de conception, de développement et de maintenance.

    Je trouve que l'on est arrivé à de sacrées usines à gaz - proprio ou pas. En outre, je constate (mais des exceptions peuvent exister, il faut l'espérer) que nombre de "spécialistes" Java sont malheureusement infoutus d'appréhender la notion de système d'information dans son entièreté et donc incapable de concevoir un projet ou ses modules. Et une conception râtée, c'est un développement râté et donc un projet qui dérape et qui coûte la peau des fesses avant même la fin de la phase de recette.

    A mon avis, en se concentrant sur les moyens de moderniser la technos qui sous-tendent le SI, on en a oublié l'objectif final: efficacité et productivité, ce pour quoi se destine l'outil informatique en général.

    Ma conclusion à moi, mais qui ne veut pas définitive, c'est qu'entre les nouvelles technos (pas si neuves que ça d'ailleurs), les envies de se faire plaisir/mousser, les incompétences et les coûts faramineux engendrés, tout ça ressemble à un air de pipot.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 5.

      Quand je vois le nombre de personnes qu'il est nécessaire de mettre sur un projet Java comparé à des environnements plus traditionnels (souvent un rapport 2 à 3)

      D'où nous sors tu ces chiffres ????? troll d'entré de jeu :o)

      je m'interroge sur les gains in fine, en terme de gestion de projet, de conception, de développement et de maintenance

      Moi au contraire je trouve que ça fait parti des avantages de Java.
      Conception objet sympa, frameworks intéressants, développement agréable et plus carré qu'en cpp, javadoc ...
      Et puis je vois pas trop le rapport entre la conception / gestion de projet et le langage utilisé mais bon.

      nombre de "spécialistes" Java sont malheureusement infoutus d'appréhender la notion de système d'information dans son entièreté et donc incapable de concevoir un projet ou ses modules

      Tout ça c'est applicable a n'importe quel language je vois toujours pas le lien avec Java ...

      les incompétences et les coûts faramineux engendrés, tout ça ressemble à un air de pipot

      C'est toi qui pipote.
      Un projet peut coûter cher quelque soit le language utilisé à partir du moment où les gens sont incompétents :-)

      Apparemment tu n'as du avoir que de mauvaises expériences ... c'est bien dommage, mais c'est pas pour autant qu'il faut reporter les fautes de personnes sur le langage de programmation ....

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  . Évalué à 3.

        D'où nous sors tu ces chiffres ????? troll d'entré de jeu :o)

        Non, ce n'est pas un troll, je ne pratique jamais la trollerie ;-). Sérieusement, les chiffres je les observe sur le terrain dans les PME et les grands comptes. Ca fait 10 ans que je bosse en SSII et je me suis donc coltiné pas mal de projets assez conséquents, tous aussi différents les uns que les autres fonctionnellement et techniquement. Enfin, j'ai aussi pas mal "d'antennes" sur ce qui se fait ailleurs et je n'ai pas de sons de cloches très différents de ce que je sais par ma propre expérience. Il est entendu que je ne dis pas que cet état de fait est vérifiable partout. Ce qui est vécu sur le terrain, c'est qu'il te faut une ressource pour JSP, une autre pour les Beans, une autre pour l'archi, un admin, un CP Java... Bref une quantité de spécialistes différents qui travaillent chacun dans son petit monde et qui ne savent pas ce qui se passe à côté.

        Tout ça c'est applicable a n'importe quel language je vois toujours pas le lien avec Java ...

        Peut-être me suis-je mal exprimé sur un point: je ne critique nullement Java. Je critique surtout le bordel mercantile et d'effet mode organisé autour de lui et qui a pour conséquence d'aveugler pas mal de monde. Du reste, et nous sommes d'accord, que ce soit Java ou Cafetiere++, le résultat est le même car la mode (limite frénésie) veut que la nouvelle donne soit Java sinon rien. Et en cela je critique les choix qui ne sont pas toujours adaptés au contexte si l'on ne garde que ses critères idéologiques.

        Apparemment tu n'as du avoir que de mauvaises expériences

        C'est bien ça. Et comme je l'ai dit auparavant: ma conclusion ne se veut pas définitive. Mais là encore, pour le moment, je suis nullement convaincu, mais je suis prêt à réviser ma position.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

      L'idée de pouvoir développer des applications indépendantes de la plateforme est séduisante. Mais à quel prix ? Quand je vois le nombre de personnes qu'il est nécessaire de mettre sur un projet Java comparé à des environnements plus traditionnels (souvent un rapport 2 à 3), je m'interroge sur les gains in fine, en terme de gestion de projet, de conception, de développement et de maintenance.
      J'aime bien ce genre de chiffres. Il faut mettre plus de personnes, mais tu ne nous dit pas que le projet est développé plus rapidement, ou que tes développeurs Java sont des mecs sous-payés.

      Je trouve que l'on est arrivé à de sacrées usines à gaz - proprio ou pas.
      Si tu me donnes l'exemple des serveurs d'application, je serais d'accord avec toi. C'est la plus mauvaise raison pour laquelle Java a perçé, alors qu'il est très fort dans bien d'autres domaines. Les EJB, c'est une espèce de merde noire où il faut, pour s'en sortir, faire appel à des vraies usines à gaz que sont les serveurs d'application. Mais sorti de là, Java marche très bien, se développe au moins aussi vite qu'un autre langage, et donne en plus un code largement plus clair que son équivalent C(++).

      En outre, je constate (mais des exceptions peuvent exister, il faut l'espérer) que nombre de "spécialistes" Java sont malheureusement infoutus d'appréhender la notion de système d'information dans son entièreté et donc incapable de concevoir un projet ou ses modules.
      Tu me parles du monde des SSII, et je te comprends. Les SSII sont la faillite de l'informatique moderne. On pense trop au salaire et pas assez à la technique. Si les gens se concentraient sur leur métier de technicien plutôt que sur celui de vendeur de patates chaudes, tu n'aurais sûrement pas ce discours.
      J'ai pour ma part toujours travaillé chez des éditeurs de logiciel, et avec des gens compétents. A ceux-là, on ne demande pas de rendre le client heureux, mais d'implémenter telle fonctionnalité. Et dans ce cas, l'exigence technique rend le travail meilleur et personne n'est déçu.

      Et une conception râtée, c'est un développement râté et donc un projet qui dérape et qui coûte la peau des fesses avant même la fin de la phase de recette.
      Typique de la SSII.

      Ma conclusion à moi, mais qui ne veut pas définitive, c'est qu'entre les nouvelles technos (pas si neuves que ça d'ailleurs), les envies de se faire plaisir/mousser, les incompétences et les coûts faramineux engendrés, tout ça ressemble à un air de pipot.
      Les coûts faramineux ? En développement Java, qu'est-ce qui coûte de l'argent, hormis le salaire du développeur ? Rien.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  . Évalué à 3.

        Typique de la SSII

        ????


        Les coûts faramineux ? En développement Java, qu'est-ce qui coûte de l'argent, hormis le salaire du développeur ? Rien.

        Si la définition du coût d'un développement Java (ou autre) se résume au seul salaire des développeurs, tu te trompes lourdement. Et je n'en suis pas étonné car apparemment tu sembles concentré sur la seule vision technique d'un projet alors qu'il implique d'autres aspects (gestion de projet, analyse et modélisation, tests en environnement de recette + prod, formation des utilisateurs....) qui ont des coûts. Et je ne parle pas du temps perdu (et donc coûteux) lorsque les projets n'avancent pas convenablement ou dérapent complètement. Et celà n'a strictement rien à voir avec les SSII. Et les SSII ne vendent que de la bidoche, les éditeurs vendent leur came et enfin les deux protagonistes se lient d'intérêts commerciaux. Ce n'est pas Java qui est en cause, encore une fois, mais ce que l'on en fait. Et c'est pareil avec les autres outils de dev. Cependant, aujourd'hui en-dehors de Java et des ERP, point de salut pour faire tourner sa boîte. Ce n'est pas moi qui le dit, il suffit d'ouvrir ses yeux et d'être curieux pour s'en rendre compte. Et c'est cet automatisme que je remets en cause, ce même automatisme qui génère ce que je critique dans mon premier message.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

          Cependant, aujourd'hui en-dehors de Java et des ERP

          Et les gros et moyens systèmes qui font encore beaucoup de boulot...

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

            Posté par  . Évalué à 1.

            Tout à fait. Pour ma part et pour info, j'adore et connais très bien l'AS/400 :-) Dommage que beaucoup dénigrent ce système et l'imaginent hors jeu. M'enfin...

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

              Raah ! chut faut dire iSeries maintenant, AS/400 c'est un gros mot ! Il n'empêche que c'est une machine étonnante et bien pensée mais, des jours, la TMA sur une appli en RPG3 pensée pour le S/38 pfff... GOTO power

              PA : Ch job AS400 "moderne" IdF ou Rh-Al ;-)

              • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

                Posté par  . Évalué à 1.

                Ben oui iSeries, je sais bien! Sans déconner, t'as une TMA sur RPGIII développé pour S/38 ? Ca me rappelle (il y a longtemps, dans une galaxie très lointaine...) une appli complète en COBOL36 avec les OCL qui vont bien qui avait été migrée par une moulinette magique pour OS/400 à l'époque de la V3. Ah les beaux CL qui commençaient tous par MONMSG CPF000... Une vraie douceur. Sans compter les vielles FD internes qui s'appuyaient faussement sur les DDS. 'Gnifiiique!

                Il n'empêche que c'est une machine étonnante et bien pensée

                Entièrement d'accord. Il y a des tas de choses qui me manquent lorsque je suis sous Linux par rapport à l'AS/400. Mais bon, comme je ne suis pas aussi bon sous nunux que sous AS400, je me dis que ça vient de moi. Question subsidiaire si tu veux/peux: il y a moyen d'avoir le principe des JOBQ ?

                Pour ta PA, tu connais quoi sur le 400 ? Il y en a des projets AS400 mordernent qui trainent, malhereusement de trop nombreux clients ont du mal à comprendre qu'on sait faire autre chose que natif 5250. C'est ben triste.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

        . Les EJB, c'est une espèce de merde noire où il faut, pour s'en sortir, faire appel à des vraies usines à gaz que sont les serveurs d'application.

        Mon pauvre ami. Et comment fais tu pour développer une application transactionnelle basée sur un système à échange de messages sans te faire chier comme un rat mort ? Parce qu'à part les J2EE et .Net, franchement, je ne vois pas.

        C'est bien de défendre Java. C'est mieux de le faire bien.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 1.

          Et comment fais tu pour développer une application transactionnelle basée sur un système à échange de messages sans te faire chier comme un rat mort ?

          MQ Series ? J'en garde d'assez bons souvenir... Enfin, sauf la première release ;-)

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

            Posté par  . Évalué à 2.

            "MQ Series"

            Ahahahaha...

            Je relis ton premier poste ("L'idée de pouvoir développer des applications") je fais un quasi collé ici:

            "usine à gaze" (20000 applications cobol), "Quand je vois le nombre de personnes" (2000 personnes pour le SI), "je m'interroge sur les gains in fine"

            tout ce beau monde "infoutus d'appréhender [le] système d'information dans son entièreté" Tu m'etonnes, il faudrait être multi centenaire et insomniaque.

            "on en a oublié l'objectif final: efficacité et productivité". j'en parlerai à tout ceux qu'on a du rappeler 20 ans après qu'ils aient ecrit leur code pour le bug de l'an 2000, ou qui doivent interopperer avec ce genre de techno. Enfin bon IBM est le roi du libre, de l'interoperabilité, notre sauveur à tous :o)

            Avec ce type de projet, ca "coute la peau des fesses avant même" d'avoir commencé.

            J'aime bien les gens qui font (ou on fait) du gros système. Vraiment :).

            Dedicace à un pote qui ne lira jamais ces lignes.

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

              Posté par  . Évalué à 1.

              Non, je ne fais pas de gros système et je n'en ai fait que sur les bancs de l'école. Je ne vois pas pourquoi tu viens me raconter ça. Par ailleurs, MQ Series ne tourne pas QUE sur gros systèmes, mais aussi sur mini, unix, windows, OS/2...

              Tu m'etonnes, il faudrait être multi centenaire et insomniaque

              Tu connais la définition du mot Appréhender ?

              Enfin bon IBM est le roi du libre, de l'interoperabilité, notre sauveur à tous :o)

              Affirmation ex nihilo et je ne vois pas le rapport avec mon propos.

              2000 personnes pour le SI

              Pffff... Entre l'ignorance et la mauvaise foi, je prendrais bien les deux.

              C'est navrant.

              EOS

              PS: c'est vraiment un pote ton pote ?

              • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

                Posté par  . Évalué à 1.

                PS: c'est vraiment un pote ton pote ?

                oui. Et on rigole souvent tous les deux de nos boulots respectifs autours d'une mousse.

                Toutes les anecdotes, les technos, les chiffres, c'est ce qu'il se passe dans sa boite et c'est son boulot depuis plus de 20 ans. Alors bon, tu peux devenir aggressif, parler d'ignorance et de mauvaise foi si tu veux, ne pas comprendre que je fais reference à l'ensemble de tes posts, c'est toi que ca regarde.

                A la difference de toi, je ne dénigre aucune des 2 technos. De ces technos, j'en suis à la fois amusé et emerveillé: "et pourtant, elle(s) tourne(nt) !".

                • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

                  Posté par  . Évalué à 1.

                  A la difference de toi, je ne dénigre aucune des 2 technos

                  Je ne dénigre aucune techno, tu ne m'as pas compris. Je ne cherche pas être agressif non plus, je n'en vois pas l'intérêt. Simplement quand tu parles de 2000 Cobolistes pour une application, ça n'a aucune signification puisque sans contexte énoncé. Le COBOL, c'est bon, je connais pas coeur et pas sur gros système, mais sur mini. A l'époque où j'en faisais, c'était sur une application de logisitique multipays et utilisée par 9 filialles en Europe. Nous étions 5 pour tout faire (analyse, modelisation, dev, migration, recettes, maintenance fonctionnelle etc...). Et ça marchait fort bien. Sur notre plateau il y avait d'autres équipes projets, chacune avait une taille variable en fonction de l'importance du projet. Mis bout à bout, ça faisait pas mal de monde mais certainement pas 2000, même pas 50.

                  Bien sûr on trouvera toujours des cas où des quantités hallucinantes de ressources sont affectées sur un même projet et que l'on a du mal à justifier. Ce n'est pas la techno qui est en cause. Par contre, et c'était l'objet de mon premier post, il existe des technos qui semblent impliquer un nombre de ressources bien supérieures à d'autres techno ; ce qui ne signifie pas que je tape ou ensence l'une ou l'autre. Les rivalités entre vieux routiers de l'informatique et les petits jeunes qui en veulent, ça fait belle lurette que ça me passe au-dessus de la tête.

                  De ces technos, j'en suis à la fois amusé et emerveillé: "et pourtant, elle(s) tourne(nt) !"

                  Presque pareil...

                  Cordialement

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

          WebObjects d'Apple (ex-NeXT), même si ces idiots sont passés d'Objective-C à Java depuis la version 5.

          Version libre : http://www.gnustepweb.org(...) -- ça marche mais ça manque de doc et d'exemples !

          Perso pour faire un site web complexe, je trouve ça vraiment super, tout est proprement encapsulé dans des composants, tout utilise le modèle vue composant, etc.

          Pour ce qui est du stockage en base de données, on prends au choix EOF (Enterprise Object Foundation si je ne me trompe pas) côté Apple et GDL2 (GNUstep Database Layer) pour GNUstep. Le principe : un mapping de ta base de données vers des objets. Du coup côté programme, tu ne fait plus de SQL, la cohérence entre les objets et les tables est automatique, les relations de dépendance également. Tu peux même décider de mapper un objet non pas vers une table mais sur une série de tables voir une requête SQL. Bref, très intéressant...

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

            un mapping de ta base de données vers des objets. Super ultra puissant. Et les Entity Bean CMP, c'est quoi, à ton avis ? Et JDO ? Si tu veux parler des EJB, je te suggère de lire d'abord un livre dessus.

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

              Je sais bien que c'est possible avec les EJB, je ne dis pas que WebObjects est dix fois mieux, mais simplement que c'est possible AUSSI avec WebObjects/GNUstepWeb ! C'est pas parce que personne connaît WebObjects que pour autant c'est un truc merdique hein :-)

              Si tu veux, struts+EJB c'est vaguement équivalent à WebObjects, la différence c'est que WO est LARGEMENT moins usine à gaz. Et perso, je préfère quand je n'ai pas trois milliards de fichiers de confs xml à remplir ou générer. Je préfère quand le fonctionnement reste simple, mais puissant.
              En tout cas moi je connais les deux, merci.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

          Mon pauvre ami. Et comment fais tu pour développer une application transactionnelle basée sur un système à échange de messages sans te faire chier comme un rat mort ? Parce qu'à part les J2EE et .Net, franchement, je ne vois pas.
          Est-ce que j'ai dit que J2EE était merdique ? Non, je dis juste que les EJB, comme toute couche d'interface entre deux systèmes complètement différents, sont obligés d'utiliser le pire des deux systèmes.
          Et puis, pour reprendre un argument d'un autre intervenant, tu connais beaucoup d'autres systèmes, à part effectivement les mainframes où l'usine à gaz est la règle, où ce soit le cas ?

          C'est bien de défendre Java. C'est mieux de le faire bien.
          Je défends Java comme j'aimerais le voir utilisé, c'est-à-dire en tant que vraie plateforme portable et transportable. Malheureusement, ce n'est pas encore assez le cas selon moi. Et J2EE ne fait rien pour ça.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 1.

          WebObjects

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

    Sans vouloir rentrer dans un méchant troll, il faut tout de même rappeler que y'a pas que le Java et la JVM... et sans vouloir polémiquer, il me semble qu'il y a des (au moins une) alternnatives qui propose les même avantages, sans les inconvénients et avec d'autres avantages... (ca y est je vais me faire taper dessus) .NET pour ne pas citer d'exemple
    Tant qu'à avoir une indépendance vis-à-vis de la plateforme, autant l'avoir aussi vis-à-vis du langage... les coûts de conversion ou de formation s'en trouve diminuer, et on n'est plus limité par une grammaire... chacun choisi... (Csharp, C++, VB même sous nux, Python, Perl, Eiffel, CAML, j'en passe, et des meilleurs que Java sur bien des points).
    Sans parler de l'interopérabilité avec l'existant (COM, etc.)... encore du gain d'argent au développement pour un passage progressif...
    et puis je veux pas dire, mais les spécifications de la machine virtuelle CLR sont normalisées et ouvertes à un consortium (dont Microsoft n'est qu'un des membres). Bref, même si c'est Microsoft qui a mis au point le premier environnement .NET digne de ce nom, je vois toujours pas pourquoi il n'est jamais mis en évidence face à Java... ou tout du moins face à la JVM (puisque on peut faire du Java sur une machine .NET, mais autant faire du Csharp :-p, clone plus évolué et moins limité )
    Pour ce qui est des performances, il me semble qu'elle ne sont pas pire, tout du moins du même niveau.
    Enfin bref, y'a des implentation libres de spécifications ouvertes qui existent, je vois toujours pas l'intérêt du Java face à ça...
    Merci de ne pas me taper dessus :-)

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  (site web personnel) . Évalué à 4.

      Sans vouloir rentrer dans un méchant troll, il faut tout de même rappeler que y'a pas que le Java et la JVM... et sans vouloir polémiquer, il me semble qu'il y a des (au moins une) alternnatives qui propose les même avantages, sans les inconvénients et avec d'autres avantages... .NET pour ne pas citer d'exemple
      C'est vrai que .NET est totallement portable sous Windows ;-)
      La vraie portabilité de ce point de vue, c'est le C ANSI.

      Tant qu'à avoir une indépendance vis-à-vis de la plateforme, autant l'avoir aussi vis-à-vis du langage... les coûts de conversion ou de formation s'en trouve diminuer, et on n'est plus limité par une grammaire... chacun choisi... (Csharp, C++, VB même sous nux, Python, Perl, Eiffel, CAML, j'en passe, et des meilleurs que Java sur bien des points).
      Ce que tu oublies, c'est que Java est une machine virtuelle, il est donc possible d'utiliser d'autres langages que le Java sur une plateforme Java. La page http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html(...) liste les langages disponibles sous VM Java. on y trouve ainsi TCL, Lisp, BASIC, Logo, Prolog, Eiffel, Smalltalk, COBOL, ADA, Forth, Fortran, C (avec C2J), ...
      L'argument me semble donc difficilement recevable ;-)


      Sans parler de l'interopérabilité avec l'existant (COM, etc.)... encore du gain d'argent au développement pour un passage progressif...
      Il existe également de nombreuses API d'interopérabilité COM/DCOM, dont notamment l'utilisation des EJB et de CORBA qui eprmet de dialogue r de manoière transparente avec DCOM.

      Bref, même si c'est Microsoft qui a mis au point le premier environnement .NET digne de ce nom, je vois toujours pas pourquoi il n'est jamais mis en évidence face à Java... ou tout du moins face à la JVM (puisque on peut faire du Java sur une machine .NET, mais autant faire du Csharp :-p, clone plus évolué et moins limité )
      Ah, j'avais pas vu que c'était un glorieux troll C#/Java, désolé.

      Pour ce qui est des performances, il me semble qu'elle ne sont pas pire, tout du moins du même niveau.
      Enfin bref, y'a des implentation libres de spécifications ouvertes qui existent, je vois toujours pas l'intérêt du Java face à ça...
      Merci de ne pas me taper dessus :-)
      Parce que java est lui aussi libre et ouvert, grâce aux langages déja cités, mais également grâce au JCP auqel tu peux participer pour faire évoluer Java.

      • [^] #

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


        C'est vrai que .NET est totallement portable sous Windows ;-)
        La vraie portabilité de ce point de vue, c'est le C ANSI.

        les projets dotGNU et Mono prouve que c un environnement portable. Les implentation dans les pda et les téléphone aussi.

        Ce que tu oublies, c'est que Java est une machine virtuelle, il est donc possible d'utiliser d'autres langages que le Java sur une plateforme Java. La page http://grunge.cs.tu-berlin.de/~tolk/vmlanguages(...) liste les langages disponibles sous VM Java. on y trouve ainsi TCL, Lisp, BASIC, Logo, Prolog, Eiffel, Smalltalk, COBOL, ADA, Forth, Fortran, C (avec C2J), ...
        L'argument me semble donc difficilement recevable ;-)

        Ce que tu oublies c que la JVM n'a pas été conçu pour... la machine virtuelle CLR a été faite pour.(Commmon Langage Runtime) là preuve, la plupart des langages "compatibles" restent des lanages de très haut niveau... c pas demain la veille qu'on fera tourner du C++ sur une JVM (je parle pas de conversion de code)
        Merci pour les infos sur l'interopérabilité DOMCOM :)
        Et désolé pour le troll :)

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 1.

      Nan, je vais pas te taper t'inquiétes...
      Bien, .NET paraît séduisant sur le papier et malgré qques qualités indéniables, je reproche :
      - J'aime pas qu'on m'oblige à développer que sur Windows, non pas parceque j'aime pas mais j'aime bien choisir en fonction des projets (et ne me parlez pas de mono svp...).
      - La trop grande jeunesse de l'ensemble (vaut mieux attendre qques années je pense avant de pouvoir juger de la qualité...)
      Voili-voilà.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

      Tu sais que l'API de .NET est protégée par Microsoft par des brevets. Tu le sais, n'est-ce pas ? Donc tu sais que l'idée même d'avoir autre chose qu'une machine virtuelle interopérable est une vaste blague. Et que si on se limite justement à une machine virtuelle, ça fait des années que des versions open source de la JVM existent et tournent très bien.

      Tu sais aussi sûrement que ce qui compte dans une plate-forme de développement, ce n'est finalement pas la machine virtuelle, ni même le langage (oui, C# c'est pas mal, tout à fait du même niveau que Java, avec des + et des -), mais surtout les API. Alors le projet Mono me fait bien rire. Ca fait des années que classpath tente d'atteindre java 1.2 et ils n'y sont pas encore (même si eclipse peut tourner en 100% open source), alors que les api Java ne sont même pas protégées par Sun.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 2.

      Bon on parle d eplus en plus de .Net qui est il faut l'admettre une presque belle realisation. Seulle truc qui me choque un peu c'est que de ce que j'en ait vu c'est plus une couche OS + VM qu'une VM pure. Et moi ca me casse les pieds.

      Ensuite loin de moi l'idee de taper sur le design MS mais j'en ai ras le bol de devoir appeler des fonctions pour modifier des variables (genre setThisVariableToZero(mon_handle, mon_scope, mon_objet, mon_instance, mes_permissions, mon_jesaispastropquoi_cesttoujoursaNULL)). Et je deteste changer des variables pour generer des actions (MonHandle.makethiswork=1).
      Je suis peut etre vieux jeu, mais je doit reconnaitre que j'aime bien l'idee d'utiliser des variables pour stocker des informations et d'appeler des des fonctions (ou methodes hein c'est encore mieux) pour generer des changements d'etats.

      Autre gros reproche que je fais a la techno .Net et qui a mon sens est lie au cote "VM+un vague bout d'OS quand meme" c'est les #@!!$#@ de pointeurs vers des fonctions qui DOIVENT etre stockees dans des variables globales. Dans tous les livres que j'ai pu lire, ils mettent ce genre de methode dans la section "a eviter a tout prix". Et moi perso a chaque fois que j'utilise le systeme des messages de C# je grince des dents.

      Voila, voila

      Kha

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  . Évalué à 1.

        Pour en avoir beaucoup fait ces derniers mois... je suis d'accord avec toi. J'aimerais également dénoncer la piètre qualité de la traduction française du manuel de l'API.

      • [^] #

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

        Pour le système des messages, ce n'est pas celui du C#, mais celui de Windows. Compatibilité avec l'existant oblige.
        Mais si tu développes une application entièrement orientée .NET (c'est le but), je vois pas trop l'intérêt d'utiliser les messages... le C# a introduit les événements beaucoup plus facile à utiliser qu'en Java par exemple...
        Par contre je vois pas ce que tu entends par " c'est les #@!!$#@ de pointeurs vers des fonctions qui DOIVENT etre stockees dans des variables globales"... tu utilises ca quand ? comment ? pour faire quoi ?
        Ma petite expérience de l'API .NET ne m'a pas fait rencontrer tes problèmes de "setthisvariabletozero", c toujours une structure de la forme "variable = 0;" (c'est pas pour rien que le C# a introduit les get() et set(), y'a pas besoin de chercher le nom de la fonction pour modifier une variable...). Ensuite me semble pas avoir utilisé une seule fois un changement de variable pour exécuter une action "(MonHandle.makethiswork=1)"

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

          le C# a introduit les événements beaucoup plus facile à utiliser qu'en Java par exemple...

          Tout le monde n'est pas d'accord. Perso, je préfère les classes anonymes aux delegates. Dans les cas simples (une seule méthode), les delegates sont moinx verbeux, mais ils ne peuvent pas s'adapter aux cas évolués...

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  . Évalué à 2.

    Je veux bien que java soit bien adapté pour les applications tels que les gros sites web avec J2EE ...

    Mais franchement niveau GUI ou appli grand public, Java est un vrai flop ! Est ce que klk peut me citer une seule appli grand public sous Java qui vaille le coup ?

    Ca fait quelque années que Sun promet une machine virtuelle plus rapide mais meme avec quelque améliorations tels que le JIT, on a rien vu ...et on verra surement jamais rien.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 1.

      lol,

      une application GUI évoluée que j'utilise régulierement, netbeans [ screenshot http://antonin.tuxfamily.org/capture4.png(...) ]

      sinon tu trouveras une liste de projets aboutis ici :
      http://solutions.sun.com/NASApp/catalogs/en/US/adirect/sun?cmd=advi(...)

      fais attention la liste est tres longue .....

      pour les projets en emergence/en cours/aboutis , tu peux regarder la aussi :

      http://sourceforge.net/softwaremap/trove_list.php?form_cat=198(...)

      [8914 projects in result set]

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

        Posté par  . Évalué à 1.

        salut,

        Euh un IDE t'appeles ca une appli grand public toi ?

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 1.

          tu peux me définir ce que tu entends par grand public ?

          Une grande [ majeure ] partie des softs que j'utilise ne sont pas "grand-public" ... fais le compte des appz que tu utilises régulierement,
          et détermine raisonnablement si elles sont grand-public. [ je connais
          un soft bogué "grand-public" ;) ]

          Je répondais à ton observation "les GUI java sont un grand flop", en
          mentionnant des liens mettant en valeur des applications java
          fonctionnelle et utilisées IRL.

          Si tu veux continuer le débat du "grand-public", je te répondrais que le
          grand-public est encore majoritairement micromou ou macos ...

          Comme sur de nombreux points [ tv, politique, société ... etc ] le public
          doit etre informé et éduqué pour pouvoir percevoir autre chose que le
          grand public, ie la substance prémaché qu'on tente de lui imposer.

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

            Posté par  . Évalué à 0.

            Alors dans la liste des applications grand public je peux te citer des softs aussi bien sous linux que windows que macos :

            - Un navigateur Web qui vaille la peine. Jamais entendu parler un browser valable en java, pkoi ?
            - Une suite bureautique
            - Un client mail
            ...

            Aucune appli JAVA de ce genre n'as jamais percé ou ne s'est fait connaitre. Pourtant le java maintenant ca commence à dater et on ne peut pas dire que c'est le temps qu'ils leur a manqué ...!!!

            Alors j'aimerais bien savoir pkoi Java n'a jamais reussi à percer dans ces domaines sinon parce k'il est [top] lent et mal foutu ...

            D'ailleurs on peut se se demander pkoi SUN n'as pas developpé StarOffice en JAVA ???

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

              Posté par  . Évalué à 1.

              Je crois me souvenir (quelqu'un pour me corriger si je dis une énormité) que Corel avait porté une suite bureautique en Java (sans doute époque de l'AWT). En tous cas, ça a fait choux blancs. M'enfin AWT, évidemment...

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

              Posté par  . Évalué à 2.

              ok,

              maintenant tu me cites pour les langages suivants :

              perl, python, php, ruby, ocaml, C# .... etc

              - Un navigateur Web qui vaille la peine. Jamais entendu parler un browser valable en * pkoi ?
              - Une suite bureautique
              - Un client mail

              Aucune appli * de ce genre n'as jamais percé ou ne s'est fait connaitre. Pourtant le * maintenant ca commence à dater et on ne peut pas dire que c'est le temps qu'ils leur a manqué ...!!!

              lol, allez .....

              Alors j'aimerais bien savoir pkoi * n'a jamais reussi à percer dans ces domaines sinon parce k'il est [top] lent et mal foutu ...

              D'ailleurs on peut se se demander pkoi * n'as pas developpé * en * ???

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

              Posté par  . Évalué à 3.

              StarOffice a été racheté. Sun ne l'a pas écrit en partant de rien.

              Tu pourras jeter un oeil sur la dernière version électronique de l'encyclopédie Britannica... c'est une interface Swing :) C'est assez grand public ?

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

              Aucune appli JAVA de ce genre n'as jamais percé ou ne s'est fait connaitre.

              Dans ta petite bulle rose, peut-être pas, mais dans le monde réel oui. Une appli qui monte : Quickrules, fait par YASU.

              D'ailleurs on peut se se demander pkoi SUN n'as pas developpé StarOffice en JAVA ???

              Tu sais de quoi tu parles toi, c'est un bonheur. :-)

              • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

                Posté par  . Évalué à 0.

                oui bon je savais pas que staroffice avait été acheté par Sun.

                N'empeche que les personnes qui m'ont repondu sont capables de donner un voir 2 softs mais pas plus. Ca reflete bien la faible (mais pas inexistante) percée de Java dans le domaine des applis bureautiques.

      • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

        une application GUI évoluée que j'utilise régulierement, netbeans

        C'est imbitable comme truc, c'est mal pensé par rapport à l'utilisateur, tu mets plein de temps avant de commencer à comprendre ou tu pourrais trouver la fonction qui t'interesse, c'est contre-intuitif. Alors oui je sais, mais un outils de développement, il faut le maitriser, ça demande du temps, bla, bla, bla.

        Seulement voilà, il y a des options que tu utilises une fois quand il te tombe un oeil et entre 2 utilisations tu dois te retaper la doc pour la retrouver. Quand je parle de contre intuitif, c'est que tu ne peux même pas retrouver cette option par rapport à une logique de l'application, "j'ai besoin de ça, à priori, ça devrait être dans tel menu parce que je sais que l'application regroupe ce genre/catégories d'options dans ce menu".

        Je sais bien que c'est l'IDE officielle de développement Java, mais franchement entre NetBean et Eclipse, on hésite pas longtemps.

        J'ai pas aimé FORTE pour java, j'ai pas aimé NETBEAN, (j'ai travaillé sur des projets avec) je les ai toujours trouvés lourds, pas réactifs, genre tu TRAINE UN BOULET D'UNE TONNE à chaque action (et en plus fortement bugges dans le cas de forte).

        Et puis on m'a montré ECLIPSE et quelques fonctionalités pratique, et paf en 10min j'étais tombé amoureux, un outils de dévéloppeurs fait par des développeurs avec pleins d'astuces pour programmer plus vite et qui EST REACTIF.

        Alors NETBEAN, c'est peut être trés beau comme concept et trés dans la philosphie Java, mais ECLIPSE est carrèment plus productif.

        Et attention, je ne connaissais pas ECLIPSE pendant que je travaillais avec FORTE et NETBEAN (mais c'est vrai qu'à l'époque, je preferais déjà Jbuilder5 ou "editeur de texte basique").

        Et je dis ça d'autant plus ouvertement que je trouves que VISUAL AGE (la génération précedente d'IDE d'IBM) est aussi trés mal foutus, bordélique et contre intuitif.

        C'est une affaire de gout et de couleurs, mais je partage mon opinion :-)

        Mais je constate que IBM est reparti de zéro en prenant compte des envies et des besoins des développeur.

        Alors que NetBean est un demonstrateur technologie du concept d'une application java pure et idéale.

        Malheureusement, le mieux n'est pas forcément l'ami du bien.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

          Posté par  . Évalué à 1.

          Et puis on m'a montré ECLIPSE et quelques fonctionalités pratique, et paf en 10min j'étais tombé amoureux, un outils de dévéloppeurs fait par des développeurs avec pleins d'astuces pour programmer plus vite et qui EST REACTIF. Réactif oui mais après 10 min pour démarrer ... Eclipse est un bon IDE c'est clair mais y'a plein de choses qui sont très exaspérantes à l'utilisation : - Dans la vue package, un auto-collapse serait vraiment pas de trop parce que lorsque beaucoup de projets sont ouverts, les fermer un à un c'est assez ennuyeux et ça peut en plus provoquer des "freezes" - La recompilation automatique dans le cas de la mise à jours d'une vue (avec clearcase par exemple) provoque souvent un gel de l'appli. On peut le désactiver mais par défaut cette option est présente. - La vue "debug" est très lourde et question réactivité c'est une catastrophe Sans compter des bugs dans les vues ... bref Eclipse est bien et certainement mieux que Netbeans mais on est encore loin de la perfection. Et je dis ça d'autant plus ouvertement que je trouves que VISUAL AGE (la génération précedente d'IDE d'IBM) est aussi trés mal foutus, bordélique et contre intuitif. C'est drôle, j'aime bien la vue "Browser" dans WSAD qui justement ressemble à Visual Age ... comme quoi les gouts et les couleurs ;-)

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

            Tes remarques m'inquiètes un peu.

            Actuellement on travaille sur Visual Age, on va passer progressivement sous WSAD.
            Pour l'instant on utilise VA pour l'appli et eclipse pour les JSP (ce qui permet d'avoir un versionning avec CVS que ne peut pas faire VA, bien sur, on peut passer par le studio je sais plus quoi jsp qui est livré avec VA, mais c'est encore plus super bordélique.

            Réactif oui mais après 10 min pour démarrer ...

            Ah ouais, là je dois avouer que j'ai une vue biaisé.
            A la maison j'ai un athlon XP1900+ avec 512mo.
            Au boulot on a des machines assez costaud de 1ghz à 2,4ghz toutes avec 512mo.
            Sur les autres postes (~1ghz), quand je vois eclipse il est déjà ouvert, et j'ai eu la "chance" d'avoir un nouveau poste à 2,4ghz, donc je n'ai pas été sensibilisé sur ce point.
            Et dans tous les cas on est sous win qui apparement est la configuration la plus rapide pour faire tourner Eclipse.

            On prend vite le gout du luxe :-)

            Dans la vue package, un auto-collapse

            Tout à fait d'accord, c'est le même problème avec la plupart des gestionnaires de fichiers ou toutes les applications qui utilisent des vues en arbres (comme un éditeur XML/HTML avec les balises par exemple).

            La recompilation automatique ... La vue "debug"

            C'est là que je commence à m'inquiéter, comme je le dis plus haut à part faire 2 ou 3 programmes de test et la gestion des JSP, on a pas encore utilisé Eclipse de fond en comble.


            C'est drôle, j'aime bien la vue "Browser" dans WSAD qui justement ressemble à Visual Age ... comme quoi les gouts et les couleurs ;-)

            Tout n'est pas mauvais dans VA, mais ça été pensé pour faire des applications uniques et séparées.
            Ce n'était pas vraiment adapté aux développement d'application sur serveur. Toutes les fonctions s'y rapportant ressemblent à des gros patch pour adapter l'outils.
            A priori faire une application sur VA indépendante, VA peut être un bon outils.

            Ce que j'ai bien aimé sur Eclipse pour l'instant, c'est la gestion automatique des imports ce qui permet de nettoyer les fichiers au fur et à mesure de son évolution et d'éviter de se retrouver avec une vingtaine d'import et ne pas savoir quels sont ceux qu'il faut garder ou pas.

            Oui il faut être rigoureux et le faie systématiquement, mais quand on reprend une application existante, on a pas toujours le temps ni la visibilité pour savoir qu'est ce qui est nécessaire ou pas (je parle des imports par rapports aux autres packages développés en interne).

            J'ai trouvé le systéme d'auto-complétion avec l'apparition de la javadoc particuliérement utile pour repérer rapidement la bonne fonction.

            C'est vrai que j'ai tendance maintenant à écrire le début du nom de la fonction et "ctrl+espace".
            ça devient de plus en plus du légo. d'un autre côté ça évite d'aller ouvrir le fichier de la classe correspondante et de rechercher le nom de la méthode. Le gain de temps est indéniable, VA faisait déjà l'auto complétion mais sans la Javadoc.

            Rien n'est parfait dans ce bas monde, mais Eclipse est une IDE qui te permet d'être à jour sans dépenser pleins de sous tous les 6 mois pour les mises à jour.
            Et dans un milieu professionnel, ça te permet d'être à jour, car avant d'obtenir l'autorisation de la comptabilité pour l'achat d'une version, tu as déjà 2 versions de retard.
            Ce n'est pas vraiment un problème financier, car ça rentre dans les dépenses du projet, mais de réactivité du service financier.

            • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

              Posté par  . Évalué à 1.

              [ ... ] Et dans tous les cas on est sous win qui apparement est la configuration la plus rapide pour faire tourner Eclipse.

              Disons que j'ai exagéré les 10 minutes mais WSAD met bien 5 minutes montre en main à démarrer sur des P4 à 2GHz avec 1Go de mémoire (au boulot hein ! chez moi je n'ai pas cette config ;-). Cependant, à l'utilisation il est bien plus rapide que NetBeans qui utilise Swing.

              C'est là que je commence à m'inquiéter, comme je le dis plus haut à part faire 2 ou 3 programmes de test et la gestion des JSP, on a pas encore utilisé Eclipse de fond en comble.

              Si le projet sur lequel tu bosses n'utilise pas d'EJB (ou que tu bosses sur la partie IHM), je te conseille de ne pas debugger avec Websphere mais plutot avec Tomcat qui est bien plus léger et qui surtout évite d'être obligé de prendre un café entre chaque point d'arrêt. Autant en production Websphere est rapide autant en debug c'est un cauchemard.
              Le système de recompilation quand il est activé est vraiment gonflant parce qu'une recompilation quand tu as 10 projets avec chacun près de 200 classes, ça peut prendre près de 10 minutes (vraiment) tout ça à cause d'un update de ta vue !!
              Maintenant, il faut quand même reconnaître que WSAD est nickel pour ce qui est de l'intégration de tests JUnit, la complétion est formidable, le système d'organisation automatique des imports est bien pensé, programmer avec est vraiment plaisant mais comme évidemment la perfection n'est pas de ce monde (comme tu le dis), on trouve toujours quelque chose à dire. Pour moi WSAD est ce qui se fait de mieux mais je n'ai pas testé Intellij Idea (dont parle guillaume plus bas) et c'est vrai que j'en ai eu de bons echos.

        • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

          Et puis on m'a montré ECLIPSE et quelques fonctionalités pratique, et paf en 10min j'étais tombé amoureux

          As-tu essayé Intellij Idea ?

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

            sapu c pa libre

          • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

            As-tu essayé Intellij Idea

            Non, car j'utilise les outils utilisés dans les projets ou que je peux utiliser sur ma machine perso sans être un "vilain pirate".

            Pour l'instant j'ai eu l'occasion d'utiliser :
            JBuilder 4 & 5
            Forte et NetBeans
            Visual Age 3.5 & Eclipse 2.1

            Je ne suis pas à la recherche d'une IDE "Absolue", mais qui soit suffisament efficace et accessible au niveau licence pour pouvoir la proposer sur un projet sans avoir à faire une demande de 6 mois.

            A une époque IBM a refourgué un paquet de VA3.5 avc Websphére, mais la tendance, c'est quand même d'utiliser des IDE libres sur des projets clients ce sont eux qui fournissent l'environement et le développement est ponctuel (mais ça peut prendre trés longtemps). Et oui je travailles en SSII vite fait mal fait.

            La problèmatique est différente chez un éditeur qui peut rentabiliser les licences sur plusieurs projets, mais je n'ai pas été de ce côté de la barrière.

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  (Mastodon) . Évalué à 1.

      Ouais, cgoban, le truc pour jouer au Go sur KGS... :-)

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

      Va voir sur Swing Sightings, tu y verras quelques applis assez grand public écrites en Swing.
      http://java.sun.com/products/jfc/tsc/sightings/(...)

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

      Est ce que klk peut me citer une seule appli grand public sous Java qui vaille le coup ?
      Beaucoup d'applications embarquées dans les téléphones portables, dans les télévisions et dans les décodeurs satellite de nouvelle génération sont écrites en Java.
      Ce ne sont pas vraiment des technos serveur, et on trouvera difficilement d'applications plus grand public. Et même si leurs utilisateurs ne les connaissent pas en tant qu'applications (mais uniquement comme faisant partie d'un tout, mélant électronique et informatique), elles sont _très_ répandues.

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  . Évalué à 1.

    personnellement, j'ai ete assez bluffe par le possibilite offerte par sun d'ajouter le support (c un draft pour l'instant, le jsr14, je crois) de la genericite dans son dernier compilo. J'espere que ca passera bientot dans les specs de java....

    un lien pour les curieux :
    http://developer.java.sun.com/developer/technicalArticles/releases/(...)

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

      Posté par  . Évalué à 3.

      C'est officiel pour le JDK 1.5. On peut déjà télécharger un compilateur pour le JDK 1.4 permettant de les essayer. Et malgré tout le mal que je pense de C++ et des templates, j'avoue que j'aime plutôt ce qu'ils ont fait. Notons aussi l'arrivée du "for/each", des listes indéfinies d'arguments et des énumérations.

      Voici donc un petit printf() pour la route :


      
    public static void printf(String fmt, Object[] args...) {
      
	int i = 0;
      
	// foreach on primitive array
      
	for (char c : fmt.toCharArray()) {
      
	    if (c == '%')
      
		System.out.print(args[i++]);
      
	    else
      
		System.out.print(c);
      
	}
      
    }


      Et l'utilisation des types génériques qui évitent les cast à outrance :


      
	LinkedList ys = new LinkedList();
      
	ys.add("zero"); ys.add("one");
      
	String y = ys.iterator().next();

  • # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  . Évalué à 1.

    Y'a aussi le problème des brevets et des copyrights détenus par Sun sur Java. MS et Jboss ont deja eu des problèmes avec Sun.

    C'est d'ailleurs la même chose pour MS avec Mono .NET ...

    • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

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

      Y'a aussi le problème des brevets et des copyrights détenus par Sun sur Java. MS et Jboss ont deja eu des problèmes avec Sun.

      Tiens, un troll poilu qui remonte ?
      Je te signale à tout hasard que le langage Java est libre, évolue suivant les désirs du JCP, une communauté ouverte, et qu'il existe aussi des JVM libres (certes un peu moins développées que les JVms commerciales).
      Quant à MS et Java, je te laisse regarder les archives de LinuxFr pour y constater que les problèmes sont essentiellement dûs à la stratégie embrace and extend de Microsoft.
      Enfin, pour JBoss et Java, la situation est beaucoup plus complexe. Il se trouve que la norme J2EE contient un certain nombre de limitations légales ou pseudo-légales qui restreignent les capacités de communication sur le code-source, et donc rend difficile la mise en place d'un serveur Open-Source J2EE. Ce qui n'a pas empêché JOnAS de passer avec succès cette certification. Le problème entre Sun et JBoss group est donc plus dû à des querelles politiques qu'à une réelle incompatibilité.

      C'est d'ailleurs la même chose pour MS avec Mono .NET ...
      Pas d'avis sur la question.

Suivre le flux des commentaires

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