Bon c'était bien un problème de JVM, on dirait bien que ça ne plante plus

En passant j'ai... tout réinstallé En fait j'ai voulu mettre le plugin PDT (pour du php), et il nécessitait une version plus récente, or dans les packages ubuntu c'est encore la 3.2
Du coup j'ai tout refait de zéro, comme c'est une appli java c'est facile :
- download de la version eclipse prépackagée avec pdt dernière version stable (pdt 2.0, eclipse "ganymede" 3.4.1)
- dézippage et hop exécution et ça marche
- j'ai rajouté subclipse et pydev ensuite sans problème par la méthode classique (help > software update > ajouter une url etc.)
Et tout semble rouler

bli> Mon but est d'utiliser Eclipse aussi parce que c'est un standard de fait auprès de beaucoup de développeurs Donc je me "dois" de le connaître.

Pour l'instant ça a l'air stable avec la JVM de Sun, je reposte quand j'aurai eu l'occasion de le tester un peu plus intensivement que ces derniers jours.

OVh> si c'était mon topic, je suis pas sûr que j'aimerais cette intervention, mais as-tu essayé Kdevelop ? je sais que tu es un fan de XFCE et/ou code::blocks que j'aime individuellement pour plein de raisons, mais m'étant érigé un petit envirronement KDE, bien léché, j'ai vraiment pris goût à cet IDE et je l'utilise déjà pour quelques langages C/C++, PHP/HTML, TCL/Tk... Ma connaissance en Py s'étant à la lecture du HS de LinuxMagazine (qui malheureusement est plus philosophique que didactique...pour un débutant pure)

Bon, je n'arrive plus à retrouver l'article en question, mais je pense que j'ai trouvé où se trouvait mon erreur. Si me me souviens bien, l'article comparait les threads java avec la solution apporté avec Python 2.6 pour imiter les thread via les process (le module multiprocessing).
Mon esprit a du faire une confusion stupide parce qu'il reprennent justement l'API des thread mais appliqué aux process.
Mais du coup, ce n'est pas fair-play de comparer la consomation mémoire d'une seule VM avec n thread contre n VM avec 1 thread.

gizmo> n'importe quel développeur Python sait que l'utilisation des threads dans ce langage est à éviter, mais pas du tout pour la raison que tu dis (je me demande d'ailleurs où tu as entendu ça), mais parce que l'interpréteur a une "global interpreter lock" qui fait que les threads sont très limité en ce qu'ils peuvent faire en parallèle. Il vaut beacoup mieux travailer en multiprocess ou mieux encore, en asynchrone.

Alors, je suis sûr que tu es très compétent en beaucoup de choses, mais je répète que ce que tu dis sur les threads Python ne veut rien dire, ou est au mieux simplement faux...

gizmo > Et la charge cpu supplémentaire apportée par la gestion de ces nombreux threads ?

Ok, alors pour préciser plus: Pour une même unité de business logic, l'empreinte mémoire d'une série de thread python est plus importante que leur équivalent java. Donc ce que l'on gagne avec sur l'empreinte mémoire de la VM python, on le perd par la suite si on a un programme fortement multi-thread.

Je rajouterai que Ovh a pas tort au niveau "deploiement" quand on rentre dans les applications servers du style JBoss, Weblogic,...

Bien qu'encore une fois, ça commence tout doucement à s'améliorer (EJB vs EJB3).


C'est clair que c'est verbeux, mais cet inconvénient est largement oublié quand on voit l'élégance des API disponibles (et pas besoin de se lancer dans l'IoC, l'AOP etc ...). On fait déjà beaucoup avec le jdk.

Sauf que ce n'est plus vraiment vrai non plus

Ok, il a fallu que C# arrive pour que Sun nous sorte une syntaxe "new Brol<X>()" mais si on code bien, le typecasting n'est plus obligatoire car les collections (ou tout autre classe) peuvent être paramètrisées.

Java 6 Gizmo il a dit, pas Java 1 ou 1.2 ou 1.3 ou 1.4 ou ... 5

/me est content de coder en object pascal après tout

</pollution>