Critique de C# par James Gosling l'inventeur de Java

Posté par . Modéré par oliv.
Tags :
0
5
fév.
2002
Java
Voici une interview du créateur de Java donnant son avis sur C# (en particularité de son modèle de sécurité).
En résumé, C# ayant dû faire des concessions à C++ ne protège pas correctement les accès mémoires.
On notera un petit dérapage sur Emacs avec mise au point de Richard Stallman égratignant au passage la prétendue moralité SUN lorsqu'ils se font les chantres de l'open source pour se ramasser de la main d'oeuvre venue du monde du libre.

Note du modérateur : Merci à G78 pour le lien sur la page personnelle de James Gosling

Aller plus loin

  • # Yep

    Posté par (page perso) . Évalué à 10.

    Le passage sur emacs m'avait étonné aussi :)
    La précision de RMS est la bienvenue ...
    Ceci dit, gosling défend son bébé et troll pas mal, mais je crois qu'il est grosso modo dans le vrai; je trouve Java plus "propre" que C# (et pourtant, j'aime pas java :-P )
    Le passage sur la coopération avec IBM est bizarre aussi, genre "nous on était pas au courant, on attendait qu'ils viennent nous demander" ... quelqu'un a suivit ça d'un peu plus près ?
    • [^] # kikiné le papa à Emacs ?

      Posté par (page perso) . Évalué à 10.

      A noter que la traduction française concernant le passage sur la paternité d'emacs est encore plus choquante que l'originale :

      «Or peu d'outils adaptés sont à leur disposition, hormis Emacs. J'ai conçu la première version d'Emacs il y a 23 ans et je constate avec effroi que cet outil est toujours utilisé aujourd'hui tel qu'il était à l'origine. Est-ce là tout ce que l'on peut offrir de mieux à ces développeurs? Je ne crois pas.»

      et l'originale :

      «And if you look for tools that are oriented toward (those) people, you basically find nothing. The No. 1 tool (in that area) is Emacs, and I was kind of the guy responsible for the original Emacs, 23 years ago. One of the things I find frightening is it's still around, and in many ways it hasn't really changed. Is that the best you can do for a (low-end) developer? I don't think so.»

      enfin, la réponse de RMS :

      «In your interview with James Gosling, he says that he was "responsible for the original Emacs, 23 years ago." Actually, I wrote the first Emacs editor, in 1975 at the MIT Artificial Intelligence Lab. (I received the ACM Grace Hopper Award in 1991 for this work.)»

      Gosling a bien écrit un Emacs pour Unix ceci dit, il n'a peut être pas tord quand à son rôle dans le succès d'Emacs (en partie); RMS ayant écrit GNU Emacs en 84.

      de toute façon, Vim rulez ;-)) (voir http://vim.sf.net(...))
  • # Bof, pas d'accord avec lui.

    Posté par . Évalué à 9.

    Il defend son bebe, mais d'apres ce que j'ai compris sur C# par defaut la gestion de la memoire est identique a celle de Java.

    C'est juste que C# t'offre en plus la possibilite de gerer toi-meme la memoire pour des raisons de performances ou quand tu as a faire des manipulations de bas niveau et a ce moment la le code est marque "unsafe".
    Donc je ne vois pas trop ce que l'on peut reprocher a C#.

    Mais bon, mon coup d'oeil a C# fut tres bref..
    • [^] # Re: Bof, pas d'accord avec lui.

      Posté par . Évalué à 7.

      et tu peux pas gérer la mémoire toi-même en java ???
      • [^] # Re: Bof, pas d'accord avec lui.

        Posté par (page perso) . Évalué à 10.

        Tu ne peux pas dire "Je voudrais un pointeur sur telle adresse mémoire" ou "Je prends l'adresse de cette objet, et je lui ajoute 5". Enfin ce genre de choses quoi ... C'est plutôt normal d'ailleurs, de par ça nature (run anywhere) ce genre de chose doit etre interdite, vu que la mémoire n'est pas gérée de la même façon sur les différents systèmes sur lesquels Java tourne. Tu pourrais qd meme faire ce genre de chose en implémentant un lib avec JNI (Java Native Interface, c'est le système pour utiliser du Java et du C ou du C++) mais tu perdrais la portabilité ...
      • [^] # Re: Bof, pas d'accord avec lui.

        Posté par (page perso) . Évalué à 10.

        Pas de manière native, il faut créer des librairies dans un autre langage que tu interfacera avec ton programme Java.

        C'est un inconvénient et un avantage, mais je pense que les avantages sont plus nombreux dans 95% des cas.

        De toute manière quitte à faire de la manipulation mémoire bas-niveau autant utiliser du C pur et dur, au moins tu décide exactement quel sera le comportement de ton application sans avoir des mécanismes new du C++ qui ne font pas toujours ce que tu pense (enfin quand tu n'as pas de malloc ou de free mal placés ou si ton programme ne fait pas autant de malloc que de free).

        Autrement je ne vois pas trop l'interêt d'une machine virtuelle si c'est pour coder comme un crade comme sur une vrai machine, tu te retrouves avec les emmerdes de gestions mémoire moins la performance.
        • [^] # Re: Bof, pas d'accord avec lui.

          Posté par (page perso) . Évalué à 10.

          sans avoir des mécanismes new du C++ qui ne font pas toujours ce que tu pense

          Si un 'new' C++ ne fait pas ce que tu penses, c'est soit un bug dans ton code, soit que tu ne devrais pas coder en C++ (soit les deux :-).
          • [^] # Re: Bof, pas d'accord avec lui.

            Posté par (page perso) . Évalué à 9.

            C'est vrai quand c'est toi qui code tes classes, mais si tu fais un héritage de 5éme niveau sur des classes que tu n'as pas codé, à moins de prendre ton papier et ton stylo pour refaire tout le processus de new, tu ne sais pas ce qui se passe (néanmoins tu pourrais savoir ce qui se passe, mais tu n'as pas forcément le temps de disséquer le code pour chaque classe que tu instancie).

            Donc effectivement, il peut y avoir un bug dans le code et je ne code pas en c++, c'est déjà suffisament long de debugger une application car tu n'avais pas prévu un comportement de l'application (je sais théoriquement, ton code doit prévoir tous les cas de figure) pour ne pas t'emmerder à rajouter la recherche des fuites de mémoires parce que ton prédecesseur ou toi-même a oublié une paire new-delete.

            Java permet de coder de manière largement plus crade car c'est le "garbage collector" qui s'occupe de ce problème pour toi et ça simplifie tout un ensemble d'erreurs au débuggage.

            Pour moi C++ doit être vu comme du C avec l'avantage de faire un découpage plus propre de l'application, car tu es obligé d'être plus propre dans ta conception (chaque objet(structure) à toutes les fonctions pour le manipuler dans un fichier) contrairement au C pur ou tes fonctions peuvent se balader n'importe où.

            L'héritage a plusieurs niveaux et multiple du C++, ça existe, mais c'est la première source d'emmerde garantie.
            Le problème est le même en Java, j'ai retravaillé une application existante ou les héritages étaient sur-multipliés, alors quand tu devais connaître le comportement d'une fonction ou du constructeur, tu devais parcourir toutes les classes du fils à l'ancêtre, car selon les niveaux, la fonction était surchargée ou pas.

            Dans ce cas là, je ne trouve pas que l'objet simplifie la programmation, je dirais plutôt au contraire

            C'est un joli modéle en théorie, mais trop en abuser nuit bcp plus à la lisibilité du programme qu'un simple langage procédural.

            C'est comme tout, le mieux est l'ennemi du bien.
            • [^] # Re: Bof, pas d'accord avec lui.

              Posté par (page perso) . Évalué à 10.

              mais si tu fais un héritage de 5éme niveau sur des classes que tu n'as pas codé

              Ah ok, je vois ce que tu veux dire. Oui, c'est un pb, mais tu ne peux pas vraiment comparer ça avec un simple malloc() C, c'est pas vraiment la même chose.

              Java permet de coder de manière largement plus crade car c'est le "garbage collector" qui s'occupe de ce problème pour toi

              C'est pas crade, bien au contraire c'est beaucoup plus pratique et élégant.

              Pour moi C++ doit être vu comme du C avec l'avantage de faire un découpage plus propre de l'application, car tu es obligé d'être plus propre dans ta conception

              Non, tu n'es pas "obligé", tu peux être plus propre. Être aussi propre en C réclame une discipline quasi-impossible à soutenir, parce que tu vas faire le boulot du compilateur. En C++, tu peux plus facilement être propre parce que le compilateur t'apporte les outils pour ça.

              L'héritage a plusieurs niveaux et multiple du C++, ça existe, mais c'est la première source d'emmerde garantie.

              Oui, mais l'héritage n'est pas une chose anodine, c'est un outil qu'il faut utiliser à bon escient.

              Dans ce cas là, je ne trouve pas que l'objet simplifie la programmation, je dirais plutôt au contraire

              Tu confonds la programmation objet et l'héritage. Ça n'a rien à voir. L'héritage est juste l'un des outils qui aident à faire de l'objet, il y en a pleins d'autres. Je te conseille de lire le chapitre d'introduction du Design Patterns.
              • [^] # Re: Bof, pas d'accord avec lui.

                Posté par (page perso) . Évalué à 10.

                Bien d'accord avec Guillaume.
                Et de plus, pour rappel, l'héritage multiple n'existe pas en Java, sauf pour les interfaces.
                Alors comment faire une application "ou les héritages étaient sur-multipliés" ? ;-)
                • [^] # Re: Bof, pas d'accord avec lui.

                  Posté par (page perso) . Évalué à 3.

                  Bien d'accord avec Guillaume.

                  Miracle. Mais descend plus bas, y a un autre thread ou on est pas d'accord. :-)

                  Et de plus, pour rappel, l'héritage multiple n'existe pas en Java, sauf pour les interfaces. Alors comment faire une application "ou les héritages étaient sur-multipliés" ?

                  Il parlait bien sur d'héritage successif, pas multiple. A qui dérive de B qui dérive de C qui dérive de... etc...

                  Pour info, dans Rosegarden (rosegarden.sf.net) on a bientot 60kloc, des templates, de l'héritage multiple, mais l'arbre d'héritage n'est pas très profond, 3 ou 4 niveaux maximum je pense, et 90% des classes ne sont pas dérivées, seules certaines classes de base le sont.
                • [^] # Re: Bof, pas d'accord avec lui.

                  Posté par (page perso) . Évalué à 8.

                  Bien d'accord avec Guillaume.
                  Moi aussi d'ailleurs je lui ai mis +1 :-)

                  Et de plus, pour rappel, l'héritage multiple n'existe pas en Java, sauf pour les interfaces.
                  Je parlais de C++

                  Alors comment faire une application "ou les héritages étaient sur-multipliés" ? ;-)
                  Ben justement, c'était un programme Java ou des classes avaient jusqu'à 5 générations d'ancêtres pour pas grand chose d'ailleurs, car ce n'était pas un arbre équilibré, ça ressemblait plus à une double liste chainée, et les fonctionalités du fils pouvaient ne plus réellement s'appuyer sur l'ancêtre, et en plus il y avait aussi des extensions d'interface (pseudo héritage multiple).

                  En gros c'était le modéle, alors on a 3 types de base (minéraux|animal|végetaux), alors on a besoin de manipuler des caniches nains et berger allemand
                  ben je vais définir
                  une classe animal qui utilise l'interface organique,
                  puis une classe mamifére qui utilise l'interface terrestre,
                  puis une classe chien,
                  puis une classe caniche qui utilisera l'interface nain
                  et une classe berger qui utilisera l'interface allemand.

                  Bon je schématise mais tout le programme était conçu comme ça, alors qu'on pouvait partir directement de la classe chien pour dériver les caniches et les bergers.
                  En soit l'idée n'est pas mauvaise, mais on sentait bien une application directe du cours de conception objet théorique ou tout les ressources mémoires et processeurs sont infinies, et avec des programmeurs qui sont des créatures avec un cerveau pouvant raisonner en 12 dimensions :-)

                  Quand on prend de la bouteille et qu'on a un cerveau qui ne pense plus qu'en 3 dimensions voire moins, on se simplifie la vie en codant selon la "vrai vie" et plus en théorie :-)
              • [^] # Re: Bof, pas d'accord avec lui.

                Posté par (page perso) . Évalué à 10.

                > Java permet de coder de manière largement plus crade car c'est le "garbage collector" qui s'occupe de ce problème pour toi
                C'est pas crade, bien au contraire c'est beaucoup plus pratique et élégant.


                Oui je suis tout à fait d'accord avec toi, moi aussi j'aime bien a ne pas m'occuper de la mémoire.
                Je voulais dire par là que tu vas plus facilement te "lacher" en créant pleins d'objets dans tous les sens sans te demander s'il n'y a pas de manières plus optimales pour arriver au même résultat.
                C'était juste un point de vue "puriste" que j'apprécie en théorie mais que je mets jamais en application en pratique :-) sauf en C ou je n'ai pas le choix (enfin si j'ai le choix d'avoir une application buggée :-)

                Être aussi propre en C réclame une discipline quasi-impossible à soutenir, parce que tu vas faire le boulot du compilateur. En C++, tu peux plus facilement être propre parce que le compilateur t'apporte les outils pour ça.

                C'est ce que je voulais dire, C++ t'apporte des mécanismes qui force ta conception et du coup rend les choses plus propres (sauf si on met du pur code C bien dégueulasse à l'intérieur évidemment car C est laxiste).

                Oui, mais l'héritage n'est pas une chose anodine, c'est un outil qu'il faut utiliser à bon escient.
                Tu confonds la programmation objet et l'héritage.


                Moi non, mais le problème c'est que dans certains programmes que j'ai repris, apparement cette idée n'avait pas été assimilée.
                Je fais des héritages uniquement sous l'effet de la torture, quand raisonnablement ça apporte un réel plus.
                <apparté>
                Je travaille en SSII, je parle de code programmé par des débutants (qui étaient trés loin d'être mauvais d'ailleurs) en milieu professionnel.
                Ils manquaient juste un peu d'expérience pour savoir quand est ce qu'il fallait appliquer le "manuel du parfait petit programmeur objet qui fait plein d'héritage car les héritages c'est jolis, les héritages c'est bon, mangez en" et quand est ce qu'il fallait dire "STOP". :-)
                </apparté>
                Mais je suis le premier à écouter un étudiant tout frais moulu quand il propose des idées, car il n'a pas d'idée préconçue ce qui permet d'avoir un autre point de vue, et d'éviter d'avoir une vision monobloc de la solution à un problème car je peux aussi faire des erreurs.
                • [^] # Re: Bof, pas d'accord avec lui.

                  Posté par (page perso) . Évalué à 3.

                  Je voulais dire par là que tu vas plus facilement te "lacher" en créant pleins d'objets dans tous les sens sans te demander s'il n'y a pas de manières plus optimales pour arriver au même résultat.

                  C'est vrai, tant que tu ne te soucies pas des perfs :-). Mais ça n'est pas la seule raison. Si tu fais du C++, tu dois régulièrement de faire chier avec des problèmes d'appartenance (quel objet doit effacer tel autre, etc...), qui exigent un maximum de rigueur pour être résolus. Contrairement à ce qu'on dit souvent, il n'y a pas de manière systématique de les gérer en C++, et un GC aide énormément pour ça. Je préfère dire que ça te permet de gagner du temps sur des problèmes souvent très complexes, plutôt que "ça te permet de te lacher".

                  C'est ce que je voulais dire, C++ t'apporte des mécanismes qui force ta conception

                  C'est juste le mot "force" sur lequel je ne suis pas d'accord. C++ ne force rien, il t'offre une possibilité. Java te force à faire de l'OO, pas C++.

                  Ils manquaient juste un peu d'expérience pour savoir quand est ce qu'il fallait appliquer le "manuel du parfait petit programmeur objet qui fait plein d'héritage car les héritages c'est jolis, les héritages c'est bon, mangez en" et quand est ce qu'il fallait dire "STOP". :-)

                  Alors nous sommes tout à fait d'accord.

                  Mais je suis le premier à écouter un étudiant tout frais moulu quand il propose des idées, car il n'a pas d'idée préconçue

                  On doit pas connaitre les mêmes étudiants :-). Enfin, je suis un peu contaminé par ce que je lis sur DLFP :-).
                  • [^] # Re: Bof, pas d'accord avec lui.

                    Posté par (page perso) . Évalué à 2.

                    Si tu fais du C++, tu dois régulièrement de faire chier avec des problèmes d'appartenance .... un GC aide énormément pour ça
                    C'est cool, tu traduis en termes plus exacts mes pensées incohérentes, j'ai encore des efforts à faire pour être plus compréhensible.
                    C'est exactement les problèmes auquels je pensais.

                    Je préfère dire que ça te permet de gagner du temps sur des problèmes souvent très complexes, plutôt que "ça te permet de te lacher".
                    C'est pour cela qu'on peut se lacher sur les allocations sans sortir un diagramme sur la gestion de la cohérence de la mémoire :-)
                    <séance typique de débuggage>
                    Alors là j'ai fait un new, bon dans ce cas là il faut faire un free, ah oui mais si la variable touintouin est vrai, alors non, ok, ah merde mais l'objet tada va en avoir besoin après si jamais, bon je crois que c'est bon là, make, toto.exe, coredump, ah merde j'ai oublié le cas ou on rentrait dans cette boucle que j'ai rajouté il y a 2h et que merde, ça casse tout, bon reprenons ....to be continued
                    </séance typique de débuggage>

                    C++ ne force rien, il t'offre une possibilité.
                    C'est vrai, mais si c'est pour faire du C en C++, autant faire du C, c'est un "forçage" moral pas technique.
                    L'inverse est encore plus vrai, déjà vu du code OO en C, bonjour l'angoisse pour le débuggage avec des pointeurs à rallonge pour simuler les classes sur des "struct" de fonctions.

                    -1 car squat de file
                    • [^] # la solution était

                      Posté par (page perso) . Évalué à 1.

                      Forcément il faut faire un delete pas un free, pas étonnant que mon programme soit buggé :-)
                      Si même dans mes exemples je me plante.

                      -oo car squat de mon squat
                    • [^] # Re: Bof, pas d'accord avec lui.

                      Posté par (page perso) . Évalué à 1.

                      Alors là j'ai fait un new, bon dans ce cas là il faut faire un free

                      Il faut faire un delete, malheureux ! :-)

                      C'est vrai, mais si c'est pour faire du C en C++, autant faire du C

                      Oui bien sur, mais il y a aussi des fois ou tu as vraiment besoin d'une simple fonction stand-alone, etc... C'est bien de pouvoir "débrayer" certaines choses.

                      L'inverse est encore plus vrai, déjà vu du code OO en C [...]

                      A qui le dis-tu (j'ai bossé 3 ans sur Gtk-- :-). Plus jamais ça.
                  • [^] # Etudiants frais moulu

                    Posté par (page perso) . Évalué à 0.

                    >Mais je suis le premier à écouter un étudiant tout frais moulu quand il propose des idées, car il n'a pas d'idée préconçue
                    On doit pas connaitre les mêmes étudiants :-). Enfin, je suis un peu contaminé par ce que je lis sur DLFP :-).


                    Je ne suis pas clair aujourd'hui, enfin si il a ses idées préconçues qui ne sont pas les miennes :-)

                    Mais il n'aura pas de réelle idée FORGEE sur la manière de traiter un problème auquel il n'aura pas été confronté même s'il a des idées préconçue fortes sur la manière optimale de traiter le problème.

                    Car seul un jeunes mec intelligent, face aux vieux cons qui ne comprennent rien à rien à l'informatique, peut le résoudre :-)

                    Du coup, c'est vrai que c'est plutôt le vieux con qui gagne à la fin, mais ça ne lui empéchera pas d'intégrer les éventuelles bonnes idée du jeune mec intelligent si elles sont réellement intelligentes. Et le jeune intelligent prendra de l'expérience s'il est assez intelligent pour écouter le vieux con. :-)

                    L'avantage du jeune intelligent, c'est qu'il aura des idées plus fraiches sur les nouvelles techniques de conception et de programmation, tandis que le vieux con, lui aura le retour d'expérience pour tempérer les ardeurs du jeune et relativiser le gain réel de telle ou telle technique.

                    -1
                    • [^] # Re: Etudiants frais moulu

                      Posté par (page perso) . Évalué à 2.

                      Je sais pas... le pb avec les étudiants c'est qu'ils ne savent rien, et même ça ils ne le savent pas. Donc quand tu le leur dis, ils ne te croient pas, et, justement, te prennent pour un vieux con.

                      Dans le cas de l'étudiant Linuxien, c'est pire, parce qu'il est le plus souvent shooté à l'idéalisme made in RMS, et il arrive non pas avec des nouvelles technos à la mode, mais avec des traditions et une idéologie. Y a qu'a voir les réactions sur la news récente à propos de Miguel et .Net, c'est un exemple parmi plein d'autres. Si tu leur dit "cet outil là marche mieux", il va immanquablement te répondre "oui mais sous Unix/Linux on fait comme ça depuis des années et ça marche".

                      Et autant faire bouger quelqu'un qui suit une mode est relativement facile, autant sortir quelqu'un de ses traditions est quasi impossible.

                      - Tu veux pas utiliser un IDE ?

                      - Nan, j'ai pas besoin, xterm+vi+make ça marche

                      - Et le temps que tu perds à chercher les fichiers dans l'arborescence, à faire des find | xargs grep pour trouver les definitions de fonctions ?

                      - M'en fous j'vais m'faire mes scripts et puis ctags roulaize.

                      J'en parle d'autant mieux que j'ai été comme ça (enfin, pas loin). Et j'utilise toujours pas d'IDE au bureau, mais c'est parce qu'il n'y en a pas qui tienne vraiment bien la route sous Linux :-).

                      Après c'est vrai, ils peuvent apporter des idées nouvelles, et les vieux cons aussi ont leurs habitudes bien ancrées dont il est bon de les faire bouger. Donc globablement, je dirais que les étudiants c'est bien, mais faut y aller avec des pincettes.

                      Enfin, on est d'accord là dessus je crois :-).
            • [^] # Re: Bof, pas d'accord avec lui.

              Posté par . Évalué à 3.

              Juste une petite info sur les héritages en Java.. Dans le bouquin "writing effective Java" (qu'on m'a chourré lors de ma dernière mission, donc j'ai plus les références exactes, mais qui est édité par Sun et écrit par un des développeurs du JDK), l'auteur mets à plusieurs reprises en garde contre les héritages inutiles. En gros, il dit que l'héritage, c'est Bien, mais que c'est pour faire des choses précises, et que sinon ça peut vite devenir une usine à gruiiik. Il donne plein d'idée s intéressantes sur comment faire autrement, et en particulier sur le bon emploi des interfaces (avec lesquelles il est plus difficile de faire porcin). très bon bouquin, amha, à lire..
    • [^] # Re: Bof, pas d'accord avec lui.

      Posté par (page perso) . Évalué à 10.

      Moi ce que j'ai compris c'est que avec le mot clef "unsafe", tu peux directement utiliser des pointeurs natifs dans le C#, et que donc tu peux travailler dans le dos du garbage collector.

      genre

      public void unsafe monGrosLeak() {
      int monPoiteur = malloc(10);
      }

      Avec java tu écrirait:

      public void native monGrosLeak();

      puis tu passes ta classe dans javah, qui va générer des entêtes (.h) avec la signature C équivalente de ta méthode. Puis c'est à toi d'implementer la méthode C séparément et d'en faire une librairie.

      C# permet donc d'utiliser rapidement du code natif, mais ca fait un mélange pas très heureux. Avec java, c'est plus long et fastidieux à écrire, mais tu a une séparation complête entre le code natif et le code java.

      A mon avis, il faut se lever tôt pour arriver à gagner en performance en gérant sa mémoire soi même (dans du java et du C#).

      En tout cas, pour mettre au même niveau C++, C# et vb, il ont du bien crader le C++... Avec un rapide coup d'oeuil sur msdn, on trouve des signatures C++ qui ressemblent à ca:

      void __gc __delegate MaClasse::maMethode();

      Ils ont peut être déposé C# dans les règles, mais le C++ en a pris un coup.
      • [^] # Re: Bof, pas d'accord avec lui.

        Posté par . Évalué à 8.

        Plusieurs points. Tout d'abord, le fait d'utiliser le mot clé unsafe dépend d'un paramétrage du système. Si c'est un problème, cela peut être désactivé.

        Ensuite, vu la séparation entre le code managed et le code unmanaged, ce genre de problème est peut probable. En effet, le mot clé ne s'applique qu'à des classes et méthodes et non à des variables. Dès que la CLR détecte ce mot clé, elle place l'assembly (la librairie en quelque sorte) dans un espace dédié. Si le code fait des choses incorrectes, cela n'impacte pas l'application ou la librairie appelante.

        Si j'étais vache, je dirais que tout appel JNI représente le même danger pour une JVM : aucun si la JVM est bien codée :)
    • [^] # Re: Bof, pas d'accord avec lui.

      Posté par (page perso) . Évalué à 10.

      Ton coup d'oeil à C# est certainement trop bref, et également celui à l'article !

      Exemple : "They had this problem in their design rules that they had to support C and C++, which means you have to have a memory model where you can access everything at all times" : Cela signifie que, comme d'habitude, on aura droit à de bon gros bug qui font planter le système... rehaussé par "they added gratuitous things and other things that are outright stupid. That's amusing"
      Citez moi un truc intéressant qu'un langage fait et qu'on peut pas faire en Java :-)

      A propos du "unsafe", le système de sécurité de Java permet d'accord des permissions de façon fine : accès réseau, mémoire, disque, etc. La c'est juste marqué "unsafe", super !

      C# reste décidémment une tentative de plus de M$ pour contrer SUN sur le terrain Java. Ils ont déjà essayé avec ActiveX, DCOM, etc, où les représentants officiels de M$ ont admis que s'ils avaient pu, ils auraient pris les mécanismes mis en place dans les beans... Mais bon c'est du M$, et ça marche pas ;-)

      "Imitation is the sincerest form of flattery--thank you very much". Evidemment, c'est bien d'imiter, mais quand c'est M$ qui le fait je suis pas convaincu.
      • [^] # Re: Bof, pas d'accord avec lui.

        Posté par (page perso) . Évalué à 3.

        Cela signifie que, comme d'habitude, on aura droit à de bon gros bug qui font planter le système...

        Tu en as en Java aussi. Une JVM peut parfaitement planter, ton code peut jeter une exception et ne pas la traiter. Et tu n'es pas "obligé" d'utiliser "unsafe".

        Citez moi un truc intéressant qu'un langage fait et qu'on peut pas faire en Java :-)

        L'operator overloading. D'ailleurs Gosling avait fait une proposition pour l'ajouter à Java :

        http://java.sun.com/people/jag/FP.html#overloading(...)

        Enfin, il y a des "extensions" non-officielles de Java qui supportent ça je crois, mais bon, c'est quand même mieux quand c'est en standard dans le langage.
        • [^] # Re: Bof, pas d'accord avec lui.

          Posté par (page perso) . Évalué à 5.

          Oui effectivement, l'operator overloading, un truc qui sert quasiment jamais et de plus supra "error prone" (source d'erreurs pour les développeurs).
          Alors ça je m'en passe sans regret !
          Et de préférence je n'en veut pas ! (voir les bouquins qui causent de codage propre, ils jettent tous cette technique moyenageuse du C++).
          • [^] # Re: Bof, pas d'accord avec lui.

            Posté par (page perso) . Évalué à 6.

            C'est beau de voir un professionnel qui donne une opinion posée, basée sur l'expérience et les faits.

            Je présume que tu as lu les raisons que Gosling donne pour vouloir l'ajouter à Java, et qu'elles t'ont semblées complètement stupides.

            Et comme tu dis que "tu" t'en passe sans regret, il est clair que ça doit être le cas pour absolument tous les autres programmeurs de la planète.

            voir les bouquins qui causent de codage propre, ils jettent tous cette technique moyenageuse du C++

            Lesquels ? Et, sachant que des bouquins fondamentaux de C++ (Stroustrup, Austern, Koenig) citent l'operator overloading comme une technique importante, permettant de clarifier le code, devons-nous conclure que ces auteurs sont, comme Gosling, des imbéciles ?
            • [^] # Re: Bof, pas d'accord avec lui.

              Posté par . Évalué à 7.

              À mon sens la surcharge d'opérateur c'est très utile.
              Imaginons une bibliothèque C++ permétant la manip de nombres entiers en multipécision.
              Sans surcharge c'est une horreur, avec ça devient très facilement utilisable. On peut même passer de la prog en entier classique vers celle en multiprécision en ne changeant que la ligne relative à la déclaration des variables.

              En plus le << c'est très utile.

              D'ailleur le merveilleux langage objet qu'est Ruby l'implémente avec bonheur et c'est ce qui le rend si compact par rapport à du Python.
              • [^] # Surcharge d'opérateur

                Posté par (page perso) . Évalué à 7.

                En dehors des surcharges pour des applications numériques, je ne trouve pas que l'opérateur overloading soit trés propre (mais c'est super pratique :-)

                De toute manière, c'est dans ce sens là que ça a été pensé.

                Autant il est plus logique d'avoir
                MatriceCarre(3x3) A,B,C,D; C = A + B; D =A * B;
                Maintenant si on a
                Matrice(7x5) E; A=B+E;
                on est dans la merde :-)

                Dés qu'on s'éloigne des types atomiques (int, float, char) on se retrouve avec pleins de "cast" à programmer, et l'opérateur sera bcp trop surchargé.
                Par exemple si je veux multiplier une matrice par un scalaire et multiplier 2 matrices entre elles j'aurais 2 surcharge de "*".
                C'est un peu comme l'héritage :-) il ne faut pas en abuser, si on voit qu'on commence à avoir toutes les fonctions d'une classe qui sont des surcharges d'ipérateur, il est bcp plus clair pour la reprise de code ultérieure de les nomer clairement mul2matrices, mulscalmatrice, etc..

                Autant une ligne de
                cout toto << " " << titi << " " << tata;
                est moins lisible | agréable à relire
                à mon sens que
                printf("%s %f.02 %c",toto,titi,tata); ou System.our.println(toto+" "+titi.toString()+" "+tata.toString());

                Comme d'habitude, c'est plus une discussion sur les gouts et les couleurs qu'un réel avantage d'un type de programmation de l'un sur l'autre. :-)

                Le plus important quand on programme c'est d'avoir un code consistant et de faire tout son application selon ses propres régles de programmation (si on est seul) mais de s'y tenir printf xor cout par ex, surcharger xor pas, fromage xor dessert :-)

                D'ailleurs c'est marrant dans les gros projets, on peut savoir qui avait tappé tel ou tel bout de code selon son style :-)
                • [^] # Re: Surcharge d'opérateur

                  Posté par (page perso) . Évalué à 5.

                  En dehors des surcharges pour des applications numériques, je ne trouve pas que l'opérateur overloading soit trés propre

                  Et pour une classe string ou array par ex ? Avoir le '[]' ça t'aide pas ? Ou les "+" et "+=" pour concatener des strings ?


                  cout toto << " " << titi << " " << tata;
                  est moins lisible | agréable à relire
                  à mon sens que
                  printf("%s %f.02 %c",toto,titi,tata); ou System.our.println(toto+" "+titi.toString()+" "+tata.toString());


                  Oui mais note que le printf() est moin safe, parce qu'il n'y a pas de vérification sur le nombre ou le types des arguments passés après le string de controle (gcc -Wall aide un peu, mais en général non). Et le 2eme exemple que tu donnes utilise l'operateur overloading aussi, dans un certain sens :-).
                  • [^] # Re: Surcharge d'opérateur

                    Posté par (page perso) . Évalué à 1.

                    je ne trouve pas que l'opérateur overloading soit trés propre (mais c'est super pratique :-)
                    Avoir le '[]' ça t'aide pas ? Ou les "+" et "+=" pour concatener des strings ?

                    Ben voilà y a plein de choses belles en théorie que je fais pas en pratique et vice-versa. :-)

                    le printf() est moin safe
                    Jamais dit le contraire, je parlais d'esthétisme de code a caractère purement subjectif :-)
                    En fait je programme perso en C et en Java au boulot, c'est pour cela que je n'utilise pas bcp le "cout", mais si j'utilise du C++ j'évite de faire du C like et utilise iostream au lieu de stdio.

                    tu donnes utilise l'operateur overloading aussi, dans un certain sens :-)
                    On chipotte là :-)

                    -1 car devient HS
                  • [^] # Re: Surcharge d'opérateur

                    Posté par (page perso) . Évalué à 3.

                    Ou les "+" et "+=" pour concatener des strings ?

                    Et oui, en java, on ne peut pas faire de l'operator overloading, SAUF pour les strings (et on aurait du mal à s'en passer). perso j'aime pas trop les langages conçus avec des "sauf".

                    System.our.println(toto+" "+titi.toString()+" "+tata.toString());
                    Avec l'opérateur "+", pas besoin de mettre des "toString()" partout justement (d'ailleurs quand tu veux passer un entier à une méthode qui veut une String, tu peux mettre ""+2, mais bon c'est plus pratique que joli), avec l'exemple, on obtient :
                    <code>System.out.println(toto+" "+titi+" "+tata);<code>
                    et à part mettre les variables directement dans la string à la shellscript, on peut difficilement faire plus clair.
                    • [^] # Re: Surcharge d'opérateur

                      Posté par (page perso) . Évalué à 1.

                      avec l'exemple, on obtient :
                      <code>System.out.println(toto+" "+titi+" "+tata);<code>

                      Tout a fait d'accord, j'ai "forcé" le toString() pour simuler la syntaxe pour l'affichage d'un objet Complexe genre Matrice, liste chainée, affichage ascii d'un framebuffer QuakeIII pour jouer sur VT100 .... :-)
                • [^] # Re: Surcharge d'opérateur

                  Posté par . Évalué à 3.

                  Euh autant je suis d'accord avoir toi sur la premiere partie: la surchage d'opérateur, c'est comme l'héritage: c'est très pratique quand c'est utilisé a bon escient, et ça peut être tres tres sale quand c'est mal utilisé..

                  <anecdote personelle> je me souviens d'un framework qui avait surchargé un opérateur et il y avait un bug dans la surcharge.. J'ai mis un temps dingue avant de comprendre pourquoi une partie du code tout ce qu'il y a de banal sortait n'importe quoi...</anecdote personelle>

                  Mais sinon cout vs printf, a mon avis la c'est plus une question d'habitude qu'autre chose..
                  Moi aussi je prefere le printf, mais je pense que c'est + lié au fait que j'ai plus l'habitude du C que du C++ qu'autre chose.

                  La plupart du temps dans printf on ne fait pas de format spécial alors cout marche tres bien et est plus court.
                  C'est le formatage d'argument avec cout qui est vraiment pas terrible..

                  De toute maniére je préfére le code ruby:
                  print "ca c'est une maniere elegante d'inclure une ${variable} dans une chaine\n";
                  • [^] # Re: Surcharge d'opérateur

                    Posté par (page perso) . Évalué à 3.

                    C'est le formatage d'argument avec cout qui est vraiment pas terrible..

                    C'est le moins que l'on puisse dire. D'un coté c'est pratique pour les trucs simples (genre string + entier + string) parce que tu n'as pas à te soucier du typage, tu enfiles juste les '<<'. Mais dès que tu veux parametrer un peu l'affichage (genre des entiers en hexa ou une certaine précision sur les floats), ça devient très très moche.

                    De toute maniére je préfére le code ruby

                    Ah, toi aussi ? C'est définitivement le meilleur langage de script que je connaisse :-).
                    • [^] # Re: Surcharge d'opérateur

                      Posté par . Évalué à 1.

                      De toute maniére je préfére le code ruby
                      et
                      Ah, toi aussi ? C'est définitivement le meilleur langage de script que je connaisse :-).

                      C'est dingue, toutes les personnes qui connaissent Ruby disent ça !!!
                      Et pourtant c'est vraiment pas très répendu comme langage.
                      Il faudrait en parler plus sur tous les sites genre linuxfr. Je crois que je vais faire un peu chier les mongueurs avec Ruby dans un future proche ;-)
                      • [^] # Re: Surcharge d'opérateur

                        Posté par (page perso) . Évalué à 3.

                        C'est dingue, toutes les personnes qui connaissent Ruby disent ça !!!

                        Non, c'est normal : Ruby est le meilleur langage de script actuellement. :-) Toutes les personnes à qui je l'ai montré le trouvent bien aussi.

                        Et pourtant c'est vraiment pas très répendu comme langage.

                        C'est en train de prendre de l'ampleur.

                        Il faudrait en parler plus sur tous les sites genre linuxfr.

                        Ou ré-écrire daCode en Ruby.
      • [^] # Re: Bof, pas d'accord avec lui.

        Posté par (page perso) . Évalué à 10.

        Citez moi un truc intéressant qu'un langage fait et qu'on peut pas faire en Java :-)

        Ben justement la manipulation directe de la mémoire dans le code java sans passer par une librairie extérieure :-)
        Tu peux pas te la jouer gros haxor en java en développant le driver de la dernière carte gfx à la mode qui tue de la mort 2 fois :-)

        Evidemment, coder des drivers ce n'est pas forcement le truc interessant à faire pour tout le monde :-)

        Reste que Java n'est pas du tout fait pour attaquer une machine physique sans API HAL (couche d'abstraction matérielle).***
        Java peut tout faire sauf ce domaine trés restreint de la programmation bas niveau du matériel.
        Maintenant ce n'est pas forcement ce qu'on lui demande non plus et il n'est pas fait pour ça, il y a le C et l'ASM qui sont bcp plus indiqués pour gagner quelques précieux cycles processeurs.

        *** Evidemment je parles de la JVM standard de la JDK 1.3, par exemple dans le cas des puces hardware java qui traduisent à la volée en code ARM des instructions bytecode, je ne sais pas s'il est possible de manipuler directement les adresses mémoires physique (pas de JVM dans ce cas là).
      • [^] # Re: Bof, pas d'accord avec lui.

        Posté par . Évalué à 3.

        Il ne faut pas confondre le modèle mémoire et le modèle sécurité : les droits d'activer telle ou telle librairie sont aussi gérés. Ce qui peut permettre à une entreprise de déployer des modèles de sécurités très fins. Par exemple, toutes les applications développées par le service interne (et donc signées par un certificat X509) ont droit à tout et les autres n'ont le droit qu'aux fichiers du poste et pas aux connexions réseaux...
        • [^] # Re: Bof, pas d'accord avec lui.

          Posté par . Évalué à 1.

          Par exemple, toutes les applications développées par le service interne (et donc signées par un certificat X509) ont droit à tout et les autres n'ont le droit qu'aux fichiers du poste et pas aux connexions réseaux...
          A condition de passer par l'API de microsoft. Mais si on autorise les pointeurs, on peut écrire ce que l'on veut où l'on veut dans l'espace mémoire d'un processus. On peut donc également éxécuter ce que l'on veut. Les pointeurs sont vraiment trop dangereux pour être autorisés par les langages haut-niveau.
          La seule façon d'éviter ça, c'est d'avoir un espace d'adressage par morceau de code. Ou d'utiliser un processus par morceau de code.
          • [^] # Re: Bof, pas d'accord avec lui.

            Posté par . Évalué à -2.

            ... et c'est justement ce qui est fait (d'après un commentaire de pmanach au dessus). Ils sont pas si bêtes chez MS ;)
            Voila qui m'apprendra à ne pas lire tous les commentaires avant de poster...
    • [^] # C# ne protège pas correctement les accès mémoires

      Posté par . Évalué à 1.

      Je ne comprend pas vraiment la... C'est pas au systeme d'exploitation de gerer les acces memoires ?
      Si un programme fait des conneries avec la memoire qui lui est alloue ca ne pose pas trop de problemes...
  • # moralité de SUN

    Posté par . Évalué à 3.

    c'est vrai que SUN ne pousse pas trop l'open source
    et que leur java n'est pas libre. mais SUN c'est
    aussi open office et ce n'est pas négligeable.

    pis RMS il est gentil mais il a fait GNU emacs, effectivement le gosling il a fait la premiere
    version d'emacs... (est-elle encore utilisée?)

    pour ce qui est Gosling ca me viendrait pas a l'idée
    de lui demander un autographe :-)
    • [^] # Re: moralité de SUN

      Posté par (page perso) . Évalué à 8.

      Non il n'a pas fait la première version d'emacs, c'est RMS qui l'a fait. Gosling en a écrit une version pour Unix par contre. Lire les liens sur une news, c'est pratique de temps en temps, on apprends des choses... :-P
      • [^] # Re: moralité de SUN

        Posté par . Évalué à 1.

        hum... j'avais lu mais pas compris comme ca... bon mea culpa, fouttage avec des orties fraiches et tout
        ca

        :-)
  • # java

    Posté par . Évalué à -10.

    Ca va être le troll de la journée mais :

    Tout le monde parle tout le temps de java, les commentaires ici sont toujours abondant et pourtant j'aimerais bien savoir ou je peux en voir du java, parce que depuis les applets d'il y a 5 ans ou les applets de webcam et irc je voit rien !?

    -1 pour engager le mouvement
    • [^] # Qques exemples ...

      Posté par (page perso) . Évalué à 9.

      IDE :
      JBuilder, IntelliJ, Forte, ...

      Editeurs :
      Jext, Jedit, ...

      File sharing :
      LimeWire

      Jeux :
      Roboforge, les 10000 applets (parfois bonnes, parfois moins)

      ....

      Fais une petite recherche sur google, tu serais étonné de voir tout ce qui existe en Java
    • [^] # Re: java -> exemple d'Oracle !?

      Posté par . Évalué à 1.

      L'installeur d'Oracle (8) client et/ou serveur est en JAVA, alors qu'Oracle lui même (client et serveur) n'a rien a voir avec Java !
      L'interêt d'Oracle : Ils ont fait un installeur universel, avec interface graphique, qui est succeptible d'installer leur produit sur les OS supportant JAVA.
      M'enfin, c'est un peu chiant d'installer JAVA juste pour ça (quand on arrive a se dépetrer des versions etc...), une install a base de shell script m'aurait convenu ... ou bien apt-get install oracle-serveur ;-)
      voilaaaa
      c'était un exemple
      • [^] # Re: java -> exemple d'Oracle !?

        Posté par . Évalué à 0.

        quand tu parles d'oracle 8, tu dois parler de la 8i parce que la 8.0.5 a l'epoque s'installait tres bien sans java.
        a partir de la 8i Oracle devait intégrer java et la bdd. L'idee etait par exemple de stocker directement des morceaux de code java dans la bdd...
        j'avoue m'etre arrete a la 8.0.5., mais si les plans pour le futur (8i et apres) on été respecté, installer oracle sans java c'est une hérésie non ?
        • [^] # Re: java -> exemple d'Oracle !?

          Posté par . Évalué à 2.

          sais pas. je te donne un exemple plus parlant :
          J'installe Oracle 8i client sur une Linux box, tout ça dans /oracle (mettons), OK.
          j'installe une nouvelle box sans Java. Je transvase mon /oracle de ma machine 1 a ma machine 2. Je bidouille 2 lignes dans /etc/ld.so.conf (me rappel plus exactement). J'ajoute les variables d'environnements ORACLE_HOME, NLS_LANG, ... et /oracle/bin ds mon path et hop !
          ça marche ! Oracle sans un goutte de Java !
          • [^] # Re: java -> exemple d'Oracle !?

            Posté par (page perso) . Évalué à 3.

            La base de donnée Oracle n'est pas en Java, et à priori ne le sera jamais (pour des questions de performance).

            Par contre tous les outils annexes comme l'installeur, les terminaux de requête SQL, les outils d'administration, la création des formulaires graphiques Forms etc.. vont être migrés peut à peu en Java, pour Oracle, c'est l'utilisation de la maxime Write Once, Run Everywhere, ça leur évite de redevelopper ces outils en natif alors qu'ils n'ont pas besoin d'être super performant.
            Avoir un temps de réaction de 2s au lieu d'1s sur l'affichage d'une requête sql à la "mano" tappée dans un terminal sql pour un developpement n'est pas trop grave.
            Par contre gérer 10000 requête simultanées au lieu de 5000 est super important pour le moteur de la base de donnée (les chiffres sont débiles et pris au hasard).
    • [^] # Re: java

      Posté par (page perso) . Évalué à 2.

      arkanae :
      arkanae.tuxfamily.org

      RPG 3D tout en java & opengl ...
      • [^] # Re: java

        Posté par (page perso) . Évalué à 0.

        <demi-troll>
        Arkane, joli, mais 4-6 fps sur l'ordi ou je l'avais testé, mais c'est vrai qu'il n'était pas équipé d'une super carte gfx.
        Néanmoins, je pense q'un équivalent (C|ASM)+(Opengl|DirectX) aurait pu tourner dans les 20~30 fps sur la même config.
        Y a pas a chier, pour les jeux (C|ASM) rulez, même si ça n'enléve rien aux qualités d'Arkanaé, j'y jourais dans 4~5 ans quand j'aurais un 6ghz avec 2go :-)
        </demi-troll>
        • [^] # Re: java

          Posté par (page perso) . Évalué à -3.

          <neuneu>
          marche tres bien quand on configure ca carte 3D (moderne correctement ...
          </neuneu>
      • [^] # Re: java

        Posté par (page perso) . Évalué à -4.

        Pouf.
        Scuzez moi de foutre ma merde : (lu sur le site de arkanae)

        Développé en Java, multiplateforme Linux et Windows

        La je voie 2 plateformes. ca fait aps bcp pour du multiplateforme.
        Develloper ca en C aurait ete aussi simple a porter, et aurait gagné 50fps.
        Le java c'est bien pour ce faire un CV, mais c'est tout...
        • [^] # Re: java

          Posté par (page perso) . Évalué à 1.

          Develloper ca en C aurait ete aussi simple a porter

          Vas-y, fais-moi voir un programme en C avec une GUI, tournant sur Unix et Windows, et dont le code soit "aussi simple" que du Java.
          • [^] # Re: java

            Posté par (page perso) . Évalué à -1.

            Gtk, Qt, etc, pour le GUI. Qt plutot, paske l'air de rien gtk sous win ca a du mal.
            Et desolé, mais je trouve le C bien plus simple que le Java. Chacun son truc.
            D'un autre coté, si tu prend tes yeux et que tu les posent sur mon post, tu verra ecrit "aussi simple a porter". A porter je lis moi. pas a ecrire.
            • [^] # Re: java

              Posté par (page perso) . Évalué à 1.

              Gtk, Qt, etc, pour le GUI.

              Qt c'est du C++ (oui, y a les bindings C, mais pour utiliser ça directement faut vraiment être maso). Plus précisément, c'est une toolkit C++, donc un produit "en plus", et c'est eux qui se sont frappé pour toi tous les problèmes de portabilité.

              D'un autre coté, si tu prend tes yeux et que tu les posent sur mon post, tu verra ecrit "aussi simple a porter". A porter je lis moi. pas a ecrire.

              Ah. Parce que tu arrives à porter du code sans écrire du code supplémentaire, ni modifier le code existant. T'es 'achement doué toi :-).
              • [^] # Re: java

                Posté par . Évalué à 3.

                Je travaille depuis plus de 2 ans sur une appli client en java. 100% du développement a été fait sous windows (avec jbuilder 3,4,5) ... On a toujours pris soin à preserver l'aspect multiplateforme (pas de Runtime.exec(), pour la manipulation des path toujours utiliser File.separator plutot que "/" ou "\"). Le jour ou on a testé le produit sous linux, les seuls problemes qu'on a etaient liée aux Look & Feel (par defaut windows, pas disponible avec la vm sun linux) ...

                En java il est donc possible de "porter" une appli pratiquement sans réécrire de code.
                • [^] # Re: java

                  Posté par (page perso) . Évalué à 0.

                  Oui mais là justement on parlait de porter du code C (j'aurais du préciser).
                • [^] # Re: java

                  Posté par (page perso) . Évalué à 1.

                  Hors sujet : pour les ceuses qui font du java sur plateforme ms, pas besoin de se faire chier avec File.separator : on peut remplacer '\' par '/' dans les noms de fichiers (c'est quand même plus lisible)
                  • [^] # Re: java

                    Posté par . Évalué à 2.

                    Ca reste une mauvaise idée !

                    File toto = new File(getPath(),"titi\toto");
                    return toto.getName();

                    ne retourne pas la meme chose que

                    File toto = new File(getPath(),"titi/toto");
                    return toto.getName();
        • [^] # Re: java

          Posté par (page perso) . Évalué à 3.

          ca marche aussi sous macosX

          et y a pas de code specifique...
    • [^] # D'autres exemples .... et bien plus ...

      Posté par . Évalué à 9.

      En plus de ceux cités précedement :

      Freenet : Un des projets les plus interessants de ces dernieres années ... http://freenet.sourceforge.net/(...)

      JDiskReport : un outil d'analyse de disque vraiment pratique et trés ergonomique (compatible JNLP)

      FreeNews : permet de disposer d'un forum NNTP entierement anonyme car utilisant Freenet (compatible JNLP)

      Tejina : apprendre à écrire des idéogrames facilement (compatible JNLP)

      JAP : un proxy pour anonymizer/tuneller ses connexions (compatible JNLP)

      ... plein d'autres applications JNLP / JavaWebStart sont disponible il suffit d'appeler google à l'aide...

      Ou alors d'aller sur le *super-mega* site : http://www.up2go.net(...) ou sont listés -ô mirrracle - les meilleures applications JNLP disponibles ;-)


      Sinon, recement c'est le marché de l'*embarqué* qui a pas mal bougé autour de J2ME surtout pour les telephones portables: http://www.microjava.com(...) Motorola, Siemens sont en europe les premiers à sortir des telephones déja dispo (accompli 008, s45/s45i, ...), plutot pratique de developper ces appli (les midlets) sous Netbeans ou JBuilder et de les voir fonctionner en live !

      Et pour finir ze truc sympas :
      SavaJe XE ( http://www.savaje.com(...) ), Un OS a recement fait bondir le Java One car ils ont reussit à faire tenir une plateforme J2SE (Swing, Corba, RMI, ... et meme compatible JNLP!!) sur un iPaq traditionel !!!
      Ok, on pouvait mettre pocketlinux et la VM J2SE de blackdown mais pas sur 12M et avec de telles perfs quasi-supérieures au win CE ;-)

      Dans ce cas c'est encore plus impressionant que J2ME puisque n'importe quelle appli J2SE (sous reserve de la place disponible) peut fonctionner dessus sans changement notoire (verifier juste que par defaut les palettes d'outils ne prennent pas tout l'ecran par exemple ...).

      Bref, Java à bien changé depuis ses debuts et même si je pense qu'il n'est pas parfait les possibilités offertes aujourd'hui sont souvent sous-estimés car beaucoup se sont arrétés à l'apprentissage du langage sans entrevoir les capacités et la puissance de la plateforme.
      De plus, il existe en Java deux approches qui cohexistent *paisiblement* : les logiciels libres et les logiciels comerciaux ...

      Il est domage de ne pas voir plus de personnes sur linux s'investir également dans Java et par exemple contribuer à l'amélioration des VM blackdown ...

      --
      Allez hop, -1 pour l'auto-promo du site :o)
  • # Quel environnement de développement pour Java?

    Posté par . Évalué à 4.


    >> Cette interview est assez interessante aussi pour son point de vue sur les environnements de développement.



    Question : Sur quels projets travaillez-vous actuellement pour Sun?



    Gosling: Cela fait maintenant 10 ans que j'ai inventé le Java, c'est pourquoi j'ai décidé qu'il était temps de faire autre chose. Je suis donc retourné au laboratoire de recherche de Sun, où j'ai dernièrement travaillé sur un projet d'outil de développement. Aujourd'hui, presque plus personne ne crée d'environnements de développement intégré (IDE), d'autant qu'ils sont généralement destinés à des développeurs novices. Or peu d'outils adaptés sont à leur disposition, hormis Emacs. J'ai conçu la première version d'Emacs il y a 23 ans et je constate avec effroi que cet outil est toujours utilisé aujourd'hui tel qu'il était à l'origine. Est-ce là tout ce que l'on peut offrir de mieux à ces développeurs? Je ne crois pas.



    >> Effectivement, en voulant "aider" trop les développeurs, les IDE classiques (comme Visual Age, JBuilder et autres) séduisent les novices, mais brident rapidement les développeurs au sein d'un carcan. A terme, les développeurs confirmés optent pour une collection d'outils modulaires, chacun les meilleurs dans leur catégorie, et les invoquent depuis un éditeur de texte. Le plus populaire est effectivement Emacs (c'est ce que j'utilise). Emacs est extensible et permet, avec JDE (Java Development Environment for Emacs, http://jdee.sunsite.dk/(...)) d'aider les programmeurs Java . En développement Java, Les outils intégrables dans Emacs les plus populaires sont ANT (automate de construction d'application, http://jakarta.apache.org/ant/(...)), JUnit (Tests Unitaires, http://junit.org/(...)), CVS (Gestion de sources, http://www.cvshome.org/(...)), Cruise Control (integration continue, http://cruisecontrol.sourceforge.net/(...)), XDocLet (Génération automatique de composants, http://sourceforge.net/projects/xdoclet/(...)). Toutefois le développeur reste libre d'étendre son environnement en fonction de ses besoins.


    >> Il est assez amusant de constater que Gosling, l'inventeur de Java, est aussi l'inventeur de l'Emacs moderne, développé en C (dont il dispute la paternité avec Richard M. Stallmann, le chantre du logiciel libre, cf. http://www.jwz.org/doc/emacs-timeline.html(...)).


    Gosling: Sun a fait l'acquisition d'un outil de développement appelé NetBeans, créé à la base pour servir de structure de conception. Il s'agit d'un système souple dont nous avons publié les codes source il y a un an et demi. Je travaille actuellement à la création d'un plug-in pour NetBeans.



    >> Netbeans (www.netbeans.org) est un IDE moderne en ce sens qu'il est complètement extensible. Chacun peut faire évoluer NetBeans en développant des plug-ins. L'environnement commercial de Sun (Forte for Java) est basé sur NetBeans. Si quelqu'un comme Gosling travaille sur NetBeans, ça va être assez intéressant de surveiller ça...



    Question : IBM a créé son propre projet open source, appelé Eclipse, afin d'intégrer des outils de développement Java. Les développeurs pourront ainsi choisir des outils provenant de différents éditeurs de logiciels, les assembler et les faire fonctionner ensemble. La plupart des concepteurs d'outils se sont joints au projet Eclipse, mais pas Sun, ce qu'a déploré IBM. Que se passe-t-il?
    Gosling: NetBeans présente de nombreux points communs avec Eclipse. IBM pense que nous avons eu tort de ne pas nous joindre à son projet. Or on ne nous l'a même pas demandé. Nous n'en avons entendu parler que lorsqu'il a été annoncé. Eclipse ressemble à un produit dérivé, créé simplement pour faire la même chose que les autres. Sans parler de la campagne marketing, qui est vraiment étrange.



    >> Eclipse, http://www.eclipse.org/,(...) reprend les mêmes principes que NetBeans. Pas étonnant que IBM na pas demandé à Sun de l'aider. Eclipse est intéressant et IBM tente d'en tirer le meilleur parti en terme de notoriété, mais il me semble un peu en retard sur NetBeans. La principale question est : quel est l'avenir à terme chez IBM des IDE vieux modèle comme Visual Age et Visual Studio face à Eclipse ? IBM s'auto-concurrence et ses clients peuvent être inquiet pour la pérennité de Visual Age...



    Question : À terme, envisagez-vous une fusion entre ces deux projets open source?
    Gosling: Ce n'est pas exclu. Certaines personnes y réfléchissent sans doute. C'est difficile de dire ce qu'il adviendra. L'essentiel est de définir un set commun d'API (interfaces de programmation d'applications), ce sur quoi nous travaillons depuis un an et demi. Nous aurions apprécié qu'IBM participe au projet open source que nous avons initié depuis longtemps déjà.


    >> On peut regretter que IBM n'ai pas rejoint le projet NetBeans plutôt que de développer son propre truc, mais on peut comprendre que IBM n'ai pas envie d'aider SUN à faire son marketing...



    >> Conclusion : Les IDE foisonnent chez les novices mais Emacs reste l'environnement fétiche des développeurs confirmés, même si c'est un outil ancien. Des IDE extensibles et ouverts, comme Emacs, mais plus modernes, restent à inventer. NetBeans et Eclipse sont d'intéressantes tentatives, mais doivent mûrir pour obtenir la reconnaissance dont Emacs jouit aujourd'hui...


    Conclusion de la conclusion: Emacs Rulez! (ou VIM à la rigueur...)

Suivre le flux des commentaires

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