Discussion :

[anadoncamille]

Bonjour,

je développe un logiciel en Java, AnAcondA qui permet entre autres de gérer son budget et son agenda. Actuellement je développe en java 32 bits et je voudrai savoir s'il est possible de faire tourner une application à la fois en 32 et en 64 bits sans avoir 2 versions différentes. Comment dois-je faire ?

[OButterlin]

Rien... ça fonctionne quelque soit la JVM.
Seule la version java utilisée pour "compiler" est importante. Si on utilise la version 8, on ne pourra pas faire tourner le programme sur une version 7 ou en dessous.

[anadoncamille]

J'ai regardé les différentes versions du JDK. La version 8 propose deux versions en 32 ou 64 bits. La version 9 du JDK ne donne pas de choix entre 32 et 64 bits et il n'y a pas de JRE 9. Je ne sais pas quelle version choisir pour compiler. Je voudrais que mon logiciel tourne sur les architectures 32 et 64 bits.

[OButterlin]

Pour toucher un maximum d'utilisateur, je te suggère de rester sur une version 8 (32 ou 64 bits, aucune importance)

[anadoncamille]

Enfin ça fonctionne ! J'avais un problème de compatibilité avec les versions 64 bits que j'ai corrigé. Du coup après quelques tests j'ai décidé de compiler en 32 bits sur une version 1.6 du JDK pour être compatible avec un maximum de versions, y compris des anciennes, et ça marche aussi avec la dernière version du JRE 64 bits.
Merci pour ton aide OButterlin !

[Gugelhupf]

Salut,

Quand tu compiles un projet avec le compilateur - disons le compilateur officiel javac présent dans le JDK d'Oracle - cela te donne du bytecode.
Si tu compiles avec la version 8 de Java, le bytecode produit pourra être interprété par une autre machine possédant une JVM (machine virtuelle Java) dont la version est supérieure ou égale à 8.
Il n'est bien sur pas obligatoire d'installer un nouveau JDK pour assurer la compatibilité, dans javac tu as les options -source 1.8 -target 1.7 ou bien des plugins Maven pour cela.
Si tu codes en Java pure, sans utiliser de librairie native (C, C++, Ada etc), la version 32 ou 64 bits d'une JVM n'aura pas d'influence sur l'exécution de ton programme.

Quelques différences entre la version 32 et 64 bits de Java :

• La version 32 bits a continué d'exister pour assurer la compatibilité avec les anciens composants + OS d'ordinateur.
• Le seul cas qui m'a posé problème entre la version 32 et 64 bits d'une JVM fut le jour où j'ai voulu exécuter un programme contenant des librairies natives sous une JVM 64 bits essayant d'attaquer une base Microsoft Access 32 bits.

A+

[yotta]

Bonjour,
Pour ma part, je ne comprend pas bien le fait de se poser ce genre de question. De toute façon, les éditeurs de système d'exploitation annoncent déjà que leurs prochaines versions ne seront plus déclinées en 32 bits. Les machines, elles, sont déjà toutes en 64 bits. Pourquoi s'évertuer à rester en 32 bits ?! C'est cela qui n'a aucun intérêt. Mis à part les impératifs de compatibilité avec l'existant, et encore, puisque si on a conservé les sources, au pire, il suffit de recompiler son source avec un jdk 64 bits et tout le monde est content. Non, je ne vois vraiment pas en quoi conserver une jvm en 32 bits pourrait être utile. Mais ce n'est que mon point de vue.

[thelvin]

Oui... Mais je crois qu'on s'éloigne un peu de la considération de départ.

Java, à la base, est connu pour une fonctionnalité assez insolite : on se fout royalement de la machine sur laquelle il va falloir que ça tourne. Le même programme Java fera exactement la même chose, quelle que soit la machine sur laquelle on l'exécute.

Alors certes, de nos jours Java a plusieurs autres qualités qui définissent plus justement son intérêt industriel : architecture très solide, grand nombre de professionnels formés, énorme quantité toujours plus croissante d'outils de développements éprouvés, compatibilité universelle (si t'es pas compatible Java tu sers à rien).

Mais le point de départ n'a jamais disparu : quand on fait du Java on n'en a rien à cirer de quel processeur le fera tourner : 32 bits ou 64 bits, RISC ou CISC, ou telle ou telle marque. Du pareil au même dans tous les cas.

[yotta]

En effet. Ce qu'il suffit de retenir de tout ça, c'est qu'il ne faut pas confondre ce que produit un développeur Java, et ce que fait la machine virtuelle Java. Le premier produit du code pré-compilé, c'est le second qui compile en temps réel le code pré-compilé du développeur pour en faire du code binaire, seul code exécutable par la machine hôte. L'importance d'un environnement 32 ou 64 Bits ne concerne donc que la machine virtuelle, pas le développeur qui comme le dit si bien thelvin, peut en faire complètement abstraction.

[anadoncamille]

Merci pour toutes vos réponses ! Pour ma part j'ai remarqué que les vieux ordinateurs durent plus longtemps que les nouveaux. Ce qui fait qu'il existe encore des ordinateurs avec des loiciels en 32 bits. Comme AnAcondA n'a pas besoin d'un PC de compétition pour bien tourner, je préfère rester compatible avec les anciennes versions de Java. Je vous invite à essayer AnAcondA, disponible sur mon site à www.anadoncamille.com. C'est un bon démonstrateur de ce que Java peut faire, en dehors du fait qu'il est un logiciel plein de fonctionnalités.

Bonne année à tous !

[Gugelhupf]

Salut,

J'ai fait un tour sur ton site, tu distribues un ".exe", pourquoi ne pas utiliser un ".jar" exécutable plutôt ?

A+

[yotta]

Bonjour à vous,
Je penses qu'anadoncamille a cherché à conditionner un installateur pour son déploiement, je ne sais pas pourquoi, et il a dû utiliser un utilitaire de création d'installateur pour produire ce .exe. D'ailleurs, c'est peut-être un simple zip auto-extractible. Je n'ai pas personnellement lancé cet exécutable. En tous cas, cela expliquerait pourquoi il attache tant d'importance à l'architecture hôte, alors que malgré toutes nos explications, il n'a de toute évidence pas compris que cet aspect n'est pas à prendre en compte avec Java sauf dans le cas d'utilisation de librairies natives, ce qui est peut-être le cas d'ailleurs, il ne le précise pas.

Au fait, anadoncamille, il faudrait corriger votre signature, vous n'avez corrigé que le texte du lien, le lien lui pointe toujours vers votre ancien site chez free !

[anadoncamille]

Je n'ai pas fait de jar exécutable parce qu'il y a des paramètres de mémoire à entrer en ligne de commande. Initialement c'était un .bat qui démarrait AnAcondA, mais j'ai trouvé Launch4j qui crée un exécutable avec un bitmap à la place de la console et la possibilité de paramétrer la mémoire et j'ai préféré cette solution. Quant à l'installeur, j'ai préféré cette solution que je trouve plus ergonomique qu'un zip. Pour le choix entre 32 et 64 bits, j'avais un problème de code qui n'acceptait pas les architectures 64 bits mais que j'ai désactivé car il n'a plus lieu d'être.

Pour ma signature, elle pointe bien vers mon site mais je n'arrive pas à la modifier dans mon profil.

[yotta]

Bonjour Anadoncamille,
Ok, je comprends mieux d'où vient ce .exe
Pour ce qui concerne votre signature, je suis surpris que vous n'arriviez pas à la modifier ?!
Voilà à quoi ressemble la mienne en mode édition (Depuis le tableau de bord, bloc "Mes paramètres", menu "Modifier votre signature") :



Si je voulais par exemple modifier uniquement l'URL de mon premier lien, "Tout sur Java, du débutant au pro...", il me suffirait de modifier la partie surlignée dans cette illustration.
Je suppose que pour votre signature, il suffit de modifier l'Url, sans toucher au texte affiché.
En fait, le texte affiché d'un lien est le texte qui se trouve entre les balises <URL> et </URL>. Ne pas confondre avec le lien. Lorsque l'on utilise un lien différent du texte affiché, il faut le déclarer dans la balise <URL=lien>texte affiché qui apparaîtra généralement en bleu</URL>. Si on ne renseigne pas l'url dans la balise, alors le texte affiché fait office d'url.

[anadoncamille]

Bonjour yotta,

ça y est j'ai modifié ma signature. J'étais dans le panneau de consultation des profils et non dans le tableau de bord. Je viens de le retrouver ce matin.
Merci pour votre aide.