Sortie d'Eclipse 3.0 finale

Posté par  . Modéré par Nÿco.
Étiquettes :
0
26
juin
2004
Java
Eclipse 3.0, plate-forme de développement universelle pour la création d'applications, vient de sortir en version finale le 21 juin.

Eclipse est un environnement de développement efficace, adaptable et open source, et ce pas uniquement pour le langage Java (JDT - Java Development Tools ) puisque d'autres langages sont disponibles via des plugins, comme le C/C++ (CDT) , perl ou autre.

Résultat de 15 mois de travail de la communauté eclipse, ce passage en version 3.0 apporte son lot de nouvelles fonctionnalités, la plus visible étant l'interface utilisateur.

Mise à jour : c'est de la 3.0RC3 dont il est question. La 3.0 finale est prévue fin juin.

Mise à jour 2 : la version 3.0 est disponible depuis le 25 juin. Coordonnée avec la sortie de la 3.0, le CDT (C/C++ Development Tools) est lui aussi disponible. Il propose de nouvelles fonctionnalités : amélioration de la recherche de chaîne, complétion configurable, navigateur de classe, fonctionnalités de refactoring pour l'automation de modifications de code à travers un projet.

La création et la maintenance de makefile est aussi incluse dans le CDT.

Complémentaire du CDT, Hyades 3.0 propose un framework d'intégration et des outils pour l'optimisation et la vérification d'applications. Cela inclut les tests, le traçage, le profiling, les logs et le monitoring des applications.

Note sur la disponibilité :

Sur la page de téléchargement, la 3.0 finale n'est pas encore disponible, la dernière version disponible au D/L étant la 3.0rc3. La 3.0 finale sera disponible au téléchargement le 30 juin.

Avis Personnel :

J'utilise eclipse depuis près d'un an à mon travail ainsi que pour mes travaux personnels. À mon sens c'est le meilleur IDE java disponible, même s'il lui manque encore dans la version basique des fonctionnalités par rapport à netbeans, un petit tour sur la page des plugins pour eclipse permet de rattraper partiellement ce "retard".

L'essayer c'est l'adopter :)

Aller plus loin

  • # Euh....

    Posté par  . Évalué à 6.

    Les infos que j'ai du site d'eclipse, c'est une RC4 qui sort le 25, et pas de date pour la finale :

    Monday June 21, 2004 10:20 EDT Status: Today is a 1-day test pass using the RC3 build (download). This is our last scheduled test pass.

    J'en profite pour préciser que pour les eclipse web tools il devrait y avoir une M3 fin octobre (Elle correspond a la fin de la phase de validation)

  • # Vive les plugins

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

    J'éspère que plutôt que d'avoir des JBuildet, JDevelopper, Netbeans, Forte...... on ne va plus avoir qu'un seul IDE avec des plugins.

    Ca permettrait de pouvoir profiter de toute ce qui se fait en libre et en propriétaire sans avoir à se marrier avec un IDE. Ca pemet aussi aux gens d'apprendre une interface, de se familiariser avec et de la garder pour tous les développements.

    Pour les editeurs d'EDI et de plugins, ca va leur permettre d'économiser et d'éviter de réinventer la roue pour toutes les fonctionnalités de base.

    Voila, c'est un post un peu simpliste, un peu bateau mais il fait chaud, j'ai pas envie de bosser et en écrivant, j'ai pas l'impression de glander :)

    http://about.me/straumat

    • [^] # Re: Vive les plugins

      Posté par  . Évalué à 7.

      Pour les plugins c'est vrai qu'avoir un seul IDE serait un plus. Mais pour l'IDE lui même je pense que se serait une régression car il y aurait mécaniquement moins de développeurs à bosser dessus et en l'absence de concurrence il deviendrait impossible de se comparer au d'autres ou de s'entre piquer les bonnes idées.

      • [^] # Re: Vive les plugins

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

        Oui masi tous les IDE se valent...
        C'est un peu comme si tout le monde redéveloppait par exemple un logger (comme log4j), c'est vrai qu'il y aurait plus de conccurence mais bon, je suis pas sur qu'on arriverait à mieux.

        L'idée c'est d'avoir un IDE sur lequel pas mal de gens bossent et on ne garde que les meilleurs idées.

        http://about.me/straumat

        • [^] # Re: Vive les plugins

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


          > C'est un peu comme si tout le monde redéveloppait par exemple un logger (comme log4j),

          Un peu comme l'a fait Sun avec java.util.logging, tu veux dire ?


          seb.

          • [^] # log4j est pas terrible

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

            J'ai jamais accroché avec l'approche log4j.
            Heureusement que Sun a sorti autre chose, même si c'est malheureusement assez proche.
            NB : Ce n'est que mon avis...

          • [^] # Re: Vive les plugins

            Posté par  . Évalué à 3.

            Sauf que l'api de sun, y'a pas besoin de l'ajouter a ton archive finale c'est pas négligable dans certain cas

        • [^] # Re: Vive les plugins

          Posté par  . Évalué à 7.

          Oui masi tous les IDE se valent...

          Je ne pense pas. Et quand bien même se serait vrai à un instant donné il peut toujours y avoir un ch'tit nouveau qui grâce à quelques idées novatrices arrive à s'imposer (comme Eclipse face à Netbeans/JBuilder il y a qq années).

          C'est un peu comme si tout le monde redéveloppait par exemple un logger (comme log4j), c'est vrai qu'il y aurait plus de conccurence mais bon, je suis pas sur qu'on arriverait à mieux.

          Log4J est nettement plus simple qu'un IDE pourtant il ne satisfait pas 100% des gens. Maintenant pour quelque chose d'aussi complexe qu'un IDE je ne vois pas comment arriver à une solution satisfaisant tout le monde (quelques idées pour d'interminables discussions sur les ML: SWT vs Swing, IDE qui fait le café contre qq chose de plus light, etc.).

          L'idée c'est d'avoir un IDE sur lequel pas mal de gens bossent et on ne garde que les meilleurs idées.

          Ça me paraît carrément utopique. Au pire une partie des dev seraient démotivés et se reconvertiraient dans l'agriculture biologique et au mieux il y aurai un fork ou un projet concurrent.

          • [^] # Re: Vive les plugins

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

            beh je te donne un exemple, il manque le code collapser dans Eclipse, beh un mec a fait un plugin pour l'avoir... voila comment ça doit fonctionner.

            la satisfaction à 100% n'existe pas mais sur l'explorateur de classe, le collapser, la façon d'afficher les fichiers.. on peut peut etre se mettre d'accord et pour le reste -> plugin.

            http://about.me/straumat

            • [^] # Re: Vive les plugins

              Posté par  . Évalué à 3.

              Si on veut un eclipse qui marche sur Swing, pour plus que ça plante en permanence et que ça rame on demande ou ? :-)

              Eclipse sous Windows ça passe, sous Linux ça rame et c'est la cata ....
              Donc sous linux je préfère nettement Netbeans.

            • [^] # Re: Vive les plugins

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

              Si par code collapser tu entends la possibilite de cacher une unite de code lexicale (methode, boucle, etc), c'est dispo dans Eclipse 3.0.

  • # Plugin Ruby pour eclipse

    Posté par  . Évalué à 7.

    Pour ceux qui codent en Ruby, il existe un plugin pour Eclipse :

    RDT (Ruby Development Tools) is a eclipse plugin and allows therefore to use many of the ecplise features for the development of Ruby projects. Some of these features refer directly to files and can therefore leveraged without modifications for Ruby projects.
    These are for example:
    * Organizing Code with projects
    * Local History of files
    * Team support (CVS)
    * Search functionality
    * Run configurations
    * Undo/Revert

    Of course the RDT can also be mixed with other plugins like a xml plugin.

    L'adresse du site : http://213.203.244.123/wiki/wiki.phtml(...)

    • [^] # Re: Plugin Ruby pour eclipse

      Posté par  . Évalué à 2.

      Le plugin a l'air d'avoir besoin de l'extension org.apache.xerces, qui d'après ce que j'ai compris de mes quelques googleries a été virée d'eclipse depuis la 3.0-M9. Problème : je n'arrive pas à mettre la main sur cette fameuse extension manquante.

      Une idée ou url ? Merci d'avance.

  • # Plugin Tom pour Eclipse

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

    Pour ceux qui codent en Tom, il existe un plugin pour Eclipse :

    jtom-eclipse Languages (1.0)
    TOM is a language extension which adds pattern matching facilities to an existing imperative language. TOM supports C, Java and Eiffel as native language. This plugin fully integrates the Java version of TOM in the Eclipse environment (automatic compilation, data-structure generation, error recovery and documentation). The TOM system is written in Java+TOM and bootstrapped.

    L'adresse du site : http://tom.loria.fr/(...)

  • # Debs et RPMs d'eclipse...

    Posté par  . Évalué à 3.

    S'il y a bien une chose que je n'ai jamais comprise, c'est pourquoi un logiciel aussi utilisé et important qu'eclipse ne soit pas disponible officiellement en RPMs ou en Debs.

    Et de source officieuse, je n'en ai pas trouvé non plus. Si quelqu'un a l'explication, ou mieux, un lien vers un dépot RPM quivabieng...

    • [^] # Re: Debs et RPMs d'eclipse...

      Posté par  . Évalué à 8.

      Sur debian sid:

      amx@debian:~$ apt-cache search eclipse
      eclipse-javac - Eclipse Java compiler and ant plug-in
      eclipse-jdt - Java Development Tools plug-ins for Eclipse
      eclipse-nls-sdk - localized message catalog for eclipse
      eclipse-pde - Plug-in Development Environment to develop Eclipse plug-ins
      eclipse-platform - Eclipse platform without plug-ins to develop any language
      eclipse-sdk - Extensible Tool Platform and Java IDE
      eclipse-source - Eclipse source code plug-ins
      eclipse-webdav-ftp - Eclipse FTP and WebDAV Support
      libeclipse-jni - Platform dependend files for eclipse-platform
      libswt2.1-gtk2-java - Fast and rich GUI toolkit for Java, gtk2 version
      libswt2.1-motif-java - Fast and rich GUI toolkit for Java, motif version

      • [^] # Re: Debs et RPMs d'eclipse...

        Posté par  . Évalué à 4.

        La dernière fois que j'ai regardé je me faisais jeter parce que les paquets eclipse dépendent d'un paquet virtuel j2re-1.3 ou j2re-1.4 qui n'existe pas dans Debian (du moins parmi les paquets officiels) vu qu'il n'y a pas d'implémentation libre et complète des specs java 1.3 et encore moins 1.4. Il faut passer par des depots non officiels et installer un j2re non libre.

        Les dépendances sont un peu trop fortes à mon avis car Kaffe+Classpath (même s'ils n'implémentent pas tout le j2re) suffisent pour faire tourner eclipse.

    • [^] # Re: Debs et RPMs d'eclipse...

      Posté par  . Évalué à 8.

      Pour Mandrake il est dans la source JPackage:

      $ urpmq eclipse
      Les paquetages suivants contiennent eclipse :
      eclipse-ftp-webdav
      eclipse-gtk2
      eclipse-jalopy
      eclipse-jdt
      eclipse-legacymenu
      eclipse-mdkmenu
      eclipse-platform
      eclipse-scripts
      eclipse-sdk

      • [^] # Re: Debs et RPMs d'eclipse...

        Posté par  . Évalué à 4.

        Avec toutefois un gros problème, si je me souviens bien : les dépendances supposent que Java (le JDK) a été installé à partir des RPM de JPackage -- or, pour des raisons de licence, ces RPMs ne sont pas là : il n'y a que les RPMs sources, à partir desquels il faut construire les RPM binaires, après être allé fouiller sur le site de Sun (par exemple) pour récupérer le JDK sous une autre forme. C'était très pénible...

    • [^] # Re: Debs et RPMs d'eclipse...

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

      c'est aussi disponible dans l'arbre portage de gentoo...

    • [^] # Re: Debs et RPMs d'eclipse...

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

      www.jpackage.org

      et tu trouvera ton bonheur !!!

      (et sinon, c'est vrai que les sources mandrake font mirroir du ftp du projet jpackage)

      Ce qui est vraiment bien, c'est qu'il existe aussi des paquet src.rpm pour java ( et différentes extensions propriétaires de Sun) directement, et tu n'a qu'a rajouter le fichier .bin de java la ou il faut, et tu peut te faire des packages java, vraiment top ensuite pour faire de l'installation sur plusieurs postes.

      D'ailleurs, je me demande si ca ne serait pas possible par exemple à plf d'ajouter sur leur ftp les paquets binaires de java et compagnie

      Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

      • [^] # Re: Debs et RPMs d'eclipse...

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

        va faire un tour sur irc, demande leur, il te répondront.

        Sinon je peux peut-être l'inclure sur un de mes ftp sit tu veut (contacte moi par mail a rapsys PATCH free LOL fr), si tu est interessé...

        En fait je cherche quelqun pour re-compiler certain de mes paquets pour la mandrake official, car je fait des paquet que pour cooker et plus vu que la cooker est devenue binairement incopatible avec l'official et la community (changement de glibc et de gcc)...

        donc si tu veut ce paquet fait le, je pourrai l'inclure dans mon ftp après...

  • # Pour ceux qui utilisent Doxygen

    Posté par  . Évalué à 3.

    http://home.gna.org/eclox(...)

  • # Pour le C, par rapport aux autres il est bien ?

    Posté par  . Évalué à 6.

    Je me demandais si certains d'entres vous avait testé Eclipse pour du développement en C ?
    Comment se comporte-t-il par rapport à Anjuta ou Kdevelop ?

    Merci !

  • # Trop lent...

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

    Je n'utilise pas Eclipse sous GNU/Linux parce que c'est vraiment trop lent : l'interface bouffe 100% du CPU pendant plusieurs secondes pour la moindre action : menu, clic sur onglet... (non, mon PC n'est pas lent et mon installation de Java n'est pas foireuse non plus).

    Alors pour moi, désolé, mais Java c'est fini.

    J'ai l'occasion de l'utiliser tous les jours sous Windows, et c'est beaucoup plus réactif. C'est dommage, c'est un excellent IDE...

    Défenseurs de Java, moinssez ce message (comme d'habitude en fait).
    Les IG en Java c'est lent, quand on dit la vérité ça fait mal, forcément...

    • [^] # Re: Trop lent...

      Posté par  . Évalué à 10.

      Cela ne serait pas plutot la jvm linux qui serait plus lente que celle de windows ? Idem pour flash player non ? (oui oui le truc qui bouffe 100% du proc en continue ). Notez le point commun entre ces deux produits ...

      Il est clair que eclipse est beaucoup plus réactif sous windows.

      Sinon il ne faut pas exagérer, sa reste tout à fait utilisable sous linux ... (Je code dessus depuis plusieurs mois sur un athlon xp-m 1800+, avec tomcat en fond et je m'en sort très bien).

      • [^] # Re: Trop lent...

        Posté par  . Évalué à 6.

        En perfs pures je crois que les JVM sont équivalentes sous Linux et Windows. C'est à mon avis surtout l'aspect interface graphique Java qui rame sous Linux. Que ce soit Swing ou SWT c'est beaucoup plus réactif sous Windows que sous Linux
        Les adeptes de SWT prétendent que SWT est beaucoup plus rapide que Swing. A mon avis c'est totalement faux. Sous Linux ça se traine au moins autant et sous Windows c'est rapide certes mais Swing aussi.

        Au final, avec beaucoup de mémoire vive, Eclipse est tout à fait utilisable sous Linux mais un peu lent à réagir.

        • [^] # Re: Trop lent...

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

          Tout a fait d'accord en ce qui concerne SWT. S'il y a une difference de performance avec Swing, ca ne creve pas les yeux. Par contre Swing est beaucoup plus propre et une architecture plus elegante.

          • [^] # Re: Trop lent...

            Posté par  . Évalué à 3.

            J'ai jamais étudié SWT, donc je ne sais pas trop. Par contre ce que je trouve bizarre c'est que SWT provient d'IBM qui avait pourtant poussé la création de Swing, et donc influencé les choix techniques retenus alors.

            Il parait qu'il y a des changement avec le JDK 1.5 à ce niveau. Notamment ce n'est plus motif qui serait utilisé en dessous du toolkit AWT. Y en a- t'il qui ont essayé et remarquer des améliorations sur la réactivité?

            • [^] # Re: Trop lent...

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

              Mon avis c'est que SWT a surtout ete pousse par IBM pour des raisons politiques que pour autre chose. Si reellement IBM voulait faire avancer les toolkits graphiques de Java, il aurait du alouer ces resources pour ameliorer Swing ou alors faire passer SWT par le JCP. Ici j'ai vraiment l'impression qu'ils ont fait ca pour se demarquer, et a part embrouiller les choses ca n'apporte rien. Je trouve ca cretin de leur part ...

              Je n'ai pas encore eu le temps de tester le JDK 1.5, faudra que je fasse ca un de ces jours.

              • [^] # Re: Trop lent...

                Posté par  . Évalué à 7.

                Swing avec la JDK 1.5 est plus rapide qu'avec la JDK1.4.
                La JDK 1.5 permet également d'utiliser le pipline opengl (à activer par l'option -opengl). Pas forcément déterminant pour Swing mais intéressant pour faire des jeux.

                De manière assez surprenante les JDK 1.4 de Blackdown (pourtant directement dérivées de celles de Sun) sont nettement plus véloces pour l'affichage.

                > Mon avis c'est que SWT a surtout ete pousse par IBM pour des raisons politiques
                Effectivement et c'est d'autant plus surprenant que c'est IBM qui a fortement soutenu et investi dans SWING (développé en partie par l'ex taligent). Malheurement, à travers SWT -la qualité du produit n'est pas en cause-, IBM a reproduit la politique qui a pourri la vie des UNIX propriétaires pendant une bonne dizaine d'année.

          • [^] # Re: Trop lent...

            Posté par  . Évalué à 2.

            Sans trop me lancer dans un troll Swing vs SWT je pense qu'avec le recul la vitesse (réelle ou annoncée) n'est pas le principal avantage de SWT mais plutôt sa meilleure intégration avec le de l'environnement client : un appli SWT toujours le look & feel des autres applis alors que la première chose que l'on voit sur une appli Swing est qu'il s'agit d'une appli Swing.

            • [^] # Re: Trop lent...

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

              Essayes un peu avec les tous derniers JDK, le look'n'feel windows (je ne parle que de ce que j'ai vu) a été terriblement amélioré, et fait que désormais les applications Swing s'intègrent aussi bien que le SWT dans un bureau.

              • [^] # Re: Trop lent...

                Posté par  . Évalué à 2.

                Je confirme pour Windows. L'intégration est très bonne. Sous Linux il y a maintenant un look GTK. C'est pas mal même si ce n'est pas encore parfait. Ce look est sensé pouvoir utiliser le thème en cours de GTK mais il a pas l'air d'aimer le thème galaxy de ma Mandrake. D'autre part, si les polices pouvaient être lissées ça serait mieux.

                • [^] # Re: Trop lent...

                  Posté par  . Évalué à 1.

                  Sous Linux il y a maintenant un look GTK

                  J'avais effectivement lu qq chose sur le sujet. Cependant il me semblait que ce n'était pas le look par défaut et qu'il fallait faire qq chose dans le code pour qu'il soit activé.

                  Sinon ce qui me gène le plus est qu'il ne s'agit au final que d'une émulation des themes GTK ce qui doit être carrément compliqué à faire.

            • [^] # Re: Trop lent...

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

              Ce qui m'a fait migrer de NetBean (Forte) vers Eclipse, c'est la consommation des ressources,l'année dernière mon pov' portable (128 Mo de RAM) pédalait dans la choucroute avec Forte, et fonctionnait de manière fluide avec Eclipse 2.0. Mais depuis la 2.1, c'est kif-kif bourricot.

              Sauf que maintenant, j'ai l'impression que Eclipse est plus actif et a plus de plug-in que NetBean.

              Par contre, je ne veux pas apprendre SWT car ce toolkit a pour moi le même défaut qu'AWT : il dépend du toolkit de l'OS hôte, de sorte que je ne suis pas assuré de l'affichage de tous les caractères (par exemple éditer du texte UTF-8 avec du français et du Japonais dedans). Alors que je sais que c'est possible avec Swing, moyennant les fontes et la modification ad hoc du font.properties.

              De plus, l'intérêt du Java, c'est de pouvoir tourner sur toute plateforme *disposant d'un émulateur^W machine virtuelle*. Une application SWT impose d'avoir en plus une implémentation de cette librairie, avec le risque de ne pas avoir les mêmes fonctionnalités ou des incohérences d'une plateforme à l'autre.
              Swing étant entièrement codé en Java, on n'a pas (ou beaucoup moins) de problèmes.

    • [^] # Re: Trop lent...

      Posté par  . Évalué à 9.

      Si tu veux expérimenter la lenteur tu as sous os X. Est-ce la machine (800 Hz)? En plus je m'emmele avec le clavier les pomme+S pour sauver Mais pomme+fn+f6 pour le changement de fichier, et je vous passe toutes les incohérences des raccourcis clavier.
      Sous Linux, je l'utilise (pas encore assez à mon goût) avec window maker +jvm 1.4+512Mo ça tourne bien, Mais pas avec gnome ou kde. ceci dit c'est vrai (ça me désole aussi) rien ne vaut windows pour eclipse.
      Pur moi, un éditeur de texte doit aller à la vitesse de la pensée. (vous comprendrez que mon petit test de neat-bean a été assez.. burlesque?).
      Il reste qu'avec la vitesse croissante des machines de bureau, même avec une machine de 2e main actuellement, et avec un peu de mémoire, je pense qu'on peut utiliser eclipse et java et resin ou tomcat. Mais mozilla en plus bon.. lancer mozilla avec modération.
      (En tapant cela je réalise combien cela doit paraître délirant aux non-javaistes. J'ai eu l'impression que la gourmandise proverbiale de java en mémoire était une anticipation de la montée en puissance des machines)

      • [^] # Re: Trop lent...

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

        C'est lent sous OS X ? J'avais toujours entendu dire que l'implementation OS X de Java etait excellente. Faudra que je teste un jour ;-)

        • [^] # Re: Trop lent...

          Posté par  . Évalué à 4.

          SWT est lent sous OS X. En revanche l'implémentation AWT/Swing d'Apple est plutôt satisfaisante.

    • [^] # De tout temps ...

      Posté par  . Évalué à 7.

      ... les IDE ont été lents et on nécesité une config musclé, c'est pas nouveau, et cça n'a rien à voir avec tux ou java, meme pour VS c pareil (ou vraiment pire encore pour la derniere version VS).

      Tu veux pas faire du Java, c toi que ça regarde ... mais essaye de lancer un IDE digne de ce nom sur ta machine et on en reparle ensuite ;-) Et non vi, emacs & co c'est pas des IDE dignes de ce nom :D (vilain troll pas beau)

      Au fait, les trolls sur la rapidité de Java, ils ont été "exterminés" depuis longtemps alors tu retardes d'un sciècle :o) Voir les derniers débats sur slashdot...

      Bon plus serrieusement, tux souffrait d'une PB, la faiblesse des performances de ces thread (l'overhead qu'il leur applique et tout bonnement démesuré !), mais avec le kernel 2.6 arrivent des thread tout beaux :D Pkoi tant de haine ? Tout simplement, Java utilise un max le multi-thread, d'ou un overhead max sur tux, et une différence de perf en multithread avec winxx ou d'autres OS (sous condition d'utilisation d'un JIT identique).

      Enfin je rapelle que si tu lance la VM, il y a deux modes : en mode "serveur" (optimisation maximum, mais temps de lancement tres long) ou en mode "client" (lancement plus rapide, mais optimisation moindre). C'est encore plus flagrant avec les optim du JDK 1.5 !

      Au fait, refuser le débat et avoir des préjugés, ce n'est pas bo ;-)
      (pire encore quand il s'agit d'un vilain troll tout vilain)

      Java est déjà une techno incontournable dans un CV, et elle est présente sur bon nombre de projet dans les monde de l'entreprise. Viendra un jour ou comme tout autre techno Java sera eclipsé par une nouvelle génération de concepts.

      Perso, je dirais bien que la prochaine revolution sera ptet plus du coté du stockage de donnée ... (je suis le seul à trouver débile l'utilisation en 2000 de SGBD/R alors que tout le reste du monde est passé à l'objet ?)

      Qui vivra ... codera.

      • [^] # Re: De tout temps ...

        Posté par  . Évalué à 8.

        Désolé, c'est mon premier post et je ne trouve pas comment recopier le texte original (marche pas sous Mozilla)

        A propos de la rapidité de Java : le dernier troll sur Slashdot n'apporte rien de neuf. A l'heure actuelle des tests *fonctionnels* écrits en Java vont aussi vite que du C++.

        Mais du C++ optimisé (c'est à dire en utilisant par ex l'allocation sur la pile, en évitant les créations inutiles d'objets, etc) reste plus rapide que du Java.
        Tout simplement parce que la librairie de classe de Java créé beaucoup d'objets intermédiaires. C'est propre mais lent.

        Ceci rend également Java non prédictible. Dans le domaine des telco où je travaille, Java n'est pas utilisé pour gérer des serveurs avec des contraintes de temps fortes par exemple. (mais il y a des versions spécifiques des JVM pour le temps réel)

        A propos des threads : Java n'utilise pas massivement les threads. L'architecture J2EE les utilise par contre beaucoup. Le problème des anciens noyaux était:
        1) le coût de création du thread car sous Linux un process et un thread c'était la même chose
        2) le coût de changement de contexte sur des opérations impliquant les mutex

        Ceci n'est un frein que si on crée et détruit de très nombreux threads et si les mutex sont massivement utilisés. Là encore, en Java pur ça n'a aucune importance. En J2EE c'est important, mais uniquement si les clients J2EE sont codés avec les pieds, c'est-à-dire s'ils créent et détruisent de nouveaux EJB
        sans arrêt, au lieu de garder une référence de session bean et ne pas exposer
        l'aspect interne de l'application.

        Pour en revenir à Eclipse, puisque il s 'agit du point de départ, je l'ai essayé...
        Et laissé tomber tout de suite. L'interface est inutilisable de lenteur
        et les fonctionnalités offertes ne m'ont pas convaincu. Je suis plus efficace avec
        emacs ou gvim :-)

        • [^] # Re: De tout temps ...

          Posté par  . Évalué à 10.

          Je suis plus efficace avec emacs ou gvim :-)

          Ouhaw .. bravo, je ne sais pas comment tu fais pour être plus efficace avec Emacs/Gvim par rapport à Eclipse, si j'étais méchant (ce que je ne suis pas) je dirais que tu ne sais pas te servir d'un clavier (ce qui parait bizarre si tu utilises Emacs) ou alors tu n'as écrit qu'un Helloworld sous Eclipse !!! :).

          J'ai très, très longtemps utilisé Emacs pour coder (Perl, C, C++, Java et Ruby principalement), j'ai même finit par acquérir une certaine dextérité poulpesque et éléphantesque (par rapport au nombre de combinaison de touche que j'ai appris). Puis vient l'heureux jour où je teste Eclipse pour réaliser un TP de stéganographie (utilisant JAI). Prise en main un peu difficile pour comprendre comment marchait la notion de projet dans cet IDE, puis quelques galères pour taper mon code (le temps de choisir le binding emacs dans les options :) ... et ensuite que du bonheurs : complétion sémantique des noms de méthodes, génération de try/catch/throws, aide à l'écriture des structures for/while..., visualisation instantanée des erreurs syntaxiques (oubli de gestion d'exception), debug bien foutu, génération des getter/setter, des délegations et tous les outils de refactoring (où Emacs peut toujours s'accrocher avec ces query/replace) ... et j'en passe ... des tas.

          Pour la réactivité de l'interface il y a effectivement une grosse différence entre Windows et Linux (j'ai pas vérifié avec les derniers JDK et Eclipse) ... mais il n'y a rien de rédhibitoire à mon avis, j'ai commencé sur un Pentium 3 900Mhz à 128 Mo de RAM et c'est vrai que c'était un peu lourd sur de gros projet mais actuellement sur un Pentium 4 2Ghz à 256 Mo de RAM je ne sens pas trop de problème. Bien sûr les menus sont assez "long" à s'afficher, mais bon, si tu es habitué à Emacs, tu dois bien imaginer qu'on ne les ouvre que très rarement.

          Je veux bien admettre que le temps de frappe pur (sans complétion automatique) est plus rapide sous Emacs (encore que je n'ai jamais pris le buffer de frappe clavier en défaut sous Eclipse), mais si tu prends ensuite le temps de compilation en compte et le nombre d'erreurs détectées par Eclipse à la volée, le gain de temps sera du coté d'Eclipse.

          Enfin, depuis que j'utilise Eclipse, je passe beaucoup, beaucoup moins de temps à me taper de la Javadoc sur mon navigateur préféré.

          Voila, Emacs a toujours ma préférence pour le scripting ou la retouche rapide de fichier mais pour du codage de plus grande ampleur (sans pour autant être des projets énormes) je préfére largement l'utilisation d'IDE tel qu'Eclipse. Ça n'engage que moi, tu fais ce que tu veux pour coder, mais la phrase que j'ai souligné au début de ce post m'a définitevement poussé à rentrer dans le troll :). Tous les arguments citées valent exclusivement pour du codage Java (je n'ai pas essayé CDT depuis longtemps).

          • [^] # emacs c'est bien

            Posté par  . Évalué à 2.

            Je crois que tu n'as jamais essayé emacs avec ECB+XREF (ou ECB+JDEE).
            La puissance est équivalente à Eclipse ou Netbeans en terme de complétion, etc. avec la légèreté d'Emacs en plus.

        • [^] # Re: De tout temps ...

          Posté par  . Évalué à 4.

          Mais du C++ optimisé (c'est à dire en utilisant par ex l'allocation sur la pile, en évitant les créations inutiles d'objets, etc) reste plus rapide que du Java.
          Certes oui, mais au niveau maintenabilité et évolutivité du code, c'est incomparable... Et les optimisations de code C++ t'apportent quoi, une exécution 10 ou 20% plus rapide ?
          Bref, c'est pas toujours rentable, ça dépend des projets (sinon on coderait tous en assembleur).

          • [^] # Re: De tout temps ...

            Posté par  . Évalué à 3.

            En optimisant correctement ton C++ tu peux avoir des gains allant jusqu'à 200% voire plus (dès que l'on touche à des fonctions natives du système). Pour 20 ou 30% çe ne serait pas très intéressant :-)

            Quand à la maintenabilité et évolutivité du code, si ton C++ est correctement écrit ça ne pose pas de problèmes. (Evidemment c'est
            le 'si' qui pose problème, C++ étant très permissif).

            Je suis d'accord, ça dépend des projets. Par exemple, pour du serveur d'application, Java est à sa place (ou dans des applets).

            Par contre, développer un soft de traitement d'image en Java...

            • [^] # Re: De tout temps ...

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

              je developpe un jeu en java (opengl) je manipule pas mal de textures, je vois pas le problème.. faut qe je retourne au C++, java c'est vraiment trop un nid à troll ;)

        • [^] # Re: De tout temps ...

          Posté par  . Évalué à 3.

          Mouhais...je développe 3 projets java en ce moment, donc un bien gros, et bien sale (je le reprend en fait)...

          La valeur ajouté d'eclipse est inestimable, surtout les fonctions de refactoring, et de navigation dans le code (recherche de déclaration ou de références)...

          on parlera également de l'intégration parfaite à ant et junit, et là on tient un truc génial...

        • [^] # Re: De tout temps ...

          Posté par  . Évalué à 2.

          De toutes façon, à part IDEA (payant) et peut être forte (lourd), eclipse est incontournable pour faire de gros projet en java. Outre l'intégration avec ant et jalopy il y aussi la possiblité d'exécution pas à pas sur un serveur d'application (testé et approuvé avec weblogic : c'est g-é-n-i-a-l). Le temps gagné grâce à cette fonction est inestimable.

          De plus, il ne faut pas juger, à mon sens, une IE uniquement sur la lenteur de déroulement de ses menus.

          Uitiliser des menus est, de toute façon, une manière lente de faire: choppage de la souris, déplacement de la souris, click, choix dans le menu, re-click, puis éventuellement retour au clavier pour compléter la commande.

          Eclipse, comme IDEA d'ailleurs, permet l'utilsation à outrance des raccourci clavier qui se montre vite, très vite, redoutablement efficace.

      • [^] # je plonge

        Posté par  . Évalué à -10.

        Java est déjà une techno incontournable dans un CV,

        t'es un goret!
        si je vois java dans le cv d'un pioupiou qui pointe son nez
        je me méfie voire le dégage aussitôt !

        perdre son temps sur une interface à bouton instable
        est un non-sens à notre époque.

        n'importe quelle personne sensée dira que la productivité
        passe par une suppression des interfaces graphiques,
        de cette souris et de ses clicks!

        et elle est présente sur bon nombre de projet dans les monde de l'entreprise.

        rédac'chef chez 01prout ?
        non ?!

        envoie leur ton cv t'as toutes tes chances

        Viendra un jour ou comme tout autre techno Java sera eclipsé par une nouvelle génération de concepts.

        il y a bien longtemps que java a été éclipsé s'il y avait quelquechose à éclipser (he'he'), si on regarde du côté de perl, php, ruby, python, etc : il n'a aucune chance avec sa non-liberté, ses instabilités, sa lourdeur, même si son ide est très beau et sponsorisé par HAL.

        l'avenir est à la console texte en environnement distribué

        ps: si vous n'avez que java dans votre cv, apprenez autre chose, ça suffira jamais pour manger longtemps.

        • [^] # Re: je plonge

          Posté par  . Évalué à 3.

          Il y a pourtant beaucoup de demande de developpeurs java, en suisse
          par exemple, et là je peux te dire que tu as de quoi manger ...

          Seul java à été retenu dans mon CV... malgré la ribambelle de langages que je
          connais, voir même que je connais beaucoup mieux..

          On est dans un monde ou il faut s' adapter au moment, et en ce moment
          pour les decideurs pressé, c' est java ou C# (fortran/cobol dans les banques).

          Grace à java je mange avec du blé gracieusement offert par la croix blanche sur font rouge... Dois-je arreté le java ?

          Si tu pense être plus rapide avec des 'cat' ou des 'ed' pour coder du java, rien ne t' empeche de le faire, maintenant il ne faudra pas être surpris de voir ton gosier se vider par manque de productivité.

          Une interface graphique qui te fais gagner du temps et une interface bien conçu avec de bon raccourcis clavier, de la souplesse au niveau de son organisation, de sa présentation, des outils et surtout un bon utilisateur curieux qui prend le temps de l'explorer et de l' exploiter. Eclipse est pas mal à ce niveau....
          Voila !!

    • [^] # Re: Trop lent...

      Posté par  . Évalué à 7.

      Moi je l'utilise sur un potable PIII 1GHz avec 256 Mo de RAM et je m'en sort tres bien.
      C'est pas super reactif c'est vrai, mais c'est plus qu'utilisable.
      En tout cas, ce n'est pas plus lent qu'un Visual Studio ou un Delphi 8.

      Par contre coté fonctionnalité, c'est du pur bonheur.
      Tout ce que je demande a une EDI est là, on passe biensur la coloration syntaxique mais on trouve reformatage du code, génération des tag javadoc et de la doc, integration de JUnit pour les test unitaires et des dfonction de refactoring de code plutot bien foutues

      • [^] # Re: Trop lent...

        Posté par  . Évalué à 2.

        au boulot je suis sur un Cel 2000 + 512 de ram...et c hyper correct...

        J'ajoute à ce que tu dis qu'en plus, avec les outils Jakarta, tu peux vraiment déployer tes projets rapidement...

        avec Ant ou même Maven, tu automatises tt le processus...c'est assez grandiose....

    • [^] # Re: Trop lent...

      Posté par  . Évalué à 4.

      Je l'utilise sur un portable (PIII 700MHz avec 128Mo de RAM).
      Pas de problèmes particuliers de lenteur. Ceci dit je n'ai pas essayé sur de gros projets.

  • # Eclipse Goes Native+ Java Open Source

    Posté par  . Évalué à 6.

    Petite information en passant:
    RedHat vient de créer une version
    native de Eclipse
    http://www.application-servers.com/links.do?reqCode=showLink&li(...)
    http://www.linuxjournal.com/article.php?sid=7413(...)
    it "runs natively using the libgcj runtime libraries, similar to the way a C program runs using the GNU C libraries."
    "The approach we took involves using GCJ to compile Java bytecode to native machine code."
    "The achievement of the native compilation of Eclipse is a strong indication that open-source Java based on GCJ and libgcj/classpath has reached the point of being commercially useful. "
    Comme quoi une implémentation open source de java est crédible.
    Reste à travailler le JIT Compiler Et Swing.

  • # Sortie *officielle* d'Eclipse 3.0

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

    L'annonce est dispo sur le site :
    http://www.eclipse.org/(...)

    Pour la liste des news :
    http://download2.eclipse.org/downloads/drops/R-3.0-200406251208/ecl(...)

    Par contre pas la peine de télécharger, je dépasse pas les 30 Ko/s, et aucun des miroirs n'est encore mis à jour avec cette version estampillée 3.0 finale.

    Tips :
    Il s'agit de build d'intégration 200406251208 qui a été promu 3.0 donc il y a peut-être moyen de le trouver sur un miroir.

    • [^] # Re: Sortie *officielle* d'Eclipse 3.0

      Posté par  . Évalué à 4.

      On y trouve tout plein de bonnes choses !

      Les Vues nouvelles (JavaDoc, Declaration, CVS...)
      La réactivité de l'IHM (barres de progression détaillées pour la compilation, la synchro CVS).
      Expressions rationnelles dans les Chercher/Remplacer.
      Signalement des erreurs Ant à l'édition.
      Un mode 'Quick Fix' dans l'éditeur qui permet de proposer une liste de suggestions en cas de problème (insertion de try/catch autour d'une exception, création de méthodes/arguments...)
      Refactoring bien amélioré (création de méthodes et attributs, recherche/remplacement de code en double...)
      Signalement des fragments de code non nécessaires (Exceptions non générées, cast inutiles...)
      Nouveaux éditeurs pour la création de plugins.

      En plus d'autres bonnes choses :)

    • [^] # Re: Sortie *officielle* d'Eclipse 3.0

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

      > Par contre pas la peine de télécharger, je dépasse pas les 30 Ko/s,
      > et aucun des miroirs n'est encore mis à jour avec cette version
      > estampillée 3.0 finale.

      Bon, à priori la maj des miroirs s'est faite cette nuit. Le dl sur objectweb fonctionne très bien. Par contre je n'ai pas trouvé de Language pack comme avec la V2. Est-ce qu'il est maintenant inclus?

  • # Torrent

    Posté par  . Évalué à 7.

    Des trackers bitorrent pour :

    eclipse-SDK-3.0RC3-linux-gtk.zip
    eclipse-SDK-3.0RC3-win32.zip
    eclipse-SDK-2.1.3-win32.zip
    swt-3.0RC3-linux-gtk.zip

    sont disponibles à cette adresse :

    http://eclipse-mirror.jab.fi:6969/(...)

  • # Pour dompter le tigre ...

    Posté par  . Évalué à 2.

    La nouvelle version de Java2 Standard Edition (de son nom de code "tiger"), devrait sortir en version finale dans les semaines qui viennent ...

    D'ailleur au passage, je ne saurrais que trop vous conseiller de tester vos appli avec les toutes dernières build qui sont disponibles sur http://java.sun.com/j2se/1.5.0/snapshots/(...)

    Celà permet de se rendre compte des perfs obtenues et en cas de pépin de reporter le bogue au plus vite afin qu'il soit corrigé avant la version finale.

    Dans cette nouvelle mouture, il y a tellement de nouvelle fonctionalité que la tête peut en tourner. Parmis tout celà, les nouvelles fonctionalités du langages tant attendues, telle la généricité ... le site http://www.3plus4.de/eclipse/cheetah.html(...) (en anglais mais avec des zimages!) explique pas à pas comment faire bénéficier eclipse 3.0 des toutes dernieres avancées du langage.

    On espère la version finale de cette mise à jour majeure de la JDT Eclipse pour bientôt ;-)

    Vive le J2SDK 5.0 ... j'ai dit 5.0 ? tiens comme c'est bizare ;-)

    • [^] # Re: Pour dompter le tigre ... NON ! la guenon

      Posté par  . Évalué à 1.

      C'est pas cheetah le nom de code de Java 1.5 ?

      Tu n'aurais pas un mac, et confondrais avec la nouvelle version de Mac OS X, qui elle
      s'appelle Tiger ?

      Trop de release tue la release

      • [^] # Ben non ;-)

        Posté par  . Évalué à 1.

        Pour les noms de singe, Sun laisse ça à d'autres ;-)

        Cheetah est le nom de code de la future version d'éclipse qui supportera les fonctionalités de tiger.

        T'es sur que t'as regardé sur la page :

        http://java.sun.com/j2se/1.5.0/snapshots/(...)

        Si tu vois une guenon, cours vite voir ton ophtalmo ... ou ton psy :))

        Plus serieusement, je pense que le nom de code du 1.5 (tiger) est antérieur au choix de Apple. Mais faudrait creuser ce point.

        Sinon, j'ai pas de Mac OSX, mais si tu veux m'acheter une pomme portable 17" écran large, je veux bien en avoir un :))

        • [^] # Aller tant qu'on y est ...

          Posté par  . Évalué à 0.

          Dans la série des choix stupide de nom, je pense que mozilla à la palme.

          Non content d'avoir vampirisé le nom de "Firebird" l'excelente base de données opensource, ils utilisent comme nom de fichier l'extension .jar qui est le format des librairies et executables Java !

          Si qqn peut me dire pourquoi les extensions de Mozilla sont nommés .jar ça m'interesse ... du coté de Java le .jar existe depuis des lustres, c'etait à l'epoque du JDK1.2 ( et .jar pour Java ARchive tout simplement). Merci ;-)

          • [^] # Re: Aller tant qu'on y est ...

            Posté par  . Évalué à 1.

            Si qqn peut me dire pourquoi les extensions de Mozilla sont nommés .jar ça m'interesse

            Un .jar désigne une Java ARchive qui est un un poil près le même format que les .zip (d'ailleurs on peut sans problème ouvrir un .jar avec unzip). Les bibliothèques et les exécutables java ne sont que de bêtes archives (d'ailleurs il est possible de mettre des .class dans un .zip sans que cela pose de problème à Java) avec une ch'tite ligne dans un fichier spécifique permettant de préciser la main class pour les exécutables.

            Bien que le format .jar soit utilisé principalement par Java rien n'empêche d'y stocker autre chose que des .class.

            • [^] # Quelques précisions

              Posté par  . Évalué à 2.

              Un .jar est une archive zip.

              La différence avec un autre fichier zip, c'est que le contenu stocké dans l'archive doit respecter une structure de repertoire propre à java pour le stockage des binaires ainsi que le fichier de description.

              |- META-INF/MANIFEST.MF // données de lancement automatique
              |- com
              -/monentreprise
              -/monapplication/
              - MaClass.class // binaires stockés selon le schéma de nommage des packages java
              |- autres // stockage des ressources ( tout et n'importe quoi ) de n'importe quelle maniere

              Si ces points sont respectés, alors l'archive zip est un jar qui peut
              etre lancé en ligne de commande grace à la commande java -jar monjar.jar

        • [^] # Re: Ben non ;-)

          Posté par  . Évalué à 2.

          D'un autre coté, cheetah ça veut dire guépard...

  • # Et python

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

    ESt ce qu'il y a un plugin python ?

Suivre le flux des commentaires

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