Posté par barmic .
En réponse à la dépêche Fim 1.1.0.
Évalué à 10.
Aller je saute dedans...
Bien moins de problèmes de cohabitation. Je n'ai qu'une seule version installée sur Debian et tout un tas de logiciels tournent dessus.
Ou pas. C'est absolument trivial de choisir en temps qu'admin la version de Java que va utiliser une application. C'est l'histoire d'une variable d'environnement. En python tu va t'amuser entre ceux qui ont mis #!/usr/bin/python, #!/usr/bin/python2, #!/usr/bin/python3 ou #!/usr/bin/env python (ou python2 ou 3). Tu dois créer un virtalenv spécifique.
Le problème c'est que la machine virtuelle Java te harcèle pour te demander de confirmer sans cesse si tu veux exécuter l'application. Que ce soit un truc vieux ou récent.
Non, c'est uniquement si tu utilise l'installeur. Rien ne t'oblige à utiliser celui là et si tu es sysadmin je te conseil de ne pas l'utiliser et de lui préférer l'archive à décompresser. Il faut en plus toucher aux variables d'environnement. Ensuite c'est à toi de déployer les mises à jour quand tu le souhaite.
D'expérience c'est systématique avec Java. Avec PHP c'est rare d'avoir un truc aussi lourd. On fait tourner du Wordpress sur à peu près n'importe quoi alors qu'un serveur Minecraft il faut plusieurs Go de ram. Autre comparaison avec deux produits à but identiques : ovirt et xencenter. ovirt c'est du tomcat et les spécifications demandent 4GB de ram sur le serveur. Xencenter est un client lourd Windows, il tourne avec 70Mo de RAM...
Tu as tout en qualité. Demande toi pourquoi des choses comme spark, cassandra, lucene, hadoop, netty,... sont écris en Java. Des logiciels dont les utilisateurs sont très soucieux de la performance et de la consommation de ressource (gagner quelques pourcent de mémoire sur ce genre de grosse infrastructure ça représente une certaine somme d'argent).
Sur le bureau XMind par exemple est plutôt pas mal.
Ce qui est important c'est de comprendre l'outil. La JVM démarre relativement lentement et nécessite un petit temps de chauffe (il faut que HotSpot découvre ton usage du code pour l'optimiser correctement). Donc réécrire les binutils avec n'a pas de sens par exemple (grep te donne le résultat avant que la JVM n'ai le temps de démarrer). Il faut aussi savoir bien utiliser le langage et éviter certaines choses qui sont mauvaises niveau performance (les JSP voire les servlet si tu veux vraiment de la haute perf, les techno qui vont créer dynamiquemnt des proxy de tes objets, etc).
Le runtime est très souple ça permet de faire des choses impressionnantes (voir les ORM comme hibernate ou OSGi), mais c'est du coup facile d'en faire n'importe quoi.
Quand quelqu'un écris du mauvais code C++, il écris des bugs.
Quand quelqu'un écris du mauvais code Java, il écris un logiciel lent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: This is javaaa
Posté par barmic . En réponse à la dépêche Fim 1.1.0. Évalué à 10.
Aller je saute dedans...
Ou pas. C'est absolument trivial de choisir en temps qu'admin la version de Java que va utiliser une application. C'est l'histoire d'une variable d'environnement. En python tu va t'amuser entre ceux qui ont mis
#!/usr/bin/python,#!/usr/bin/python2,#!/usr/bin/python3ou#!/usr/bin/env python(ou python2 ou 3). Tu dois créer un virtalenv spécifique.Non, c'est uniquement si tu utilise l'installeur. Rien ne t'oblige à utiliser celui là et si tu es sysadmin je te conseil de ne pas l'utiliser et de lui préférer l'archive à décompresser. Il faut en plus toucher aux variables d'environnement. Ensuite c'est à toi de déployer les mises à jour quand tu le souhaite.
Tu as tout en qualité. Demande toi pourquoi des choses comme spark, cassandra, lucene, hadoop, netty,... sont écris en Java. Des logiciels dont les utilisateurs sont très soucieux de la performance et de la consommation de ressource (gagner quelques pourcent de mémoire sur ce genre de grosse infrastructure ça représente une certaine somme d'argent).
Sur le bureau XMind par exemple est plutôt pas mal.
Ce qui est important c'est de comprendre l'outil. La JVM démarre relativement lentement et nécessite un petit temps de chauffe (il faut que HotSpot découvre ton usage du code pour l'optimiser correctement). Donc réécrire les binutils avec n'a pas de sens par exemple (grep te donne le résultat avant que la JVM n'ai le temps de démarrer). Il faut aussi savoir bien utiliser le langage et éviter certaines choses qui sont mauvaises niveau performance (les JSP voire les servlet si tu veux vraiment de la haute perf, les techno qui vont créer dynamiquemnt des proxy de tes objets, etc).
Le runtime est très souple ça permet de faire des choses impressionnantes (voir les ORM comme hibernate ou OSGi), mais c'est du coup facile d'en faire n'importe quoi.
Quand quelqu'un écris du mauvais code C++, il écris des bugs.
Quand quelqu'un écris du mauvais code Java, il écris un logiciel lent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)