Voici l'arrière-plan du problème sous-jacent, je collabore avec un groupe sur un projet qui utilise les bibliothèques Swt
et j'essaye de préparer le logiciel pour le déploiement. Comme il se avère SWT
est très dépendante de la plate-forme/architecture. Je voudrais pouvoir emballer tous les six jar
s (linux, mac, win et 32/64-bit) dans le même paquet et utiliser la bibliothèque appropriée selon le système. Je me rends compte que c'est un défi difficile cependant, passer à Swing
(ou toute autre chose) n'est pas vraiment une option en ce moment.Problèmes de chargement des ressources lors de l'exécution
J'ai trouvé un certain nombre de sujets pertinents (@Aaron Digulla's thread et @mchr's thread) qui m'ont fourni des informations précieuses sur le problème rencontré. J'ai essayé de mettre en œuvre la solution proposée par @Alexey Romanov here. Avec une différence, comme la méthode loadSwtJar()
qu'il propose n'est pas statique, j'instancie l'objet, et immédiatement après cela, exécutez la méthode avant toute autre chose à l'objet.
Il apparaît que la procédure de chargement ne fonctionne pas correctement. Mon raisonnement pour cette déclaration est la suivante:
- Si tous
Swt
pots sont retirés de la classpath du fichier jar exécutable, puisException in thread "main" java.lang.NoClassDefFoundError: org/eclipse/swt/events/MouseListener
est jeté qui est causée par:java.lang.ClassNotFoundException: org.eclipse.swt.events.MouseListener
pour moi, cela signifie que les bibliothèques ne sont pas trouvées sur classpath, je me trompe?
- Si
swt
jars sont laissés sur le chemin de classe, le premier fichier jar est utilisé par le système pendant l'exécution. Cela signifie que si gtk-linux-x86_64 se trouve être le premier pot swt sur la liste des pots, alors le système essaye de l'utiliser, peu importe si le système est win32 ou Mac OSX.
J'ai essayé d'ajouter une sortie pour voir si la méthode loadSwtJar()
est de choisir le pot droit, et la sortie semble à droite sur toutes les plates-formes que je l'ai essayé, comme dans le bon paquet est sélectionné (et les fichiers existent-ils dans le pot runnable). Mais la bonne bibliothèque n'est pas chargée donc des erreurs d'exécution se produisent: Exception in thread "main" java.lang.reflect.InvocationTargetException
causé par par ex: Caused by: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM
(Notez que c'est l'erreur que je reçois sur ma machine Linux si je change l'ordre d'apparition de 64 bits et 32 bits swt bibliothèques sur le fichier build.xml
)
Alors, quel semble être le problème ici? Ai-je manqué certains détails, ou est-il simplement impossible de vérifier les propriétés du système et de charger une bibliothèque appropriée en conséquence?
Enfin ci-dessous est un extrait de mon fichier de construction, pensé qu'il pourrait aider à trouver la source du problème.
Merci à l'avance,
EDIT: Après une longue session de débogage avec un collègue, le problème est résolu (à l'exception d'un bug gênant en ce qui concerne la gestion des threads sur MacOS comme je l'ai mentionné here). Il s'agissait de peaufiner avec la construction ANT ainsi que la façon dont la classe principale a été écrite.(La classe principale, en fin de compte, étendait les références de la bibliothèque SWT ce qui signifiait que le code ne compilerait pas du tout, encapsulerait la classe principale avec une autre classe et chargerait les jarres SWT qui semblaient être assez pour résoudre le problème)
Merci à tous ceux qui ont contribué, en particulier @Aaron. Vraiment apprécié!
Merci Aaron. Je dois dire que je ne suis pas très sûr de la façon dont vous creusez pour trouver les swtFiles, avez-vous vos fichiers swt dans un grand pot avec toutes les autres dépendances ou d'une autre manière? – posdef
@Aaron: une autre question, avez-vous rencontré des problèmes avec les paquets SWT non signés? ou est-ce juste moi ... – posdef
@posdef: J'ai mis tous les fichiers JAR normaux dans un répertoire appelé 'lib /' et les six fichiers JAR SWT dans 'swt /'. Si vous les mettez tous dans un répertoire, il est probable que le chemin de classe du manifeste du JAR principal tentera de charger le mauvais. –