Arf j'ai eu un doute un instant en lisant natif. Tu voulais bien sur dire natif java, mais souvent en java on dit souvent natif pour du code non java justementEnvoyé par GrandFather
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Arf j'ai eu un doute un instant en lisant natif. Tu voulais bien sur dire natif java, mais souvent en java on dit souvent natif pour du code non java justement
pour moi un avantage de Java est qu'on n'a pas besoin de recompiler sur chaque plateforme, recemment professionnellement j'ai eu a deployer une petite appli sur un gros server productif solaris et ou seul Java etait autorisé.
(d'ou par ailleurs un grand avantage au drivers type 4, c'est beaucoup plus facile a deployer)
Mouais, enfin je crois pas que la recompilation en soi soit un problème (si c'est juste faire une ./configure && make && make install, je vois pas trop ou est la difficulté.) Au mieux cela t'économise le temps de la compilation.
Ben faut croire que c'est pas si simple a faire puisque Java a été inventé.
Pis ton ./configure, ton make, et make install ca marche pas trop sous Windows par exemple, faudra donc tout adapter pour que ca fonctionne sous Windows aussi
Pis tu dois avoir d'autres OS avec leurs variantes. Et bien entendu tout ca nécessite que tu distribues tes sources ce que tu n'as pas toujours envi de faire
C'est pas si compliqué que ça non plus. Maintenant, si tu ne veux pas distribuer tes sources, tu créé un fichier compréssé avec les binaires et éventuellement un script ou un programme d'installation. Pour le déploiement, perso je ne vois la différence. (entre copier un fichier .jar ou décomprésser un fichier, dans les 2 cas c'est juste l'affaire d'une ou 2 minutes).
Le plus dur en fait réside dans le fait que tu dois posséder une machine pour chaque OS que tu vises afin d'être en mesure ce créer les binaires.
PS: je vois juste d'aller faire un tour sur le site du driver JDBC pour postgres donné en exemple plus haut, dans la partie download. J'avoue y avoir trouvé une jolie matrice ou l'on peut choisir le fichier que l'on doit télécharger en fonction de sa version de postgres mais aussi, en fonction de la version de java que l'on utilise.
Moralité: Java ne résout pas tout les problèmes à ce niveau, loin de là.
Tu n'est pas obligé d'avoir une machine/OS pour chaque cible puisqu'il est possible de faire de la cross-compilation...
Mais cela ne change rien au fait que tu dois gérer plusieurs versions selon l'architecture/système alors que tu peux t'en contenter d'une seule avec Java (mais il faut avouer que le même problème survient lorsqu'on utilise des librairies natives en Java).
Ce n'est pas le même problème : il s'agit pas de version différentes selon l'architecture ou le système, mais des différentes évolutions des spécifications. Il suffit de choisir la version "minimum" de compatibilité ascendante : un driver JDBC 1.0 pour le JDK 1.1 fonctionnera avec une machine virtuelle plus récente...PS: je vois juste d'aller faire un tour sur le site du driver JDBC pour postgres donné en exemple plus haut, dans la partie download. J'avoue y avoir trouvé une jolie matrice ou l'on peut choisir le fichier que l'on doit télécharger en fonction de sa version de postgres mais aussi, en fonction de la version de java que l'on utilise
Moralité: Java ne résout pas tout les problèmes à ce niveau, loin de là.
a++
J'ai trouvé un mega gros default a Java...
Peut-etre et j'espere vous allez me dire que j'ai tort ...
ces deux derniers jours, avec deux programmes differents, je me paye un out of memory. si je l'augmente avec java -Xms256M ca tourne
mais diable pourquoi est-on obligé de specifier la memoire que l'application est suceptible d'utiliser ?
en c++ par contre aucun probleme !!!!
sans doute parce que C++ ne tourne pas dans une machine virtuelle...
le principe d'une sandbox est de brider le programme qui tourne dedans afin d'offrir plus de sécurité au système... cela vaut aussi pour la mémoire maximale que peut consommer le processus (ce serait gênant si une applet se mettait à consommer tellement de ressources que plus rien ne tourne)
et tu trouves cela normal ?sans doute parce que C++ ne tourne pas dans une machine virtuelle...
le principe d'une sandbox est de brider le programme qui tourne dedans afin d'offrir plus de sécurité au système... cela vaut aussi pour la mémoire maximale que peut consommer le processus (ce serait gênant si une applet se mettait à consommer tellement de ressources que plus rien ne tourne
c'est au systeme de se garder assez de resource pour etre reactif ....
comment peut-on predire a l'avance l'occupation memoire de notre application ?
j'ai eu deux problemes ces deux derniers jours:
1. sur mon engine 3d, java a explosé parce que il devait manipuler 2 millions de points. apres plusieurs essais 512 Megas etaient bons
2. au boulot sur un server productif, java a planté ... demain je vais justement regarder pourquoi / comment / solution
et maintenant comment un utilisateur normal peut faire ?
il faut tout le temps le lancer avec 4Go de memoire pour etre tranquille ?
Oui c'est normal, comme l'a dit gorgonite le principe est que le langage est protégé. Et non ce n'est pas au système de se protéger, d'ailleurs il ne le fait pas. Il est très déconseillé de lancer tes programmes avec 4 Go de ram en java, parce que ca va pas inciter le garbage collector a fonctionner et donc l'occupation mémoire augmentera peut être plus que nécéssaire, et la JVM ne rend pas la mémoire tant qu'elle ne s'arrête pas.
A noter que certaines JVM peuvent modifier leur utilisation mémoire, jRockit le fait je crois
he ben c'est pas pratique du tout ...
je n'aimerais pas dependre d'un programme qui peut lancer un out of memory alors que l'ordi est super-equipé ...
bon enfin puisque c'est normal ....
a+
pas d'accord, un systeme ne peut et ne doit pas planter pas parce qu'un programme demande trop de ressource.
mais comment font les utilisateurs de logiciels gourmands ?
comme photoshop / 3d studio etc ?
vous croyez que l'utilisateur va regler lui meme sa memoire en fonction de ses besoins ?
:-/
Ben quand un soft est mal programmé et se met a prendre 100% de CPU, ou utilise 12 Go de ram (j'exagère), ben effectivement ton OS répond plus en général et t'es bien emmerdé.
Dans le cas de photoshop oui l'utilisateur a intérêt a gérer sa mémoire, car par défaut il n'en utilise que la moitié et ne peut pas dépasser ce seuil. Donc t'as 4 Go de ram, et Photoshop ne pourra pas utiliser plus de 2 Go si l'utilisateur ne configure pas autrement
de memoire, l'utilisateur gere la memoire virtuelle sur le HD, mais pas la ram,
faudra que je verifie mais je ne pense pas.
Perso ce que je pense, c'est que l'utilisateur ne peut configurer la memoire de chaque application qu'il utilise. C'est au systeme de le faire.
[ca me rappelle le debat sur l'allocation memoire, peut-on laisser au programmer la responsabilité de la memoire ?]
Si si il gère aussi l'occupation en ram. Tu peux avoir 2 Go de ram, dès qu'il dépassera 1 Go il se mettra a swapper même s'il reste 600 Mo de libre. A moins qu'ils aient changé de méthode mais d'après ce qu'on m'en a dit ils ont pas changé
j'ai verifié :-)
t'as raison !
pour etre honnete j'avais hesité a repasser sur Java,
mon dernier projet était du java avec une database embarqué (H2), et franchement super bien.
mais apres plusieurs tests sur mon engine 3d en comparaison avec le C++, j'ai un facteur 2.3 alors bof apres reflexion et plusieurs out of memory, je reste en C++ !
a+
Effectivement Java n'est peut être pas adapté a tout. Par contre comment as tu fais les tests ? Tu n'avais pas développé ton moteur 3d en Java pour comparer j'imagine. Tu passais par JNI ?
je suis bien d'accord avec toi
le fait de préférer tel ou tel langage pour des raisons de gout ne se discute pas, mais pour le reste il faut bien dire qu'il n'y a pas photo lorsque l'on developpe de 'vraies' applications, les faits parlent d'eux-même et sont particulièrement tétus. Si Bouml utilise aussi peu de resources mémoire et CPU c'est aussi grace au couple C++ & Qt. La comparaison avec des modeleurs écrit en Java est particulièrement édifiante
S'il n'y a pas qu'un seul langage de programmation ce n'est pas pour rien, chacun à sa place quelque part et des domaines il est mieux adapté que les autres. Le problème ne se pose donc pas au niveau des langages eux-même, le problème se pose au niveau des utilisations inapropriées. Je ne vais donc pas utiliser C++ pour animer une page Web, et je ne vais pas utiliser Java pour le développement d'une grosse application ayant des contraintes de temps et mémoire comme un modeleur UML
Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour)
N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML
Tu as a moitié raison, certaines choses sont plus adaptées a un langage plutot qu'un autre. Mais le cas de l'UML est exactement le cas ou le C++ ne fait pas nécéssairement la différence.je suis bien d'accord avec toi
le fait de préférer tel ou tel langage pour des raisons de gout ne se discute pas, mais pour le reste il faut bien dire qu'il n'y a pas photo lorsque l'on developpe de 'vraies' applications, les faits parlent d'eux-même et sont particulièrement tétus. Si Bouml utilise aussi peu de resources mémoire et CPU c'est aussi grace au couple C++ & Qt. La comparaison avec des modeleurs écrit en Java est particulièrement édifiante
S'il n'y a pas qu'un seul langage de programmation ce n'est pas pour rien, chacun à sa place quelque part et des domaines il est mieux adapté que les autres. Le problème ne se pose donc pas au niveau des langages eux-même, le problème se pose au niveau des utilisations inapropriées. Je ne vais donc pas utiliser C++ pour animer une page Web, et je ne vais pas utiliser Java pour le développement d'une grosse application ayant des contraintes de temps et mémoire comme un modeleur UML
Effectivement Bouml est plus léger que la plupart des autres modeleurs UML. Mais faut aussi voir au niveau de ce qu'il peut faire. Et surtout, du point de vue des performances pures, ses concurrents sont plus lent et plus lourds qu'ils soient écrit en Java ou non. Donc dans ce cas précis ce n'est peut être pas le langage qui fait la différence.
Si énormément de soft UML sont écrit en Java, j'imagine que c'est pas juste parce que les éditeurs sont des idiots, et que finalement l'intérêt du C++ n'est pas si décisif que ca et que le choix est possible.
je me corrige un peu, ce sont des moteurs de calcul de trajectoire d'outil pour des machines fraiseuses à commandes numeriques. seulement du calcul donc avec beaucoup d'intersection rayon/triangle tangence sphere/plan etc.
Au final un fichier txt pour la machine a commande numerique.
et le but etait de comparer les deux languages pour un cas concret.
D'apres mes tests, Java explose en utilisation memoire, et je dirais c'est le plus gros probleme, ensuite vient la rapidité de calcul. Java ne tient pas vraiment la charge quand il y a beaucoup de points et/ou un gros model.
a+
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager