Mon but n'est pas de battre des record de vitesse, mais sur certain PC
par exemple je me vois mal installer java juste pour faire tourner une
fois mon programme.
Donc un executable en plus du jar offre un plus.
J'ai un peu de mal a faire le tri entre le subjectif de certain propos
sur le web concernant le code natif. Non je veux pas que mon programme
aille plus vite que du C++ (enfin si ca le fait je suis preneur quand
meme)
Et si l'exe doit avoir en plus un runtime dll pour tourner c'est pas
un probleme.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Bourg
Jean Bon (de Parme) a écrit :
Bonjour
Mon but n'est pas de battre des record de vitesse, mais sur certain PC par exemple je me vois mal installer java juste pour faire tourner une fois mon programme.
Donc un executable en plus du jar offre un plus.
J'ai un peu de mal a faire le tri entre le subjectif de certain propos sur le web concernant le code natif. Non je veux pas que mon programme aille plus vite que du C++ (enfin si ca le fait je suis preneur quand meme)
Et si l'exe doit avoir en plus un runtime dll pour tourner c'est pas un probleme.
Mon but n'est pas de battre des record de vitesse, mais sur certain PC
par exemple je me vois mal installer java juste pour faire tourner une
fois mon programme.
Donc un executable en plus du jar offre un plus.
J'ai un peu de mal a faire le tri entre le subjectif de certain propos
sur le web concernant le code natif. Non je veux pas que mon programme
aille plus vite que du C++ (enfin si ca le fait je suis preneur quand
meme)
Et si l'exe doit avoir en plus un runtime dll pour tourner c'est pas
un probleme.
Mon but n'est pas de battre des record de vitesse, mais sur certain PC par exemple je me vois mal installer java juste pour faire tourner une fois mon programme.
Donc un executable en plus du jar offre un plus.
J'ai un peu de mal a faire le tri entre le subjectif de certain propos sur le web concernant le code natif. Non je veux pas que mon programme aille plus vite que du C++ (enfin si ca le fait je suis preneur quand meme)
Et si l'exe doit avoir en plus un runtime dll pour tourner c'est pas un probleme.
Mon but n'est pas de battre des record de vitesse, mais sur certain PC par exemple je me vois mal installer java juste pour faire tourner une fois mon programme.
Donc un executable en plus du jar offre un plus.
J'ai un peu de mal a faire le tri entre le subjectif de certain propos sur le web concernant le code natif. Non je veux pas que mon programme aille plus vite que du C++ (enfin si ca le fait je suis preneur quand meme)
Et si l'exe doit avoir en plus un runtime dll pour tourner c'est pas un probleme.
Merci de vos lumieres.
En plus de la solution déjà donnée, tu peux :
* utiliser (sous windows) un .bat qui appelle le .jar, et à y être tu pourras aussi créer un .bat pour compiler. * dans certains systèmes, et avec une installation correcte de java, double-cliquer sur un .jar l'exécute. Je l'ai vu au moins sous MacOSX, et je soupçonne Windows d'en être capable (la solution du .bat sert alors lorsque tu ne souhaites pas utiliser de .jar, mais laisser tes classes "à l'air libre". Je ne vois pas où est le problème avec l'installation de java : si tu souhaites programmer en java, tu vas de toute façon en avoir besoin, quant à tes éventuels "clients", je pense qu'ils s'y retrouveront plus facilement avec un JRE qu'avec une solution barbare à base d'exécutable: on y perd la compatibilité inter-OS entre autres. Le JRE peut d'ailleurs être livré avec ton appli, comme on le voit par exemple avec Scilab 5 ou SAS, ou simplement l'installation est laissée à l'utilisateur, et ça se fait en quelques clics sur java.sun.com. Et quelques clics de plus pour configurer le PATH.
Je trouve que le plus simple et le plus agréable quand je télécharge un programme java est d'avoir trois fichiers: * un .zip (ou .tar.gz suivant les goûts) pour les sources * un .zip (idem) pour la javadoc * un .jar pour le binaire Bien sûr, ça reste un simple avis perso. J'aurais également tendance à préférer le .zip, qui ne nécessite pas de programme supplémentaire pour être décompressé : la commande jar de Java le fait très bien, puisque n'importe quel fichier .jar est simplement une archive zip avec un fichier en plus à l'intérieur, le "manifest".
Petite remarque sur la vitesse : le jdk6 est déjà capable de battre gcc, sur du code pas trop méchant. Dans le tableau qui suit, je fais une multiplication matricielle "naïve" (*), de deux matrice de taille n x n, et j'utilise gcc (optimisation -O0, -O1 et -O2) et java jdk6 (-client et -server). Les nombres sont les temps en secondes sur mon ordi.
Il faut tout de même noter que ce genre de test avantage java lorsqu'on fait des calculs sur des types élémentaires. Si on utilise des grosses classes, ça ne sera pas trop un problème (C++ ne ferait guère mieux), mais avec des classes très simples, comme Complex (pour des nombres complexes), Java se fait couler : il alloue tous les objets sur le tas, alors que C++ peut les allouer sur la pile. J'obtiens un facteur 10 en temps, entre deux boucles réalisant le même calcul, additionner des nombres complexes, l'une avec des additions de "double", et l'autre avec des additions de "Complex" (avec la classe trouvée dans la Netlib). Cela dit, même pour du calcul numérique, Java se débrouille très bien (cf Cern Colt ou Jama pour des classes "matrices" bien faites (**)).
(*) juste une triple boucle, avec pour seule optimisation de les mettre dans le bon sens : "ijk" n'est pas équivalent à "ikj" par exemple
Mon but n'est pas de battre des record de vitesse, mais sur certain PC
par exemple je me vois mal installer java juste pour faire tourner une
fois mon programme.
Donc un executable en plus du jar offre un plus.
J'ai un peu de mal a faire le tri entre le subjectif de certain propos
sur le web concernant le code natif. Non je veux pas que mon programme
aille plus vite que du C++ (enfin si ca le fait je suis preneur quand
meme)
Et si l'exe doit avoir en plus un runtime dll pour tourner c'est pas
un probleme.
Merci de vos lumieres.
En plus de la solution déjà donnée, tu peux :
* utiliser (sous windows) un .bat qui appelle le .jar, et à y être tu
pourras aussi créer un .bat pour compiler.
* dans certains systèmes, et avec une installation correcte de java,
double-cliquer sur un .jar l'exécute. Je l'ai vu au moins sous
MacOSX, et je soupçonne Windows d'en être capable (la solution
du .bat sert alors lorsque tu ne souhaites pas utiliser de .jar,
mais laisser tes classes "à l'air libre".
Je ne vois pas où est le problème avec l'installation de java : si
tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
quant à tes éventuels "clients", je pense qu'ils s'y retrouveront
plus facilement avec un JRE qu'avec une solution barbare à base
d'exécutable: on y perd la compatibilité inter-OS entre autres.
Le JRE peut d'ailleurs être livré avec ton appli, comme on
le voit par exemple avec Scilab 5 ou SAS, ou simplement l'installation
est laissée à l'utilisateur, et ça se fait en quelques clics sur
java.sun.com. Et quelques clics de plus pour configurer le PATH.
Je trouve que le plus simple et le plus agréable quand je télécharge
un programme java est d'avoir trois fichiers:
* un .zip (ou .tar.gz suivant les goûts) pour les sources
* un .zip (idem) pour la javadoc
* un .jar pour le binaire
Bien sûr, ça reste un simple avis perso.
J'aurais également tendance à préférer le .zip, qui ne nécessite
pas de programme supplémentaire pour être décompressé :
la commande jar de Java le fait très bien, puisque n'importe
quel fichier .jar est simplement une archive zip avec un fichier en plus
à l'intérieur, le "manifest".
Petite remarque sur la vitesse : le jdk6 est déjà capable de battre gcc,
sur du code pas trop méchant. Dans le tableau qui suit, je fais une
multiplication matricielle "naïve" (*), de deux matrice de taille n x n,
et j'utilise gcc (optimisation -O0, -O1 et -O2) et java jdk6 (-client
et -server). Les nombres sont les temps en secondes sur mon ordi.
Il faut tout de même noter que ce genre de test avantage java
lorsqu'on fait des calculs sur des types élémentaires.
Si on utilise des grosses classes, ça ne sera pas trop
un problème (C++ ne ferait guère mieux), mais avec des
classes très simples, comme Complex (pour des nombres
complexes), Java se fait couler : il alloue tous les
objets sur le tas, alors que C++ peut les allouer sur
la pile. J'obtiens un facteur 10 en temps, entre deux boucles
réalisant le même calcul, additionner des nombres
complexes, l'une avec des additions de "double", et
l'autre avec des additions de "Complex" (avec la classe
trouvée dans la Netlib). Cela dit, même pour du calcul
numérique, Java se débrouille très bien (cf Cern Colt
ou Jama pour des classes "matrices" bien faites (**)).
(*) juste une triple boucle, avec pour seule optimisation de les
mettre dans le bon sens : "ijk" n'est pas équivalent à "ikj" par
exemple
Mon but n'est pas de battre des record de vitesse, mais sur certain PC par exemple je me vois mal installer java juste pour faire tourner une fois mon programme.
Donc un executable en plus du jar offre un plus.
J'ai un peu de mal a faire le tri entre le subjectif de certain propos sur le web concernant le code natif. Non je veux pas que mon programme aille plus vite que du C++ (enfin si ca le fait je suis preneur quand meme)
Et si l'exe doit avoir en plus un runtime dll pour tourner c'est pas un probleme.
Merci de vos lumieres.
En plus de la solution déjà donnée, tu peux :
* utiliser (sous windows) un .bat qui appelle le .jar, et à y être tu pourras aussi créer un .bat pour compiler. * dans certains systèmes, et avec une installation correcte de java, double-cliquer sur un .jar l'exécute. Je l'ai vu au moins sous MacOSX, et je soupçonne Windows d'en être capable (la solution du .bat sert alors lorsque tu ne souhaites pas utiliser de .jar, mais laisser tes classes "à l'air libre". Je ne vois pas où est le problème avec l'installation de java : si tu souhaites programmer en java, tu vas de toute façon en avoir besoin, quant à tes éventuels "clients", je pense qu'ils s'y retrouveront plus facilement avec un JRE qu'avec une solution barbare à base d'exécutable: on y perd la compatibilité inter-OS entre autres. Le JRE peut d'ailleurs être livré avec ton appli, comme on le voit par exemple avec Scilab 5 ou SAS, ou simplement l'installation est laissée à l'utilisateur, et ça se fait en quelques clics sur java.sun.com. Et quelques clics de plus pour configurer le PATH.
Je trouve que le plus simple et le plus agréable quand je télécharge un programme java est d'avoir trois fichiers: * un .zip (ou .tar.gz suivant les goûts) pour les sources * un .zip (idem) pour la javadoc * un .jar pour le binaire Bien sûr, ça reste un simple avis perso. J'aurais également tendance à préférer le .zip, qui ne nécessite pas de programme supplémentaire pour être décompressé : la commande jar de Java le fait très bien, puisque n'importe quel fichier .jar est simplement une archive zip avec un fichier en plus à l'intérieur, le "manifest".
Petite remarque sur la vitesse : le jdk6 est déjà capable de battre gcc, sur du code pas trop méchant. Dans le tableau qui suit, je fais une multiplication matricielle "naïve" (*), de deux matrice de taille n x n, et j'utilise gcc (optimisation -O0, -O1 et -O2) et java jdk6 (-client et -server). Les nombres sont les temps en secondes sur mon ordi.
Il faut tout de même noter que ce genre de test avantage java lorsqu'on fait des calculs sur des types élémentaires. Si on utilise des grosses classes, ça ne sera pas trop un problème (C++ ne ferait guère mieux), mais avec des classes très simples, comme Complex (pour des nombres complexes), Java se fait couler : il alloue tous les objets sur le tas, alors que C++ peut les allouer sur la pile. J'obtiens un facteur 10 en temps, entre deux boucles réalisant le même calcul, additionner des nombres complexes, l'une avec des additions de "double", et l'autre avec des additions de "Complex" (avec la classe trouvée dans la Netlib). Cela dit, même pour du calcul numérique, Java se débrouille très bien (cf Cern Colt ou Jama pour des classes "matrices" bien faites (**)).
(*) juste une triple boucle, avec pour seule optimisation de les mettre dans le bon sens : "ijk" n'est pas équivalent à "ikj" par exemple
On Mon, 29 Sep 2008 22:59:44 +0200, Jean-Claude Arbaut wrote:
Je ne vois pas où est le problème avec l'installation de java : si tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple) Disons que l'exe est plutot une version portable qui n'installe pas jre sur la machine.
Quand a la course de vitesse, je suis pas specialement interessé. Tant que ca rame pas, ca me va.
De toute facon je pars sur une version jar, bin (pour linux) et exe pour avoir le choix.
Je ne vois pas où est le problème avec l'installation de java : si
tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple)
Disons que l'exe est plutot une version portable qui n'installe pas
jre sur la machine.
Quand a la course de vitesse, je suis pas specialement interessé. Tant
que ca rame pas, ca me va.
De toute facon je pars sur une version jar, bin (pour linux) et exe
pour avoir le choix.
On Mon, 29 Sep 2008 22:59:44 +0200, Jean-Claude Arbaut wrote:
Je ne vois pas où est le problème avec l'installation de java : si tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple) Disons que l'exe est plutot une version portable qui n'installe pas jre sur la machine.
Quand a la course de vitesse, je suis pas specialement interessé. Tant que ca rame pas, ca me va.
De toute facon je pars sur une version jar, bin (pour linux) et exe pour avoir le choix.
Jean-Claude Arbaut
Jean Bon (de Parme) wrote:
On Mon, 29 Sep 2008 22:59:44 +0200, Jean-Claude Arbaut wrote:
Je ne vois pas où est le problème avec l'installation de java : si tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple)
J'ai le même problème au boulot ! En attendant d'aller pleurer aux ressources infos, je me suis rabattu sur openwatcom et python, qui veulent bien s'installer ! :-)
Disons que l'exe est plutot une version portable qui n'installe pas jre sur la machine.
Ça, ça dépend ! (cf la fin du message)
Quand a la course de vitesse, je suis pas specialement interessé. Tant que ca rame pas, ca me va.
Juste un conseil alors : regarde ce qu'affiche "java -version". Si c'est "Java HotSpot(TM) Client VM" : démarrage rapide, mais programme lent ensuite. Si c'est "Java HotSpot(TM) Server VM" : démarrage lent, mais après ça va plus vite. Pour changer, tu utilises "java -client" ou "java -server". Sur un OS 64 bits tu n'as pas le choix, c'est toujours "server". Sans courir après les cycles cpu, on peut améliorer un peu l'ordinaire, ça ne fait pas de mal ! :-)
De toute facon je pars sur une version jar, bin (pour linux) et exe pour avoir le choix.
Les solutions usuelles qui fournissent un .exe ne donnent pas des programmes "natifs", mais un exe qui appelle le JRE pour lancer le programme. C'est juste pour faire "joli" sous windows ou macosx. Tu as donc besoin du JRE quoi qu'il arrive.
Pour du code natif, en principe gcj fait cela (c'est le morceau "java" de gcc), mais je ne sais pas jusqu'à quel point c'est encore du java (jamais essayé) : que se passe-t-il par exemple si on veut charger une classe dynamiquement ?
Je ne vois pas où est le problème avec l'installation de java : si
tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple)
J'ai le même problème au boulot ! En attendant d'aller pleurer aux
ressources infos, je me suis rabattu sur openwatcom et python, qui
veulent bien s'installer ! :-)
Disons que l'exe est plutot une version portable qui n'installe pas
jre sur la machine.
Ça, ça dépend ! (cf la fin du message)
Quand a la course de vitesse, je suis pas specialement interessé. Tant
que ca rame pas, ca me va.
Juste un conseil alors : regarde ce qu'affiche "java -version".
Si c'est "Java HotSpot(TM) Client VM" : démarrage rapide, mais programme
lent ensuite. Si c'est "Java HotSpot(TM) Server VM" : démarrage lent,
mais après ça va plus vite. Pour changer, tu utilises "java -client" ou
"java -server". Sur un OS 64 bits tu n'as pas le choix, c'est toujours
"server". Sans courir après les cycles cpu, on peut améliorer un
peu l'ordinaire, ça ne fait pas de mal ! :-)
De toute facon je pars sur une version jar, bin (pour linux) et exe
pour avoir le choix.
Les solutions usuelles qui fournissent un .exe ne donnent pas
des programmes "natifs", mais un exe qui appelle le JRE pour
lancer le programme. C'est juste pour faire "joli" sous windows
ou macosx. Tu as donc besoin du JRE quoi qu'il arrive.
Pour du code natif, en principe gcj fait cela (c'est le morceau
"java" de gcc), mais je ne sais pas jusqu'à quel point
c'est encore du java (jamais essayé) : que se passe-t-il par
exemple si on veut charger une classe dynamiquement ?
On Mon, 29 Sep 2008 22:59:44 +0200, Jean-Claude Arbaut wrote:
Je ne vois pas où est le problème avec l'installation de java : si tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple)
J'ai le même problème au boulot ! En attendant d'aller pleurer aux ressources infos, je me suis rabattu sur openwatcom et python, qui veulent bien s'installer ! :-)
Disons que l'exe est plutot une version portable qui n'installe pas jre sur la machine.
Ça, ça dépend ! (cf la fin du message)
Quand a la course de vitesse, je suis pas specialement interessé. Tant que ca rame pas, ca me va.
Juste un conseil alors : regarde ce qu'affiche "java -version". Si c'est "Java HotSpot(TM) Client VM" : démarrage rapide, mais programme lent ensuite. Si c'est "Java HotSpot(TM) Server VM" : démarrage lent, mais après ça va plus vite. Pour changer, tu utilises "java -client" ou "java -server". Sur un OS 64 bits tu n'as pas le choix, c'est toujours "server". Sans courir après les cycles cpu, on peut améliorer un peu l'ordinaire, ça ne fait pas de mal ! :-)
De toute facon je pars sur une version jar, bin (pour linux) et exe pour avoir le choix.
Les solutions usuelles qui fournissent un .exe ne donnent pas des programmes "natifs", mais un exe qui appelle le JRE pour lancer le programme. C'est juste pour faire "joli" sous windows ou macosx. Tu as donc besoin du JRE quoi qu'il arrive.
Pour du code natif, en principe gcj fait cela (c'est le morceau "java" de gcc), mais je ne sais pas jusqu'à quel point c'est encore du java (jamais essayé) : que se passe-t-il par exemple si on veut charger une classe dynamiquement ?
http://gcc.gnu.org/java/
Jean Bon (de Parme)
On Tue, 30 Sep 2008 00:26:43 +0200, Jean-Claude Arbaut wrote:
Jean Bon (de Parme) wrote:
On Mon, 29 Sep 2008 22:59:44 +0200, Jean-Claude Arbaut wrote:
Je ne vois pas où est le problème avec l'installation de java : si tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple)
J'ai le même problème au boulot ! En attendant d'aller pleurer aux ressources infos, je me suis rabattu sur openwatcom et python, qui veulent bien s'installer ! :-)
Le probleme c'est pas que l'installation avec les droit, mais c'est interdit par la charte, par contre rien n'interdit de brancher la clé usb avec un executable dessus qui n'install rien sur la machine...
Disons que l'exe est plutot une version portable qui n'installe pas jre sur la machine.
Ça, ça dépend ! (cf la fin du message)
Quand a la course de vitesse, je suis pas specialement interessé. Tant que ca rame pas, ca me va.
Juste un conseil alors : regarde ce qu'affiche "java -version". Si c'est "Java HotSpot(TM) Client VM" : démarrage rapide, mais programme lent ensuite. Si c'est "Java HotSpot(TM) Server VM" : démarrage lent, mais après ça va plus vite. Pour changer, tu utilises "java -client" ou "java -server". Sur un OS 64 bits tu n'as pas le choix, c'est toujours "server". Sans courir après les cycles cpu, on peut améliorer un peu l'ordinaire, ça ne fait pas de mal ! :-)
Ok
De toute facon je pars sur une version jar, bin (pour linux) et exe pour avoir le choix.
Les solutions usuelles qui fournissent un .exe ne donnent pas des programmes "natifs", mais un exe qui appelle le JRE pour lancer le programme. C'est juste pour faire "joli" sous windows ou macosx. Tu as donc besoin du JRE quoi qu'il arrive.
Pour du code natif, en principe gcj fait cela (c'est le morceau "java" de gcc), mais je ne sais pas jusqu'à quel point c'est encore du java (jamais essayé) : que se passe-t-il par exemple si on veut charger une classe dynamiquement ?
http://gcc.gnu.org/java/
J'avais cru comprendre que l'exe etait accompagné d'une enorme dll pour le rendre autonome.
Je ne vois pas où est le problème avec l'installation de java : si
tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple)
J'ai le même problème au boulot ! En attendant d'aller pleurer aux
ressources infos, je me suis rabattu sur openwatcom et python, qui
veulent bien s'installer ! :-)
Le probleme c'est pas que l'installation avec les droit, mais c'est
interdit par la charte, par contre rien n'interdit de brancher la clé
usb avec un executable dessus qui n'install rien sur la machine...
Disons que l'exe est plutot une version portable qui n'installe pas
jre sur la machine.
Ça, ça dépend ! (cf la fin du message)
Quand a la course de vitesse, je suis pas specialement interessé. Tant
que ca rame pas, ca me va.
Juste un conseil alors : regarde ce qu'affiche "java -version".
Si c'est "Java HotSpot(TM) Client VM" : démarrage rapide, mais programme
lent ensuite. Si c'est "Java HotSpot(TM) Server VM" : démarrage lent,
mais après ça va plus vite. Pour changer, tu utilises "java -client" ou
"java -server". Sur un OS 64 bits tu n'as pas le choix, c'est toujours
"server". Sans courir après les cycles cpu, on peut améliorer un
peu l'ordinaire, ça ne fait pas de mal ! :-)
Ok
De toute facon je pars sur une version jar, bin (pour linux) et exe
pour avoir le choix.
Les solutions usuelles qui fournissent un .exe ne donnent pas
des programmes "natifs", mais un exe qui appelle le JRE pour
lancer le programme. C'est juste pour faire "joli" sous windows
ou macosx. Tu as donc besoin du JRE quoi qu'il arrive.
Pour du code natif, en principe gcj fait cela (c'est le morceau
"java" de gcc), mais je ne sais pas jusqu'à quel point
c'est encore du java (jamais essayé) : que se passe-t-il par
exemple si on veut charger une classe dynamiquement ?
http://gcc.gnu.org/java/
J'avais cru comprendre que l'exe etait accompagné d'une enorme dll
pour le rendre autonome.
On Tue, 30 Sep 2008 00:26:43 +0200, Jean-Claude Arbaut wrote:
Jean Bon (de Parme) wrote:
On Mon, 29 Sep 2008 22:59:44 +0200, Jean-Claude Arbaut wrote:
Je ne vois pas où est le problème avec l'installation de java : si tu souhaites programmer en java, tu vas de toute façon en avoir besoin,
Sur certain PC, on ne peut pas installer java (boulot par exemple)
J'ai le même problème au boulot ! En attendant d'aller pleurer aux ressources infos, je me suis rabattu sur openwatcom et python, qui veulent bien s'installer ! :-)
Le probleme c'est pas que l'installation avec les droit, mais c'est interdit par la charte, par contre rien n'interdit de brancher la clé usb avec un executable dessus qui n'install rien sur la machine...
Disons que l'exe est plutot une version portable qui n'installe pas jre sur la machine.
Ça, ça dépend ! (cf la fin du message)
Quand a la course de vitesse, je suis pas specialement interessé. Tant que ca rame pas, ca me va.
Juste un conseil alors : regarde ce qu'affiche "java -version". Si c'est "Java HotSpot(TM) Client VM" : démarrage rapide, mais programme lent ensuite. Si c'est "Java HotSpot(TM) Server VM" : démarrage lent, mais après ça va plus vite. Pour changer, tu utilises "java -client" ou "java -server". Sur un OS 64 bits tu n'as pas le choix, c'est toujours "server". Sans courir après les cycles cpu, on peut améliorer un peu l'ordinaire, ça ne fait pas de mal ! :-)
Ok
De toute facon je pars sur une version jar, bin (pour linux) et exe pour avoir le choix.
Les solutions usuelles qui fournissent un .exe ne donnent pas des programmes "natifs", mais un exe qui appelle le JRE pour lancer le programme. C'est juste pour faire "joli" sous windows ou macosx. Tu as donc besoin du JRE quoi qu'il arrive.
Pour du code natif, en principe gcj fait cela (c'est le morceau "java" de gcc), mais je ne sais pas jusqu'à quel point c'est encore du java (jamais essayé) : que se passe-t-il par exemple si on veut charger une classe dynamiquement ?
http://gcc.gnu.org/java/
J'avais cru comprendre que l'exe etait accompagné d'une enorme dll pour le rendre autonome.
Emmanuel Bourg
Jean-Claude Arbaut a écrit :
le voit par exemple avec Scilab 5 ou SAS, ou simplement l'installation est laissée à l'utilisateur, et ça se fait en quelques clics sur java.sun.com. Et quelques clics de plus pour configurer le PATH.
Un petit détail, n'envoyez pas les utilisateurs sur java.sun.com pour télécharger le JRE, le site est plutôt dédié à des développeurs et pour un néophyte c'est pas évident de s'y retrouver. Sun a mis en place un autre site orienté grand public pour télécharger le JRE :
http://java.com
Jean-Claude Arbaut a écrit :
le voit par exemple avec Scilab 5 ou SAS, ou simplement l'installation
est laissée à l'utilisateur, et ça se fait en quelques clics sur
java.sun.com. Et quelques clics de plus pour configurer le PATH.
Un petit détail, n'envoyez pas les utilisateurs sur java.sun.com pour
télécharger le JRE, le site est plutôt dédié à des développeurs et pour
un néophyte c'est pas évident de s'y retrouver. Sun a mis en place un
autre site orienté grand public pour télécharger le JRE :
le voit par exemple avec Scilab 5 ou SAS, ou simplement l'installation est laissée à l'utilisateur, et ça se fait en quelques clics sur java.sun.com. Et quelques clics de plus pour configurer le PATH.
Un petit détail, n'envoyez pas les utilisateurs sur java.sun.com pour télécharger le JRE, le site est plutôt dédié à des développeurs et pour un néophyte c'est pas évident de s'y retrouver. Sun a mis en place un autre site orienté grand public pour télécharger le JRE :
