Je cherche un outil libre sous Linux et/ou Windows, de préférence au
moins Linux, qui permette de créer des exécutables autonomes en Java. Il
me faudrait donc un compilateur Java vers du code directement exécutable
qui puisse intégrer dans l'exécutable les ressources utiles au
programme (images, sons, textes...)
Même si cela est indépendant de la question, je précise que le but n'est
pas de "cacher" les sources et ressources des programmes, qui seront
libres et publiées par ailleurs. Il s'agit simplement de faire des
programmes qui se résument à un unique fichier exécutable, sans
nécessité d'installation ni de désarchivage.
Merci d'avance de vos conseils.
[CITATION ALÉATOIRE : Le bonheur humain est composé de tant de pièces
qu'il en manque toujours. Bossuet]
--
Pierre Crescenzo
mailto:Pierre@crescenzo.nom.fr
http://www.crescenzo.nom.fr/
Je ne connais que peu de programme qui ont un seul et unique fichier qui est l'exécutable.
MacOS (<X) utilisait des fichiers applications contenant tout dans le "resources fork": code binaire (éventuellement PPC+68000), templates de dialogues, chaînes, icônes et autres éléments de GUI, sons, infos sur la version, signatures de l'application et des documents, etc.... [MacOS X doit sûrement avoir un principe du même genre, caché par l'OS]
Bingo, c'est le fameux "peu" ! Mais les .app sont des répertoires dont le contenu est cachés par le système et représenté sous la forme d'un simple fichier exécutable. C'est un ancien format (plutôt bien fait) qui provient de son ancètre cher au coeur de steve : NextStep ! Ah les joies d'Interface Builder :) Mais je digresse ....
A priori NTFS gère les streams, dont pourrait faire la même chose - si leur utilisation était normalisée et standardisée par l'OS. Mais c'est très peu utilisé à ma connaissance.
Stream ? Probablement aussi utilisé que les junctions, ce qui doit faire peur dans les chaumières de redmont ;-)
Tiens, je me demandais qui pouvait bien en utiliser sur mon disque alors j'y ai passé un coup de LNS, résultat : des .lnk, des thumbs.db et enfin un .exe dans le répertoire spécial "System Volume Information", ya pas vraiment foule...
A+
TM
Bonsoir,
Laurent Pointal wrote:
TestMan wrote:
Je ne connais que peu de programme qui ont un seul et unique fichier qui
est l'exécutable.
MacOS (<X) utilisait des fichiers applications contenant tout dans le
"resources fork": code binaire (éventuellement PPC+68000), templates de
dialogues, chaînes, icônes et autres éléments de GUI, sons, infos sur la
version, signatures de l'application et des documents, etc....
[MacOS X doit sûrement avoir un principe du même genre, caché par l'OS]
Bingo, c'est le fameux "peu" ! Mais les .app sont des répertoires dont
le contenu est cachés par le système et représenté sous la forme d'un
simple fichier exécutable. C'est un ancien format (plutôt bien fait) qui
provient de son ancètre cher au coeur de steve : NextStep ! Ah les joies
d'Interface Builder :) Mais je digresse ....
A priori NTFS gère les streams, dont pourrait faire la même chose - si
leur utilisation était normalisée et standardisée par l'OS. Mais c'est
très peu utilisé à ma connaissance.
Stream ? Probablement aussi utilisé que les junctions, ce qui doit faire
peur dans les chaumières de redmont ;-)
Tiens, je me demandais qui pouvait bien en utiliser sur mon disque alors
j'y ai passé un coup de LNS, résultat : des .lnk, des thumbs.db et enfin
un .exe dans le répertoire spécial "System Volume Information", ya pas
vraiment foule...
Je ne connais que peu de programme qui ont un seul et unique fichier qui est l'exécutable.
MacOS (<X) utilisait des fichiers applications contenant tout dans le "resources fork": code binaire (éventuellement PPC+68000), templates de dialogues, chaînes, icônes et autres éléments de GUI, sons, infos sur la version, signatures de l'application et des documents, etc.... [MacOS X doit sûrement avoir un principe du même genre, caché par l'OS]
Bingo, c'est le fameux "peu" ! Mais les .app sont des répertoires dont le contenu est cachés par le système et représenté sous la forme d'un simple fichier exécutable. C'est un ancien format (plutôt bien fait) qui provient de son ancètre cher au coeur de steve : NextStep ! Ah les joies d'Interface Builder :) Mais je digresse ....
A priori NTFS gère les streams, dont pourrait faire la même chose - si leur utilisation était normalisée et standardisée par l'OS. Mais c'est très peu utilisé à ma connaissance.
Stream ? Probablement aussi utilisé que les junctions, ce qui doit faire peur dans les chaumières de redmont ;-)
Tiens, je me demandais qui pouvait bien en utiliser sur mon disque alors j'y ai passé un coup de LNS, résultat : des .lnk, des thumbs.db et enfin un .exe dans le répertoire spécial "System Volume Information", ya pas vraiment foule...
A+
TM
TestMan
Bonsoir,
flipouk wrote:
TestMan wrote:
Je ne connais que peu de programme qui ont un seul et unique fichier qui est l'exécutable. En tout cas pas sous Linux, surtout s'il faut des
Sous Linux, le JDK et Netbeans sont livrés sous la forme d'un seul et unique fichier .bin
Ce sont des fichiers auto extractibles il me semble ... une variante plus performante du shar en somme.
Ce n'est donc pas vraiment différent d'un msi windows par exemple. Sauf, que le MSI si je ne me trompe gère des choses en plus : désinstalable, configurable en externe pour un déploiement en masse ...
Mais ci ça lui convient, alors dans la série des instaleurs Java qui génère un .exe avec ou sans VM : il y a foule, et une petite recherche dans ce forum s'imposerait :)
A+
TM
Bonsoir,
flipouk wrote:
TestMan wrote:
Je ne connais que peu de programme qui ont un seul et unique fichier
qui est l'exécutable. En tout cas pas sous Linux, surtout s'il faut des
Sous Linux, le JDK et Netbeans sont livrés sous la forme d'un seul et
unique fichier .bin
Ce sont des fichiers auto extractibles il me semble ... une variante
plus performante du shar en somme.
Ce n'est donc pas vraiment différent d'un msi windows par exemple. Sauf,
que le MSI si je ne me trompe gère des choses en plus : désinstalable,
configurable en externe pour un déploiement en masse ...
Mais ci ça lui convient, alors dans la série des instaleurs Java qui
génère un .exe avec ou sans VM : il y a foule, et une petite recherche
dans ce forum s'imposerait :)
Je ne connais que peu de programme qui ont un seul et unique fichier qui est l'exécutable. En tout cas pas sous Linux, surtout s'il faut des
Sous Linux, le JDK et Netbeans sont livrés sous la forme d'un seul et unique fichier .bin
Ce sont des fichiers auto extractibles il me semble ... une variante plus performante du shar en somme.
Ce n'est donc pas vraiment différent d'un msi windows par exemple. Sauf, que le MSI si je ne me trompe gère des choses en plus : désinstalable, configurable en externe pour un déploiement en masse ...
Mais ci ça lui convient, alors dans la série des instaleurs Java qui génère un .exe avec ou sans VM : il y a foule, et une petite recherche dans ce forum s'imposerait :)
A+
TM
Pierre Crescenzo
Bonsoir,
Je ne connais que peu de programme qui ont un seul et unique fichier qui est l'exécutable. En tout cas pas sous Linux, surtout s'il faut des bibliotheques, des resources et des fichiers de config ;-) En clair, si l'on a fait des systèmes d'installation pour les clients lours, c'est pour une raison bien précise : gérer complexité d'intégration avec l'environment.
Je suis d'accord avec cela. Et tout le reste de l'argumentation. Mais cela ne répond en rien à ma question, qui est purement technique...
Si je comprend bien, votre demande se décompose en : - outil de développement opensource
gcj peut me convenir.
- outil de déploiment
Non. Puisqu'il n'y aura rien à déployer. (C'est justement un des intérêts du l'exécutable unique et autonome.)
- partage des sources
Oui, les éventuels produits seront en (L)GPL. Les sources seront diffusés par ailleurs, par exemple sur un site Web.
Le contexte et les conditions sont particuliers et sévères, j'en conviens depuis le début. Mais, sinon, je saurais faire... :-)
Merci.
[CITATION ALÉATOIRE : C'est dans le mépris de l'ambition que doit se trouver l'un des principes essentiels de bonheur sur la Terre. Edgar Allan Poe]
-- Pierre Crescenzo mailto: http://www.crescenzo.nom.fr/
Bonsoir,
Je ne connais que peu de programme qui ont un seul et unique fichier
qui est l'exécutable. En tout cas pas sous Linux, surtout s'il faut
des bibliotheques, des resources et des fichiers de config ;-) En
clair, si l'on a fait des systèmes d'installation pour les clients
lours, c'est pour une raison bien précise : gérer complexité
d'intégration avec l'environment.
Je suis d'accord avec cela. Et tout le reste de l'argumentation. Mais
cela ne répond en rien à ma question, qui est purement technique...
Si je comprend bien, votre demande se décompose en :
- outil de développement opensource
gcj peut me convenir.
- outil de déploiment
Non. Puisqu'il n'y aura rien à déployer. (C'est justement un des
intérêts du l'exécutable unique et autonome.)
- partage des sources
Oui, les éventuels produits seront en (L)GPL. Les sources seront
diffusés par ailleurs, par exemple sur un site Web.
Le contexte et les conditions sont particuliers et sévères, j'en
conviens depuis le début. Mais, sinon, je saurais faire... :-)
Merci.
[CITATION ALÉATOIRE : C'est dans le mépris de l'ambition que doit se
trouver l'un des principes essentiels de bonheur sur la Terre. Edgar
Allan Poe]
--
Pierre Crescenzo
mailto:Pierre@crescenzo.nom.fr
http://www.crescenzo.nom.fr/
Je ne connais que peu de programme qui ont un seul et unique fichier qui est l'exécutable. En tout cas pas sous Linux, surtout s'il faut des bibliotheques, des resources et des fichiers de config ;-) En clair, si l'on a fait des systèmes d'installation pour les clients lours, c'est pour une raison bien précise : gérer complexité d'intégration avec l'environment.
Je suis d'accord avec cela. Et tout le reste de l'argumentation. Mais cela ne répond en rien à ma question, qui est purement technique...
Si je comprend bien, votre demande se décompose en : - outil de développement opensource
gcj peut me convenir.
- outil de déploiment
Non. Puisqu'il n'y aura rien à déployer. (C'est justement un des intérêts du l'exécutable unique et autonome.)
- partage des sources
Oui, les éventuels produits seront en (L)GPL. Les sources seront diffusés par ailleurs, par exemple sur un site Web.
Le contexte et les conditions sont particuliers et sévères, j'en conviens depuis le début. Mais, sinon, je saurais faire... :-)
Merci.
[CITATION ALÉATOIRE : C'est dans le mépris de l'ambition que doit se trouver l'un des principes essentiels de bonheur sur la Terre. Edgar Allan Poe]
-- Pierre Crescenzo mailto: http://www.crescenzo.nom.fr/
