Le gestionnaire Java dans Windows lance par défaut la VM 32 bits si tu as installé la version 32 bits de Java, même si tu as aussi installé la version 64 bits. Si tu n'as pas installé du tout la version 32 bits, ce gestionnaire se lance en 64 bits. Bref désinstalle cette fichue version 32 bits de Java si ton OS est 64 bits (plus personne n'a besoin d'exécuter des applets Java dans un navigateur 32 bits). Note aussi que le gestionnaire 64 bits met aussi à jour automatiquement la version 64 bits. Si tu désinstalles la version 32 bits de Java la version 64 bits sera encvore là mais tu n'auras plus de gestionnaire dans le panneau de configuration: réinstalle la version 64 bits pour installer le gestionnaire 64 bits.
Il se trouve que la page d'Oracle proposant d'installer Java te proposes la version 32 bits si ton navigateur est 32 bits même si ton OS est 64 bits, car le site web ne sait pas détecter correctement que ton OS peut faire autre chose. En cause ici: Les navigateurs qui sont encore trop nombreux à ne s'intaller eux-même qu'en 32 bits (dont Chrome dont la version 64 bits existe mais n'est pas proposée car pas encore officiellement supportée: Chrome est en 32 bits car il n'a pas besoin du 64-bits pour créer des processus pour ses moiteurs de rendus et onglets et il utilise alors un peu moins de mémoire par processus; IE 11+ et Edge sont en 64 bits et ne créent pas de processus séparés mais des threads, avec cependant moins de sécurité qu'avec l'isolation en processus séparés: si le processus plante tout le navigateur plante, alors qu'avec des processus séparés pour un moteur de rendu, ou pour un seul onglet, ou un une seule extension, les processus parents restent fonctionnels et ne sont pas attaquables aussi facilement par les processus enfants plantés...) Le pari de Chrome est plus de sécurité pour l'isolation avec des processus et non des threads, et comme chaque processus en fait moins, il n'a pas besoin d'autant de mémoire et chacun peut tourner en 32 bits. Cependant rien n'interdit à Chrome de créer des processus enfants 64 bits (ce qu'il fait dans sa version 64 bits non encore supportée). Chrome devra réfléchir à exécuter ses processus enfants selon leurs besoins en 32 bits ou 64 bits. Du fait de l'isolation des processus de Chrome, un site web tiers ne peut pas savoir si ton OS supporte ou pas le 64 bits. Mais le site officiel de Java t'avertit et te propose un lien alternatif pour les OS 64 bits si tu visites le site avec un navigateur 32 bits. Il te prévient aussi que la version 64 bits de Java ne prend pas en charge l'intégration des anciennes "applets" pour les navigateurs 32 bits. Le 19 mars 2018 à 11:07, Jérôme Seigneuret <jerome.seigneu...@gmail.com> a écrit : > On a pas sur le wiki un procces pour l'install et la mise à jour de java > sur les différentes plateforme? après on a piour certains une contrainte de > taille, (le gestionnaire du SI qui n'installe que les 32Bit et non les 64) > je suis pas admin de mon poste donc... dans le c** lulu > > Le 19 mars 2018 à 10:25, Philippe Verdy <verd...@wanadoo.fr> a écrit : > >> JOSM est rapide et ne bloque pas du tout si tu l'utilises avec Java en 64 >> -bits qui ne souffre pas de la limite de taille mémoire trop basse par >> défaut. >> JOSM documente comment augmenter la taille de la VM par défaut (même en >> 32 bits seulement on peut le faire même si on ne peut pas aller aussi haut >> qu'en 64-bits). >> >> Personnellement je n'utilise plus du tout l'installation de Java en 32 >> bits (qui ne servait encore que pour les "plugins" et "applets" au sein >> d'un navigateur 32-bits) et qui n'est même pas installé du tout, je >> n'utilise que la version 64 bits, donc sans aucune intégration aux >> navigateurs 32 bits. Je ne comprend pas d'ailleurs pourquoi le site Java >> continue de proposer par défaut la version 32-bits même sur un OS 64 bits: >> la double installation est totalement inutile, et cela fait longtemps que >> Java aurait du prendre en charge l'intégration des anciennes applets dans >> un navigateur 32 bits via un proxy où la VM Java ne serait installée qu'en >> 64 bits. Ce qui est parfaitement possible (et même documenté dans le JDK >> sur la façon de le faire!) >> >> L'ennui c'est le composant d'intégration au navigateur qui n'a jamais >> évolué et continue d'utiliser la vielle méthode NPAPI héritée de Netscape >> et que même Firefox a abandonné (après déjà IE, Edge, Chrome, Safari, >> Opera...), et qu'il aurait du être réécrit depuis longtemps pour profiter >> des évolutions (y compris des améliorations de sécurité au sein des >> navigateurs comme au sein de la VM Java elle-même: NAPI est totalement >> obsolète, remplacé sur tous les principaux navigateurs). >> >> >> Le 19 mars 2018 à 10:13, Rpnpif <rpn...@trob.eu> a écrit : >> >>> Le 17 mars 2018, deuzeffe a écrit : >>> >>> > Mmmhhh ??? On peut utiliser QGis pour mettre à jour JOSM qui mettra à >>> > jour osm ? C'est plus intéressant que JOSM seul ? >>> >>> Oui puisque chez moi JOSM est trop lent et bloque avec autant de >>> données. >>> >>> Bien sûr, le but est de sélectionner une petite zone (communale au >>> plus). >>> Mais je vais peut-être me rabattre sur la couche rapatriée sur Id. >>> >>> Merci. >>> >>> -- >>> Alain Rpnpif >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > > > -- > Cordialement, > Jérôme Seigneuret >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
