Reprise du message précédent :

j'avais ce genre de souvenirs aussi, d'où mon post.
mais bon, maintenant, je risque plus de parler de ce dont "je ne connais pas", vais faire l'impasse totale sur 90% des topics de ce forum, ça sera bien mieu. websphere s'est peut-être un peu normalisé depuis un an, mais j'ai de gros doutes à ce sujet (sinon je vois pas comment ils justifieraient un tel prix pour leur VM, vu qu'il y en a des plus performantes qui sont gratuites et plus officielles, celle de Sun par exemple). mais bon, à partir du moment où y'a marqué "java", c'est forcément 100% portable et 100% standard et de toute façon y'a que M$ pour se foutre des normes et des standard... n'oubliez pas que c'est IBM qui a lancé M$, comme on dit dans ma campagne, tel père tel fils.

 
tu t'enfonces

 
il y a une différence entre code et outils ...

Evidement. Ca change tout.
Je fais un truc standard qui ne fonctionne pas sur un truc standard. Bah oui, c'est parceque mon environnement n'est pas standard. Je vois pas très bien la différence d'un point de vue résultat. Faudra que tu m'expliques un jour.

ça ne te rappelle rien ?

à côté:
 
pour déconner j'ai fait le bench ADN en python
sur ma bécane,
javac + java = 9s, 12Mo de mémoire
python = 31s, 3.5Mo de mémoire
 
je trouve que c'est intéressant
 
 

 
ce que je veux dire c'est que si IBM essaye d'attraper des gens en fournissant des fonctionnalités en plus (tels qu'un accès direct au container, je ne vois pas très bien ce que tu veux dire par là, URL?) et bien OK.
 
Il n'empêche qu'étant certifié J2EE, Webpshere doit passer les tests avec une JVM non IBM. Ce qui est le cas vu qu'ils ont la certif. Donc si ca les amuse de fournir des trucs en plus pour que les utilisateurs utilisent leur JVM, bah qu'ils le fassent.
 
C'est différent d'un microsoft qui ne respecte pas les standards Java et qui redéfinit les trucs à sa sauce ...

ça revient exactement au même. à partir du moment où tu utilises les packages de websphere pour faire des java beans websphere, ça tournera que sur du websphere. donc c'est pas portable, point à la ligne.
évidement, si tu utilises websphere pour ne faire que des progs 100% standards, t'aura pas de problème. m'enfin là j'en vois plus trop l'intérêt.
 
tu sais peut-être que tu peux écrire du C++ compilable par un compilo C++ avec .NET Seulement, si c'est pour ne pas utiliser les packages de l'outils, faudra m'expliquer l'intérêt... bénéficier de l'IDE qui est très réussie ?

 
ben faire des progs qui se limite aux specs ca sert justement à être portable sur d'autres serveurs d'applications. Evidement, si tu utilises des spécificités de websphere, faut pas s'étonner que ca fonctionne pas bien sur web-logic  

Je précise que les développeurs Java sont pas plus crétins que les développeurs C, ils savent ce qu'ils font quand ils utilisent l'outillage de WebSphere.

jamais dis le contraire.
 
mais je sais plus d'où est parti le débat à l'origine (m'en vais relire), mais grosso-modo je me suis fait contre-dire (en faisant abstraction de toutes les péjorations accompagnant la contre-diction) alors que je disais qu'une appli websphere n'était pas portable (ou standard, je sais plus). l'un dans l'autre, ça revient au même de toute façon, l'un impliquant systématiquement et implicitement l'autre.

Voilà, j'avais écrit ça. J'avais d'ailleurs tourné de façon à mettre en valeur que je n'était pas certain de moi, et d'ailleurs la première phrase est fausse, du moins je l'espère, mais la seconde reste tout à fait vrai, surtout si on prends en compte le "écrit pour websphere", ce qui implique évidement l'utilisation des packages et spécificités de websphères, qui ne sont pas standards.

normal
 
une appli websphere n'est pas forcement développée en utilisant les spécificités websphere. Dans ce cas, elle est parfaitement portable ...

ouais, mais à ce moment là, le J++ aussi est portable. t'as troujours moyen de trouver les 3 instructions communes avec la norme et t'y limiter. franchement, dépenser 50 K? ou plus pour avoir WebSphere et pas s'en servir, faut avoir un problème neuronal là...

Ecoute, MagicBuzz, j'ai rien contre toi, mais lire ce que tu écris, c'est un peu comme se retrouver prof à corriger la copie d'un élève qui n'a rien compris au cours.
 
Tu sembles supposer que WebSphere n'est qu'un outil banal auquel sont greffées des fonctionnalités qui ne font pas partie de la défintion de Java.
 
Je ne vais pas te faire un cours sur WebSphere, je ne vais pas m'étendre sur la certification du produit, sur le load balancing, l'administration centralisée... D'autant que, après tout, qu'est ce que tu t'en branles de WebSphere, tu n'en fais pas du Java, ça te plait pas, tu n'y toucheras jamais profondément. Pour faire simple, WebSphere est un produit qui permet de déployer du Java avec une très grande robustesse. C'est, entre autres, ce qui fait qu'un décideur achète WebSphere.
 
Après leur hybride de JavaScript côté serveur, on s'en tape. Qui développe avec ?
 
Franchement, ce serait sympa de te cantonner à ce que tu connais et d'arrêter d'inventer des trucs sur des produits qui ne t'intéressent pas. ça m'évitera d'écrire des pavés.

et ça m'éviterait d'en lire 2x autant    
 
 
 

+2

 
Dans ma boîte, les décideurs n'ont jamais vu une ligne de code ni une machine autre que leur PDA, ou alors à l'époque des machines à feuilles perforées, et se basent uniquement sur l'avis du 01 Informatique et sur une recherche google pour acheter un produit. Ils n'achètent donc que chez les "leaders du marché". Quand ça coûte très cher et que c'est connu c'est forcément bien.
 
 
 
Le pire dans l'histoire étant que je n'exagère pas du tout.
 
Faut vraiment que je change de boîte...

Rares sont les boites qui raisonnent comme tu voudrais. Le porte-feuille achète les softs, mais ce sont les développeurs qui les utilisent. Seules quelques boites prennent le temps de faire évaluer les produits par leurs employés, parce que mine de rien, tester une demi-douzaine de produit, avec une appli test pas trop conne (histoire de toucher les limitations du produits), ça prend beaucoup de temps, et encore plus d'argent que faire comme 01 Informatique dit.

Enfin, c'est ce que croient la plupart des décideurs. Même si la plupart du temps, quand on impose aux développeurs un produit, ils ne sont pas formés à ce produit, or le temps de formation, difficilement incompressible, passe dans le temps de l'évaluation quand il y en a une. Et souvent, le produit en question ne convient pas parfaitement au besoin, et les développeurs doivent l'adapter. Or généralement, ils ne comprennent pas immédiatement la manière correcte pour l'adapter à leurs besoins, ce qui prend d'autant plus de temps...

Je partage entièrement ton point de vue Biface.

 
et moi ca m'évitera d'hésiter à dire quelque chose qui pourrait justifier mon ban

 
On voit bien la différence de GC : python marche avec un compteur de référence, chaque changement de pointeur nécessite un accès à l'ancien objet plus un accès au nouveau donc c'est très lent. Mais ça désalloue tout de suite donc en pointe ça consomme moins.
 
Java est (en général) un simple mark-and-sweep (étonnement peu sophistiqué d'après les docs d'IBM) qui n'influe pas sur la vitesse du programme quand il tourne, le programme est arrêté lorsque l'on veut désallouer, mais on le fait plus rarement (d'où plus de mémeoire consomée). À noter que l'on a le choix du ratio bouffage de mémoire/vitesse d'exécution avec ce système.

elle est pas la différence, le code python creer moins d'objet et j'ai jamais vu tourner le gc de Java ... la vm se ferme et voilà. le gc de python, c'est un vrai gc qui appelle __systématiquement__ l'opérateur surchargeable __del__ et pas comme cette perte de temps qu'est finalize. donc l'argument du gc est pas vraiment judicieux vu les fonctionnement differents. avec gc.disable(), le temps du script est similaire.
la différence vient du typage et de la compilation, ainsi que de l'exécution qui fait que Python est lent à l'appel de fonction (tout en étant un des plus rapides langages interprétés)

 
  t'as fait tourner quoi sur ton pc. Des hello world?

attends, avoue que le gc commence à s'exiter que quand la VM atteint une taille vraiment grosse

 
oui, et alors?

là ou python fait son boulot puisque qu'un objet non-référencé exécute un destructeur, là ou java se tourne les pouces. java ça me gave à cause de l'empreinte mémoire. vous aurez beau me dire, je connais rien d'autre qui bouffe autant
 
 
edit: et je sors, ça me gave tout ça

j'ai remarqué un truc marrant : j'ai un tomcat sur ma machine qui est pas très utilisé et apprès de long moment d'activité, le process ne prend plus que 2 Mo de mémoire    
(il est à 25 Mo au lancement)

Putain, mais c'est quoi ce nid à trolls ?
Eh les gars, pour ce genre de débat débile, y a le topic sur les langages hein... J'comprends pas qu'un modo ait pas encore fait le ménage là-dedans

on trolle pas, comparaison n'est pas raison, les contraires s'annulent, l'inverse n'est pas faux...

 
sinon, Taz, modifie la taille du heap au démarrage de la jvm à une valeur assez basse. On va voir si le GC se mets pas en route
 
c'est juste une question de design (perf) d'ailleurs ton test le prouve  

ouaip

Change de GC avec un java -X... (-X:incgc pour activer le GC incrémental, -XX:+UseConcMarkSweepGC pour activer le GC M&S concurrent, ou -XX:+UseParallelGC pour activer le GC parallèle). Et un -Xloggc:<file> logguera toute l'activité du GC choisi.

vous avez des bancs d'essais pour des applications de tous les jours / connues qui montrent les différences de performances / empreinte mémoire ?

ça ne change pas cet aspect du bench.
 
Par contre, changer les seuils de GC ça change ce que dit Taz (le seuil à partir duquel on lance le GC) ou Benou (la décroissance de l'espace avec l'inactivité, je ne sais pas comment ça se règle).
 
Taz : http://www-106.ibm.com/developerwo [...] -garbage1/

De mon coté fonctionnement de classes compilées sous NT ET Linux sans aucun problème ! C'est une réalité dans mon boulot en tout cas !!