Articles précédents : Logiciel
- [56] Sortie de WineX 4.0
- [20] xdTV 1.9.2 "Keuleu" est sortie : que fait donc ce petit logiciel ?
- [16] Formsess, pour les formulaires et les templates
- [33] Skype pour Linux !
- [18] Glom : une interface pour PostgreSQL
- [82] Sortie d'OpenOffice.org 1.1.2
- [8] POV-Ray 3.6.0 disponible !
- [13] Un petit tour d'horizon des logiciels d'astronomie sous Linux
- [76] Les ISO de SuSE 9.1 version personnelle sont enfin disponibles...
- [140] Ça bouge du côté de SQLite !
Liens connexes
- L'annonce (3386 hits)
- Liste des miroirs pour le téléchargement (3651 hits)
- Plugins eclipse (3395 hits)
- Nouveauté d'Eclipse 3.0 (1616 hits)
- Eclipse.org (2015 hits)
Dépêche modérée par
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.
L'annonce (3386 hits)
Liste des miroirs pour le téléchargement (3651 hits)
Plugins eclipse (3395 hits)
Nouveauté d'Eclipse 3.0 (1616 hits)
Eclipse.org (2015 hits)
> Lire la suite (86 commentaires, moyenne: 4,1). [dépêche : 1248 caractères]
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 :)
Euh....
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)
-
[^]Re: Euh....
Posté par Roger Rabbit () le 22/06/2004 à 14:01. (lien). Évalué à 14.Dans le premier lien il est indiqué
>> Availability
>> Distributions of Eclipse 3.0 will be available by June 30 for download from
>> http://www.eclipse.org.(...)
C'est de la que je tiens la date de disponibilité de la 3.0 finale pour le 30 juin
-
[^]Re: Euh....
Posté par ninou () le 22/06/2004 à 14:10. (lien). Évalué à 8.2 petits liens qui donnent quelques infos supplémentaires dont la date pour la finale qui serait prévue dans la semaine du 28 juin :
http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0(...)
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/eclipse-pro(...)-
[^]Re: Euh....
Posté par yxorp () le 22/06/2004 à 16:11. (lien). Évalué à 5.http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0(...)
The 3.0 release is targeted for the week of June 28, 2004.
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/eclipse-project(...)
Release 3.0 - Goal: Ship Eclipse 3.0 during the week on June 28.
http://www.eclipse.org./org/press-release/jun212004r30pr.html(...) :
Distributions of Eclipse 3.0 will be available by June 30 for download from http://www.eclipse.org(...)
Donc, pas d'embrouillaminie, tout cela concorde : la sortie d'Eclipse 3.0 est bel et bien prévue pour le 30 juin... c'eut été un comble de voir un tel projet se ridiculiser en jouant sur des effets d'annonce ! :-)-
[^]Re: Euh....
Posté par Daniel Le Berre (page perso, ) le 24/06/2004 à 07:02. (lien). Évalué à 0.Je confirme que c'est la RC3 qui est dispo actuellement.
Il faudrait enlever cette nouvelle.-
[^]Re: Euh....
Posté par Daniel Le Berre (page perso, ) le 26/06/2004 à 11:06. (lien). Évalué à 8.La version finale est maintenant vraiment disponible.
(recu sur la mailing list de dev d'eclipse)
------------------------------------------------------------------------------
We are pleased to announce that Eclipse 3.0 is now available for download from http://eclipse.org/downloads/index.php.(...)
This drop is in the process of being propagated to the various Eclipse mirror sites, which usually takes a day or so.Due to the anticipated level of traffic, we strongly suggest that you download the drop from a mirror that is geographically close to you for a faster download.
For people who already downloaded the integration build with timestamp 200406251208, there's no need to download 3.0 - it's the same.
For further details, please refer to the new and noteworthy.
http://download.eclipse.org/downloads/drops/R-3.0-200406251208/ecli(...)
-
-
-
Vive les plugins
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 :)
-
[^]Re: Vive les plugins
Posté par gabuzo () le 22/06/2004 à 14:55. (lien). É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 Stéphane TRAUMAT (page perso, ) le 22/06/2004 à 15:45. (lien). É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.-
[^]Re: Vive les plugins
Posté par Sebastien Tanguy (page perso, ) le 22/06/2004 à 18:38. (lien). É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 VACHOR (page perso, ) le 22/06/2004 à 20:02. (lien). É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: log4j est pas terrible
Posté par Stéphane TRAUMAT (page perso, ) le 23/06/2004 à 07:58. (lien). Évalué à 2.Beh pour moi, log4j est génial :D
il est paramétrable et simple.. tout ce que j'attends pour faire du loggin
-
-
[^]Re: Vive les plugins
Posté par hachesse (page perso, ) le 23/06/2004 à 16:11. (lien). É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 gabuzo () le 23/06/2004 à 12:32. (lien). É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 Stéphane TRAUMAT (page perso, ) le 23/06/2004 à 16:03. (lien). É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.-
[^]Re: Vive les plugins
Posté par Laurent Mouillart (page perso, ) le 23/06/2004 à 18:24. (lien). É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 Daniel Le Berre (page perso, ) le 24/06/2004 à 06:54. (lien). É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
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 tgl () le 24/06/2004 à 11:53. (lien). É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.-
[^]Re: Plugin Ruby pour eclipse
-
[^]Re: Plugin Ruby pour eclipse
Posté par tgl () le 24/06/2004 à 18:51. (lien). Évalué à 5.Merci. En fait ça j'avais trouvé, mais le problème était l'intégration dans Eclipse.
J'ai finallement trouvé ça :
http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.cme/contri(...)
Si y'en a que ça intéresse, j'ai eu juste à copier les fichiers dans un repertoire /path/to/eclipse/plugins/org.apache.xerces_4.0.13, puis à ajouter dans le /path/to/eclipse/features/org.eclipse.platform_3.0.0/feature.xml une entrée adéquate :
< plugin
id="org.apache.xerces"
download-size="0"
install-size="0"
version="4.0.13"/ >
Je sais pas si c'était la bonne méthode (je connais pas eclipse en fait), mais ça à l'air de suffire pour faire marcher le plugin Ruby.
-
-
[^]Re: Plugin Ruby pour eclipse
Posté par Stéphane Brunner () le 25/06/2004 à 06:20. (lien). Évalué à 1.J'avais un problème du style et pour le résoudre j'avais simplement copier le plugin xerces depuis eclipse 2.x sur eclipse 3.0.
-
Plugin Tom pour Eclipse
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...
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 Antoine Büsch () le 22/06/2004 à 16:22. (lien). É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 Croconux () le 22/06/2004 à 18:07. (lien). É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 Benoît Sibaud (Jabber id, page perso, ) le 23/06/2004 à 07:30. (lien). Évalué à 7.Moving Java To Main (travail en cours autour du Java libre par Debian)
http://java.debian.net/index.php/MovingJavaToMain(...)
avec notamment des infos sur eclipse
-
[^]Re: Debs et RPMs d'eclipse...
Posté par Stéphane Brunner () le 23/06/2004 à 07:41. (lien). Évalué à 5.Le gros problème java (duquel dépend eclipse) sous linux est que la licaence de la machine virtuelle de sun interdit à d'autre entité de distribuer leur machine virtuelle -> mauvaise intégration dans debian par exemple !!!
S'est pour cela que le développement de SabreVM est important !-
[^]Re: Debs et RPMs d'eclipse...
Posté par José Araujo (page perso, ) le 23/06/2004 à 09:56. (lien). Évalué à 5.C'est plutôt sableVM (http://sourceforge.net/projects/sablevm/(...)) et SUN est en train de revoir ses license suite à des pressions de certaines 'grosses' entreprises !
-
[^]Re: Debs et RPMs d'eclipse...
Posté par Romain LE DISEZ () le 23/06/2004 à 11:23. (lien). Évalué à 1.SableVM a l'air d'être un projet intéressant.
Est ce qu'il permettrait d'obtenir un fonctionnement plus rapide des applications ou des applets écrient en Java ?
Et au niveau de la compatibilité, qu'en est il ?
Je n'ai pas trouvé d'info à ce sujet sur le site.-
[^]Re: Debs et RPMs d'eclipse...
Posté par Cook Captain () le 23/06/2004 à 18:31. (lien). Évalué à 5.Comme beaucoup d'autres VM libres, Sable VM utilise les librairies classpath.
Ce dernier projet est le plus important pour avoir un environnement Java libre. Le développement est trés actif et le projet est assez avancé pour pouvoir faire tourner une 'bête' comme Eclipse; cependant il manque un encore un gros "paquet" pour faire tourner la majorité des applications clientes sous Linux : Swing.
Pour info, Sable VM est constitué à l'heure actuelle que d'un interpréteur qui semble trés performant (et trés portable); un compilateur Just In Time est en cours de développement.-
[^]Re: Debs et RPMs d'eclipse...
Posté par tanguy_k (page perso, ) le 26/06/2004 à 12:53. (lien). Évalué à 5.> cependant il manque un encore un gros "paquet" pour faire tourner la majorité des applications clientes sous Linux : Swing
D'ou l'interet de SwingWT: http://swingwt.sourceforge.net/(...) C'est une re-implementation des widgets SWING en utilisant SWT et c'est plutot bien avance puisque toute l'API est implementee modulo les bugs.
http://forum.hardware.fr/hardwarefr/Programmation/sujet-53356-1.htm(...)
-
-
-
-
-
-
-
[^]Re: Debs et RPMs d'eclipse...
Posté par wismerhill (page perso, ) le 22/06/2004 à 16:28. (lien). É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 Vincent ZOONEKYND (page perso, ) le 23/06/2004 à 14:36. (lien). É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 Pothin Alain (page perso, ) le 22/06/2004 à 17:27. (lien). Évalué à 4.c'est aussi disponible dans l'arbre portage de gentoo...
-
[^]Re: Debs et RPMs d'eclipse...
Posté par Lastnico Nicolas Ternisien (page perso, ) le 23/06/2004 à 08:15. (lien). É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--
http://www.forum-software.org
Trouvez le meilleur logiciel de forum Internet pour votre communauté !-
[^]Re: Debs et RPMs d'eclipse...
Posté par Raphaël Gertz (Jabber id, page perso, ) le 23/06/2004 à 16:03. (lien). É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 le C, par rapport aux autres il est bien ?
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...
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 mrlag (Jabber id, page perso, ) le 22/06/2004 à 19:45. (lien). Évalué à 14.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).--
\_o<-
[^]Re: Trop lent...
Posté par ndesmoul () le 23/06/2004 à 08:16. (lien). É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 Nelis (page perso, ) le 23/06/2004 à 09:04. (lien). É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.
--
Vache qui rit, à moitié dans son lit-
[^]Re: Trop lent...
Posté par ndesmoul () le 23/06/2004 à 12:11. (lien). É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 Nelis (page perso, ) le 23/06/2004 à 12:30. (lien). É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.--
Vache qui rit, à moitié dans son lit-
[^]Re: Trop lent...
Posté par Cook Captain () le 23/06/2004 à 18:18. (lien). É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 gabuzo () le 23/06/2004 à 13:26. (lien). É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 Nicolas Delsaux (page perso, ) le 24/06/2004 à 07:47. (lien). É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 ndesmoul () le 24/06/2004 à 08:27. (lien). É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 gabuzo () le 24/06/2004 à 09:18. (lien). É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 David Sporn (page perso, ) le 24/06/2004 à 08:30. (lien). É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 Gabriel () le 22/06/2004 à 20:52. (lien). É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)--
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying-
[^]Re: Trop lent...
Posté par Nelis (page perso, ) le 23/06/2004 à 06:54. (lien). É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 ;-)
--
Vache qui rit, à moitié dans son lit-
[^]Re: Trop lent...
Posté par Cook Captain () le 23/06/2004 à 19:49. (lien). É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 Hive Arc (page perso, ) le 23/06/2004 à 09:30. (lien). É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 pognibene2 () le 23/06/2004 à 10:31. (lien). É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 pifou () le 23/06/2004 à 14:09. (lien). Évalué à 14.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 sircomsoft () le 28/06/2004 à 21:27. (lien). É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 Pierre Tramonson () le 24/06/2004 à 08:50. (lien). É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 pognibene2 () le 24/06/2004 à 11:09. (lien). É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 vrm (page perso, ) le 24/06/2004 à 13:26. (lien). É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 Julien Bidault (page perso, ) le 26/06/2004 à 12:27. (lien). É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 Calvin0c7 () le 27/06/2004 à 09:51. (lien). É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 B. franck () le 25/06/2004 à 08:42. (lien). É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 petit_bibi () le 28/06/2004 à 14:23. (lien). É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 hachesse (page perso, ) le 23/06/2004 à 11:05. (lien). É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 Julien Bidault (page perso, ) le 26/06/2004 à 14:39. (lien). É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 Pierre Tramonson () le 24/06/2004 à 09:17. (lien). É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
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.
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
-
[^]Re: Eclipse Goes Native+ Java Open Source
Posté par Pierre Tramo (page perso, ) le 25/06/2004 à 18:31. (lien). Évalué à 6.http://www.linuxjournal.com/article.php?sid=7413(...) : Posted on Thursday, July 01, 2004
Leur implémentation de IPOT, elle est native aussi ?
Sortie *officielle* d'Eclipse 3.0
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 Pierre Tramonson () le 26/06/2004 à 10:29. (lien). É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 Christophe Garault (page perso, ) le 26/06/2004 à 12:58. (lien). É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
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/(...)
-
[^]Re: Torrent
Posté par TazForEver () le 26/06/2004 à 14:54. (lien). Évalué à 1.ça n'est pas la version finale ...
-
[^]Re: Torrent
-
Pour dompter le tigre ...
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 Dreammm () le 28/06/2004 à 15:52. (lien). É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 Hive Arc (page perso, ) le 28/06/2004 à 16:14. (lien). É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 Hive Arc (page perso, ) le 28/06/2004 à 16:43. (lien). É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 gabuzo () le 29/06/2004 à 07:53. (lien). É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 Roger Rabbit () le 29/06/2004 à 08:05. (lien). É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 ;-)
-
-
Et python
ESt ce qu'il y a un plugin python ?
-
[^]Re: Et python
Posté par dannyboy () le 30/06/2004 à 08:13. (lien). Évalué à 1.Va faire un tour par là:
http://www.python.org/cgi-bin/moinmoin/EclipsePythonIntegration(...)
pydev ayant l'air plus avancé (http://pydev.sourceforge.net/(...) ).
quoi que trustudio a l'air pas trop mal non plus (http://www.xored.com/products.php(...) )
J'espère que tu vas trouver ton bonheur-
[^]Re: Et python
-




Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.