Nouvelle spécification pour le lanceur en ligne de commande abstrasyc
Remplacement de l'ancien lanceur abstrasyc par une version plus légère et plus rapide.
Blueprint information
- Status:
- Complete
- Approver:
- Luc Bruninx
- Priority:
- Medium
- Drafter:
- Luc Bruninx
- Direction:
- Approved
- Assignee:
- Luc Bruninx
- Definition:
- Approved
- Series goal:
- Accepted for 1.0
- Implementation:
- Implemented
- Milestone target:
- abstrasy-1.0.6338.0
- Started by
- Luc Bruninx
- Completed by
- Luc Bruninx
Related branches
Related bugs
Sprints
Whiteboard
La version du lanceur abstrasyc utilisé jusqu'à présent (rev-6336) est écrit en langage Python (un langage très répandu et pré-installé sur Linux). Ce lanceur était conçu pour répondre à une stratégie "pessimiste". En effet, on considérait que le cas le plus fréquent serait l'absence d'une jvm compatible ou la mauvaise configuration du système (qui ne proposerait par exemple pas par défaut une jvm à jour).
L'avantage de cette stratégie, c'est qu'elle permet de lancer une application Java sur un système mal configuré ou la jvm proposée par défaut n'est pas suffisamment à jour (ou n'est pas compatible jvm d'Oracle ou l'OpenJDK). Ce script de lancement est donc très robuste.
Cependant, cet avantage entraîne un coût important en ressources et en temps. En effet, ce script recherche systématiquement la meilleure jvm. Pour cela, il doit non seulement les trouver, mais aussi les tester une à une pour obtenir leur version respective. De ce fait, plus il y a de jvm installées et plus il faut faire de tests.
Pour tester une jvm, il faut exécuter la commande "java -version" et analyser la sortie sur le stderr ("java -version" ne retourne pas son message d'accueil sur stdout, mais bien sur stderr). Donc, dans le meilleur des cas, s'il n'y a qu'une seule jvm et que c'est la bonne, il faut la lancer 2 fois pour exécuter un script: (1) une première fois pour vérifier sa version et (2) une deuxième pour exécuter le script. Ceci est assez lourd d'autant plus que nous utilisons Python (pour plus de souplesse) qui n'est pas l'interpréteur le plus léger.
Ce n'est donc pas la solution idéale pour lancer un interpréteur de scripts en ligne de commande.
Nous proposons donc à présent un nouveau lanceur dont la stratégie est résolument "optimiste".
En considérant que la jvm installée par défaut sur le système est compatible, on évite tous les tests et on peut déjà dans le meilleur des cas lancer beaucoup plus rapidement l'exécution du script cible.
Par ailleurs, il est possible d'utiliser un langage de script plus léger que Python. On propose donc d'utiliser simplement sh. Très souvent, sh est déjà chargé pour implémenter le terminal. Il ne consomme pas beaucoup de ressources et est suffisant pour concevoir un lanceur efficace selon notre nouvelle stratégie.
Work Items
Work items:
Beta version disponible: http://
Documentation de la commande : DONE