J'ai un .Fichier jar qui représente un wrapper pour lancer un autre fichier .jar avec certains arguments pour la machine virtuelle Java, car il n'y a apparemment aucun autre moyen de le faire. Ce wrapper construit les arguments en ligne de commande java -jar <arg1> <arg2> ... MyJarFile.jar sur la base de l’architecture du système: appel de la machine virtuelle Java 64 bits (-d64) ou non et définir la taille du tas via -Xmx1280M (max sur un système 32 bits, d'après ce que j'ai compris) ou demander 4 Go s'il s'agit d'une architecture 64 bits. java -version me montre que j'ai une machine virtuelle Java 64 bits en cours d'exécution etvérifier le PATH dans les variables d'environnement le confirme. Maintenant, tout va bien si je lance le wrapper via la ligne de commande. Le fichier .jar actuel est lancé avec 4 Go de mémoire allouée. Si je double-clique sur le wrapper à partir de l'explorateur Windows, le fichier .jar réel est lancé avec le minimum (par exemple, 247 Mo) de mémoire. Remarque que j'ai aussi mis la -Xms512MB dans les arguments de commande, qui est apparemmentignoré si vous lancez le wrapper à partir de l'interface utilisateur Windows. Il est vrai que sur les machines sur lesquelles je rencontre le problème, les versions 32 bits et 64 bits de Java sont installées. En vérifiant le registre Windows (regedit) sous l’entrée machine / jarFile locale, je constate qu’il est lié à la version 32 bits de l’environnement d’exécution. Si je le modifie ici, cela fonctionne, mais dès qu'une mise à jour Java est installée, le paramètre de registre est annulé. Des idées pourquoi cela se produit? (Je n'ai pas encore testé sur les systèmes UNIX car l'application est principalement utilisée sous Windows). Je vous remercie.
Réponses:
0 pour la réponse № 1Voir un exemple avec 2 Go:
java -Xmx2g -jar <your-file>.jar
J'espère que cela aide