Bonjour,
 
J ai une application java, et mmnt je veux qu elle fonctionne sur n importe quel PC meme si y a pas la machine virtuelle
Autrement dit comment je peut extraire l'executable pour ensuite utiliser  installschield pour la rendre installable .
Merci d' avance.

Salut,
je voudrai une doc clair en français de preference
 
j ai entendu dire que ça se faisait sur l invite de commande  
mais je ne sais pas comment  
 
Je le repet emon but est d extraire l executable
 
Merci

 
Salut,
 
je pense que tu n'as rien bitté à Java, et qu'il serait grand temps que tu t'y mettes.
 
Merci.

install anywhere avec la JVM bundlée avec?

Je pense que tu ne devrais même pas le penser mais l'affirmer  

Soit il s'arrete au JDK 1.2 et fait du Visual J++ (introuvable) mais a un EXE Win32.
Soit il s'arrete au JDK 1.3 et fiat du Visual J# mais a un EXE .NET 2.0.
Soit il achete un compilo supair cher qui compile du JDK 1.5 (et ptet 1.6 maintenant) en EXE Win32, car ça existe.
 
Vous me paraissée un peu trop peteux là.

Sais-tu seulement ce que fait "le compilo super cher" ?
Dans le même ordre d'idées, sais-tu aussi pourquoi il peut avoir un exe win32 avec du Java 1.2 ?

De la magie, comme Gérard Majax

yeah

Bah parce que c'est compilé en Win32 et pas en Bytecode.
Et alors ? Il peut le faire et c'est ce qu'il veut, je ne vois pas le problème.
 
Après il c'est peut-être mal exprimé ou a mal compris la philosophie du Java. Mais s'il veut coder en Java et a un besoin ponctuel de distribuer son programme compilé de manière native pour Win32, c'est possible.

Ah ouais, OK le tout c'est d'y croire

Personne n'a jamais dit que c'était pas possible C'est surtout une très mauvaise façon de faire, qui va lui générer un exécutable de 2 Mo pour un Hello World et qui au final va revenir à installer une simili-JVM chez le client (et éventuellement à pourrir le PC du client).

Je vous garantie que le Visual J++ fait du code Win32.
 
Apres pour les autres truc je suis quasi sur que c'est idem. Je parle pas des Java2EXE mais bel et bien de compilateur qui fond tu code natif : http://schmidt.devlib.org/java/native-compilers.html
 
Enfin bref.

C'est "normal" et ça ne supporte que le 1.2 car les DLLs qui savent interpréter tout ça sont livrées de base dans XP (dépendance sur msjava.dll).

Normal qu'une DLL existe qui connaisse les bibliothèques de Java existe. Mais ça reste du code Win32 natif.
 
Y'as pareil pour VB, ou même la STL Visual C++ avec les DLL MSVB et MSVCRT... Mais c'est juste pour éviter d'inclure dans tout les EXE le code des bibliotheque de base. C'est un peu le principe de la compilation et des bibliothèques d'éviter la redondance.

Merci de m'expliquer le principe des DLLs
Ce que je voulais dire, c'est que Visual J++ génère du code qui tire sur une DLL qui est la JVM de Microsoft (enfin était, car MS a arrêté de la supporter en... 1.2, tiens donc) et que, bizarrement, c'est le seul outil qui fasse ça La compil n'est pas complète et le code généré n'est pas du Win32 pur ; on en a l'illusion car on récupère un exe au final qui marche sur tous les Windows XP mais ça n'est pas le cas.

Nah, en théorie il y a e.g. gcj qui est censé pouvoir générer du code natif.

Il n'y a après tout pas grand chose qui s'oppose au fait de compiler du java en code natif, il faut simplement embarquer une partie du runtime (comme ce que font les compilos Haskell, même si il faut embarquer bien plus de trucs pour Java dans la mesure où on se bouffe les problèmes de réflexion toussa, au final ça doit rester plus simple qu'un compilo Common Lisp et il en existe e.g. CMUCL, AllegroCL ou SBCL ).

Non, ce que je voulais dire c'est que y a que VJ++ 6 qui compile du "natif" qui tire sur msjava.dll.

Je dis pas qu'il y a que des inconvénients (sinon ce genre de produit n'existerait pas) mais y a pas mal de problèmes qui vont faire que tel ou tel exe va se viander : instanciation dynamique (et, comme tu le dis, tout ce qui est lié à la réflexion), distribution du package (un exe/dll un peu poussé est pas forcément simple à installer, faut un installer), etc... et puis bon, même si c'est évident, on perd tout l'aspect portabilité.
A mon sens, il est plus judicieux de coder en C/C++ à moins vraiment qu'on ait un projet ultra-lourd à porter (mais dans ce genre de cas, c'est plutôt un souci de design à la base ).

Visual J++ etait peut etre pas le meilleur exemple, mais le Visual J# produit bien du CLR, mais s'il faut un runtime Visual J# car les Assembly emulant le JDK ne sont pas dans le .NET de base (j'ai jamais compris pourquoi).

On avait un gars de Microsoft dans notre boîte y a quelques années qui nous expliquait que l'intérêt de J# était uniquement pour faire le pont entre du code Java et du code .Net. Là encore, la version de Java supportée est limitée (1.3, je crois qu'ils ont eu un outil beta qui faisait la 1.4) pour justement encourager les boîtes à faire le passage sur .Net. Donc en fait, ils font une conversion de Java à .Net mais sans passer par du code natif (youpi).
Ca s'utilise chez nous pour éviter de coder (et maintenir, surtout) le même truc dans 2 langages différents mais franchement, la limitation à Java 1.3 fait mal au cul (pis comme tu le dis, il faut avoir .Net préinstallé sur la machine cliente pour l'utiliser... autant installer une JVM )

J'ai pas dit qu'il allait se viander (si on peut compiler du Common Lisp, ya pas de raison de pas pouvoir compiler du Java), j'ai dit que le boulot du compilo était plus tendu (ou que plus de runtime devait être inclus) que dans le cadre de la compilation d'un langage plus statique (genre OCaml), nuance.

Beuh, non

Oui et non, on perd en portabilité sur le binaire compilé final, mais rien n'empêche de distribuer les binaires et le source, ou un binaire pour chaque target, toussa.

le problème c'est que si Java c'est de la merde, C/C++ c'est de la diarhée

Nan mais ça on s'en fout, le CLR c'est grosso merdo équivalent à la JVM (avec des nuances, mais faut pas abuser), donc un compilo Java -> CIL ça n'a rien d'impressionnant, et aucun rapport avec un compilo Java -> natif

Bin ça dépend vers quoi te fait tirer ton compilo natif (genre s'il a besoin d'une DLL à lui au runtime, bin va falloir la packager avec ton exe).

Ouais enfin c'est quand même super loin de la portabilité de Java, qui était celle à laquelle je me référais.

Tu vas pas nous rechier une pendule comme tu l'avais fait pour PHP, hein

Effectivement, après un peu de PHP on a une coulante telle qu'on peut chier une horloge, ou même une armoire normande (en plus on a le cul bien fait, donc ça passe tout seul)

De deux choses l'une, ou tu fais dans la portable et tu utilise la machine virtuelle java, ou tu ne fais aps dans le portable te tu peux utiliser du code natif.
 
Il existe plusieurs solutions : un jar executable (avec manifeste donc).
Un jar executable, fournis avec des scripts de base (batch/bash) qui le lancent automatiquement.
Un faux executable natif (le compilo borland et celui du biliu savant faire ca) qui a besoin de la JVM.
Un vrai executable natif (gcj sait faire ca) mais compte minimum 50Mo pour une application de base.