Quand compileriez-vous un service Java en image native, et qu'y perdez-vous ?

L'image native convient aux charges où le temps de démarrage et la mémoire dominent : fonctions serverless, outils en ligne de commande et services qui descendent à zéro, puisqu'elle démarre en millisecondes sans chauffe et avec une empreinte bien plus petite. Le coût est une hypothèse de monde fermé, donc la réflexion, les proxys dynamiques et le chargement de ressources doivent être connus à la construction, les builds sont lents, et le débit de pointe peut être inférieur à ce que le JIT atteint sur un processus de longue durée.

J'y vais quand le temps de démarrage est sur le chemin critique. Une fonction qui s'exécute deux cents millisecondes ne peut pas se permettre une JVM qui met trois secondes à démarrer et une minute de plus à chauffer, et le même argument vaut pour un outil en ligne de commande ou un service qui descend à zéro entre deux vagues de trafic. La mémoire est l'autre gain, puisqu'une image native peut tourner dans une fraction du tas. Ce que vous perdez, c'est le dynamisme. La compilation anticipée suppose un monde fermé, donc tout ce qui est découvert à l'exécution, réflexion, proxys dynamiques, chargement de services, bundles de ressources, doit être déclaré à la construction. Les frameworks modernes génèrent l'essentiel de cette configuration pour vous pendant leur étape de build, mais une bibliothèque qui fait quelque chose de malin à l'exécution échouera d'une façon qui n'apparaît que dans le binaire natif, donc la suite de tests doit tourner contre l'image aussi. Les builds prennent aussi des minutes plutôt que des secondes, et l'outillage d'observabilité est moins mûr. Pour un service de longue durée avec un trafic régulier je reste sur la JVM, parce que le JIT finit par battre le code compilé à l'avance sur le débit de pointe.