En gros les gens espèrent récupérer les bonnes propriétés des machines virtuelles Java optimisées à mort : compilation JIT optimisée à mort, et runtime qui supporte bien le parallélisme multi-thread (alors que les implémentations maisons reposent souvent sur un Big Interpreter Lock et ne peuvent donc faire que du parallélisme multi-process). Tant mieux si tu as en plus accès aux librairies Java (mais en pratique les interfaces sont tellement différentes que ça n'est pas si commode), aux outils qui travaillent directement sur le bytecode (test de sécurité ou de bugs, instrumentation etc.).
C'est partiellement liés aux raisons que les gens de Google ont utilisé quand ils ont écrit Gerrit, une implémentation d'un logiciel de revue de code basée sur un backend Git: au lieu de prendre l'implémentation Git officielle en C, ils utilisent une ré-implémentation de Git en java, JGit, parce qu'ils préfèrent administrer des trucs qui tournent sur la JVM.
[^] # Re: Utilité ?
Posté par gasche . En réponse à la dépêche JRuby 1.7.0. Évalué à 4.
En gros les gens espèrent récupérer les bonnes propriétés des machines virtuelles Java optimisées à mort : compilation JIT optimisée à mort, et runtime qui supporte bien le parallélisme multi-thread (alors que les implémentations maisons reposent souvent sur un Big Interpreter Lock et ne peuvent donc faire que du parallélisme multi-process). Tant mieux si tu as en plus accès aux librairies Java (mais en pratique les interfaces sont tellement différentes que ça n'est pas si commode), aux outils qui travaillent directement sur le bytecode (test de sécurité ou de bugs, instrumentation etc.).
C'est partiellement liés aux raisons que les gens de Google ont utilisé quand ils ont écrit Gerrit, une implémentation d'un logiciel de revue de code basée sur un backend Git: au lieu de prendre l'implémentation Git officielle en C, ils utilisent une ré-implémentation de Git en java, JGit, parce qu'ils préfèrent administrer des trucs qui tournent sur la JVM.