Je ne sais pas si cela serait géré exactement de la même manière pour Webstart, mais nous avons rencontré cette situation dans une application de bureau lorsque nous traitions avec un ensemble de bibliothèques natives (dll dans notre cas).
Le chargement de libA avant libB devrait fonctionner, sauf si l'une de ces bibliothèques a une dépendance qui n'est pas prise en compte et qui n'est pas dans le chemin. Ma compréhension est qu'une fois qu'il arrive à un appel système loadLibrary (c'est-à-dire que Java a trouvé la bibliothèque dans son java.library.path et dit maintenant au système d'exploitation de la charger) - il dépend complètement du système d'exploitation pour trouver toutes les bibliothèques dépendantes , car à ce stade, c'est le système d'exploitation qui charge la bibliothèque pour le processus, et le système d'exploitation ne sait que regarder dans le chemin du système. Cela semble difficile à définir dans le cas d'une application Webstart, mais il existe un moyen de contourner cela qui n'implique pas de compilation statique. Vous pourrez peut-être mélanger où se trouvent vos bibliothèques - je ne suis pas sûr
Si vous utilisez un chargeur de classe personnalisé, vous pouvez remplacer loadLibrary et findLibrary afin qu'il puisse localiser vos bibliothèques à partir d'un jar dans votre chemin de classe, et si vous lui faites également prendre conscience de vos dépendances de bibliothèque natives (c'est-à-dire que libB dépend de libA dépend sur libX, alors lors du chargement de libB, vous pouvez vous rattraper et vous assurer de charger libA en premier, et en vérifiant cet avis et en chargeant libX en premier. Ensuite, le système d'exploitation n'essaie pas de trouver une bibliothèque qui n'est pas dans votre chemin. C'est maladroit et un peu pénible, mais s'assurer que Java les trouve et les charge tous dans le bon ordre peut fonctionner.
