Deployment 32 bit vs 64 bit

Version imprimable

16/02/2012, 10h16
Alec6

Deployment 32 bit vs 64 bit

J ai une application java standalone que je veux deployer sur des ordinateurs.

Ces derniers peuvent etre 32 bit ou 64 bit (mac, pc, linux...).

Question: est ce que l’environnement avec lequel j'ai compilé le code avant le déploiement à une incidence.

Question 2: je veux déployer avec une JRE embarquée (la 5 qui correspond à l’environnement de test) pour être certain de ne pas avoir de régression avec les évolutions. Est ce que je peux faire tourner une JRE 32 bit sur un OS 64 et inversement ?

Question 3: sous mac j'ai pas réussi à embarquer la JRE de mac dans le logiciel; est ce possible ?

Qu'elle est la best practice ?
16/02/2012, 10h44
adiGuba

Salut,

Citation:

Envoyé par Alec6

Question: est ce que l’environnement avec lequel j'ai compilé le code avant le déploiement à une incidence.

Non.
Sauf si tu utilises du code natif ou des librairies externes qui utilisent du code natif. Dans ce cas il faudra fournir les différentes codes natifs compilés pour chaque plateforme.

Citation:

Envoyé par Alec6

Question 2: je veux déployer avec une JRE embarquée (la 5 qui correspond à l’environnement de test) pour être certain de ne pas avoir de régression avec les évolutions. Est ce que je peux faire tourner une JRE 32 bit sur un OS 64 et inversement ?

En général les OS 64 bits inclut un mode de compatibilité qui permet l'exécution d'application 32 bits.

Mais l'inverse ne fonctionne pas !

Citation:

Envoyé par Alec6

Question 3: sous mac j'ai pas réussi à embarquer la JRE de mac dans le logiciel; est ce possible ?

Aucune idée...

Citation:

Envoyé par Alec6

Qu'elle est la best practice ?

Il faudrait plus de détail sur ton application... mais perso je doute que le choix de déployer le JRE avec l'appli soit une bonne idée. De quel type d'application s'agit-il ?

a++
16/02/2012, 10h53
Alec6

Merci Adiguba pour ces réponses

C'est une application java swing standalone que j'ai toujours déployé avec sa JRE (sauf sur Mac) car il est arrive des régressions au niveau:
- du jfilechooser.
- du parser sax
...
on se rappelle tous de la création du mot clef enum.

Donc j essai de faire en sorte que le contexte de déploiement soit comme le contexte de test.
16/02/2012, 11h04
adiGuba

Citation:

Envoyé par Alec6

on se rappelle tous de la création du mot clef enum.

La création du mot clef enum n'a eu aucune incidence sur les postes clients, mais uniquement sur les postes de développement.

Aujourd'hui encore si tu compiles en 1.4 tu peux utiliser le terme "enum" comme variable et exécuter ton application sur un JRE 7 sans aucun problème...

Pour une application cliente déployé il serait préférable de comprendre ces régressions et de les corriger plutôt que d'imposer une JVM.

a++
16/02/2012, 11h09
thelvin

Citation:

Envoyé par Alec6

on se rappelle tous de la création du mot clef enum.

Ça ça posait problème pour compiler les programmes qui existaient.
Mais on pouvait exécuter sans problèmes les programmes qui avaient déjà été compilés.

Citation:

Envoyé par Alec6

Donc j essai de faire en sorte que le contexte de déploiement soit comme le contexte de test.

Moi je me contente de dire : "Ce logiciel doit être utilisé avec Java en version 1.5".
Quand ce n'est pas acceptable, Je m'arrange pour que le programme s'adapte à ce qu'il y a. Et si ça ne marche pas avec les versions futures, les utilisateurs auraient pu me demander ce que j'en pensais avant de faire une mise à jour majeure de Java (pas être stupide non plus, c'est pareil avec tout le reste de l'informatique, et de l’ingénierie d'ailleurs.)

De ce que j'en ai vu, l'état de l'art, c'est ça. On attendait du JDK 7 qu'il change des choses, mais il me semble que ça s'est pas fait.
16/02/2012, 11h22
Alec6

Ce que vous dites est juste mais on a pas toujours le temps d être réactif et le client lui n attends pas.

Et le téléphone sonne....

Par contre il faut bien sur que le logiciel évolue avec les versions de Java. Surtout qu'en générale on a besoin des nouvelles fonctionnalités offertes.
16/02/2012, 11h22
adiGuba

Citation:

Envoyé par thelvin

De ce que j'en ai vu, l'état de l'art, c'est ça. On attendait du JDK 7 qu'il change des choses, mais il me semble que ça s'est pas fait.

Non les évolutions du langage prennent en compte au maximum les éventuels problèmes d'incompatibilités, et en particulier en ce qui concerne les binaires (cad les programmes déjà compilé). Il n'était pas du tout prévu que Java 7 casse tout (ni les suivant d'ailleurs).

Bien sûr il peut quand même y avoir des incompatibilités, mais cela se limite souvent à des cas très particulier où à des corrections de comportement déjà incohérent.

a++
16/02/2012, 11h31
thelvin

Citation:

Envoyé par Alec6

Ce que vous dites est juste mais on a pas toujours le temps d être réactif et le client lui n attends pas.

Et le téléphone sonne....

Le monde est vraiment trop injuste, n'est-ce pas ?
Les incompatibilités de ce genre, elles arrivent pas par légions. Enfin, ça arrive peut-être quand on s'y prend mal, et du coup, quand on s'y prend mal on a des problèmes. Incroyable, hein ?
De toute façon, ça sera toujours le cas d'une manière ou d'une autre. On n'inclut pas de JRE dans ses programmes.

Citation:

Envoyé par adiGuba

Non les évolutions du langage prennent en compte au maximum les éventuels problèmes d'incompatibilités, et en particulier en ce qui concerne les binaires (cad les programmes déjà compilé). Il n'était pas du tout prévu que Java 7 casse tout (ni les suivant d'ailleurs).

C'est pas ce que je veux dire. À une époque on parlait de la soudaine possibilité de distribuer la JRE directement avec ses programmes Java, et il me semble que c'était en rapport avec OpenJDK et le JDK 7. Mais finalement j'en ai pas vu la couleur.