Dans Java ARchive, c'est archive que t'as pas compris?
J'ose penser que je comprends à peut prêt la signification de Java ARchive. J'irai même jusqu'à penser que je sais même exactement comment ca marche, sa spécification et les problèmes qui existe.
Connais tu une seule extension qui selon le DE t'envoie soit l'éditeur soit exécute le fichier?
Nautilus par exemple ? Un .sh qui n'a pas de bit exécutable est ouvert dans un éditeur de texte. Si le bit exécutable est présent un pop-up te propose ce que tu veux faire. C'est aussi vrai pour les .py
Pour un JAR ca peut être exactement la même chose. Exécuter un script python qui n'a pas de main n'a pas plus de sens que lancer un JAR qui n'a pas de Main-Class spécifiée.
Maintenant le problème des JAR est double. D'une part il ne rentre pas du tout dans le mécanisme de loader d'UNIX, tel qu'implémenté actuellement. Son côté dynamique étant limité au shebang. Si ton format de fichier ne permet pas le shebang (fichier binaire), alors le travail doit être fait par l'userland (donc le DE) plutôt par le noyau dans l'execve. On pourrait étendre le mécanisme de binfmt soit en rajoutant explicitement le support pour un magic number donné, soit un branchant un mécanisme extensible (voir binfmt_misc par exemple). Le deuxième problème du JAR est que son type n'est pas identifiable par un magic number, il l'est uniquement par son extension et la présence d'un fichier Manifest.
Tu noteras aussi que dans mes autres commentaire que j'indique que lancer un simple java -jar archive ne résout pas tout les problèmes. Pour un jeu ca peut le faire (et encore ca veut dire que tu n'es pas pleinement standalone puisque tu supposes que le client à un JRE en bonne version d'installé), mais pour la plupart des applis il faut de toute façon un lanceur pour gérer l'intégration. Maintenant je dis juste que je trouve profondément stupide l'argumentation utilisant le fait que le nom d'un format contienne "archive".
[^] # Re: mon grain de sel
Posté par ckyl . En réponse au journal Write once, run anywhere qu'il disait. Évalué à 6.
J'ose penser que je comprends à peut prêt la signification de Java ARchive. J'irai même jusqu'à penser que je sais même exactement comment ca marche, sa spécification et les problèmes qui existe.
Je pense que tu peux relire la spécification
Nautilus par exemple ? Un .sh qui n'a pas de bit exécutable est ouvert dans un éditeur de texte. Si le bit exécutable est présent un pop-up te propose ce que tu veux faire. C'est aussi vrai pour les .py
Pour un JAR ca peut être exactement la même chose. Exécuter un script python qui n'a pas de main n'a pas plus de sens que lancer un JAR qui n'a pas de Main-Class spécifiée.
Maintenant le problème des JAR est double. D'une part il ne rentre pas du tout dans le mécanisme de loader d'UNIX, tel qu'implémenté actuellement. Son côté dynamique étant limité au shebang. Si ton format de fichier ne permet pas le shebang (fichier binaire), alors le travail doit être fait par l'userland (donc le DE) plutôt par le noyau dans l'execve. On pourrait étendre le mécanisme de binfmt soit en rajoutant explicitement le support pour un magic number donné, soit un branchant un mécanisme extensible (voir binfmt_misc par exemple). Le deuxième problème du JAR est que son type n'est pas identifiable par un magic number, il l'est uniquement par son extension et la présence d'un fichier Manifest.
Tu noteras aussi que dans mes autres commentaire que j'indique que lancer un simple java -jar archive ne résout pas tout les problèmes. Pour un jeu ca peut le faire (et encore ca veut dire que tu n'es pas pleinement standalone puisque tu supposes que le client à un JRE en bonne version d'installé), mais pour la plupart des applis il faut de toute façon un lanceur pour gérer l'intégration. Maintenant je dis juste que je trouve profondément stupide l'argumentation utilisant le fait que le nom d'un format contienne "archive".