Hallo zusammen,
... ich hoffe, in meinem ersten Posting hier frage ich nicht direkt nach etwas, was eh schon bekannt ist & hier schon wer-weiss-wie-oft behandelt wurde - zumind. über die Board-Suche habe ich nur einen Thread gefunden, der hierzu zu passen schien, in diesem gab es aber leider auch keine Lösung dafür. Also frag ich nochmal selbst... :wink:
Ich habe folgendes Problem: ich bin hier gerade dabei, eine original mit AWT/Swing entwickelte Applikation auf SWT umzustellen (... nicht fragen, warum - Cheffe wollte das so... :wink: ), und dabei stosse ich gerade auf folgendes Problem: die Applikation verarbeitet bestimmte "Modelle", die bisher natürlich nur für die AWT/Swing - Variante entwickelt wurden. Diese "alten" Modelle sollen auch weiterhin in der SWT-Variante zu benutzen sein. Unter anderem sind in diesen Modellen auch Menü-Einträge definiert, die beim Laden eines Modells dynamisch mit in die Menüstruktur des Programms integriert werden (als JMenuItem's). In der SWT-Version kann ich diese JMenuItem natürlich nicht mit einbinden, da muss ich sie "umbauen" (wobei das nicht das Problem ist bzw. ich an dieser Stelle noch nicht bin).
Das Laden aus einem solchen Modell geschieht in einer spez. dafür geschriebenen Klasse; in dieser gibt es eine Methode, die ganz allgemein Klassen "hineingeworfen" bekommt, und dann überprüft, was diese darstellen sollen (es müssen nicht nur z. B. Menüeinträge sein, es kann auch alles mögliche andere sein). Das ganze sieht dann so aus:
In der mit "//hier tritt der Fehler auf!" gekennzeichneten Zeile tritt dann der Fehler auf, genauer gesagt dieser hier:
"Witzigerweise" tritt dieser Fehler nur in der SWT-Variante auf, nicht in der AWT/Swing-Variante, mit der ich das gegengetestet habe. An der Verwendung von SWT oder SWT kann das aber an sich nicht liegen, die Klasse, in der ich das ganze mache, stellt alles bereit, was ich dafür brauche (und z. B. "erkennt" das Programm ja auch, dass es sich um ein JMenuItem handelt - s. die if-Abfrage mit dem ".isAssignableFrom...").
Google'n hat ergeben, dass sowas "irgendwie" mit dem Verwenden von unterschiedlichen Java-Versionen beim erstellen zu tun haben kann - allerdings hab ich sichergestellt, dass ich sowohl bei dem SWT-Programm, dass den Fehler schmeisst, wie auch beim Erstellen des Jars, dass das Modell bereitstellt, aus dem geladen wird, die gleiche Version benutze.
Ich hab nicht mehr wirklich Ideen, was das sein kann bzw. wodran ich da noch rumschrauben könnte - hat hier evtl. jemand eine Idee? (muss ja nichtmal speziell zu diesem konkreten Problem hier sein, ein paar "allgemeine Ideen" zu diesen java.lang.verifyError würden mir schon helfen - das "Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem.", was die API bereitstellt, ist jetzt ja nicht sooo aussgekräftig... :cry:
Danke schonmal!
Schönen Gruss,
Sierra aka Jan
... ich hoffe, in meinem ersten Posting hier frage ich nicht direkt nach etwas, was eh schon bekannt ist & hier schon wer-weiss-wie-oft behandelt wurde - zumind. über die Board-Suche habe ich nur einen Thread gefunden, der hierzu zu passen schien, in diesem gab es aber leider auch keine Lösung dafür. Also frag ich nochmal selbst... :wink:
Ich habe folgendes Problem: ich bin hier gerade dabei, eine original mit AWT/Swing entwickelte Applikation auf SWT umzustellen (... nicht fragen, warum - Cheffe wollte das so... :wink: ), und dabei stosse ich gerade auf folgendes Problem: die Applikation verarbeitet bestimmte "Modelle", die bisher natürlich nur für die AWT/Swing - Variante entwickelt wurden. Diese "alten" Modelle sollen auch weiterhin in der SWT-Variante zu benutzen sein. Unter anderem sind in diesen Modellen auch Menü-Einträge definiert, die beim Laden eines Modells dynamisch mit in die Menüstruktur des Programms integriert werden (als JMenuItem's). In der SWT-Version kann ich diese JMenuItem natürlich nicht mit einbinden, da muss ich sie "umbauen" (wobei das nicht das Problem ist bzw. ich an dieser Stelle noch nicht bin).
Das Laden aus einem solchen Modell geschieht in einer spez. dafür geschriebenen Klasse; in dieser gibt es eine Methode, die ganz allgemein Klassen "hineingeworfen" bekommt, und dann überprüft, was diese darstellen sollen (es müssen nicht nur z. B. Menüeinträge sein, es kann auch alles mögliche andere sein). Das ganze sieht dann so aus:
Code:
protected void blubb(Class class) {
//blablabla...
if (javax.swing.JMenuItem.class.isAssignableFrom(class)) {
//blablabla
JMenuItem jMenuItem = new JMenuItem();
try {
jMenuItem = (JMenuItem) class.newInstance(); //hier tritt der Fehler auf!
} catch (Exception ex) {
return;
}
//blablabla
}
} // Ende von void blubb
In der mit "//hier tritt der Fehler auf!" gekennzeichneten Zeile tritt dann der Fehler auf, genauer gesagt dieser hier:
Code:
java.lang.VerifyError: (class: /haumichtot/KlasseMitFehler, method: actionPerformed signature: (Ljava/awt/event/ActionEvent;)V) Incompatible argument to function
"Witzigerweise" tritt dieser Fehler nur in der SWT-Variante auf, nicht in der AWT/Swing-Variante, mit der ich das gegengetestet habe. An der Verwendung von SWT oder SWT kann das aber an sich nicht liegen, die Klasse, in der ich das ganze mache, stellt alles bereit, was ich dafür brauche (und z. B. "erkennt" das Programm ja auch, dass es sich um ein JMenuItem handelt - s. die if-Abfrage mit dem ".isAssignableFrom...").
Google'n hat ergeben, dass sowas "irgendwie" mit dem Verwenden von unterschiedlichen Java-Versionen beim erstellen zu tun haben kann - allerdings hab ich sichergestellt, dass ich sowohl bei dem SWT-Programm, dass den Fehler schmeisst, wie auch beim Erstellen des Jars, dass das Modell bereitstellt, aus dem geladen wird, die gleiche Version benutze.
Ich hab nicht mehr wirklich Ideen, was das sein kann bzw. wodran ich da noch rumschrauben könnte - hat hier evtl. jemand eine Idee? (muss ja nichtmal speziell zu diesem konkreten Problem hier sein, ein paar "allgemeine Ideen" zu diesen java.lang.verifyError würden mir schon helfen - das "Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem.", was die API bereitstellt, ist jetzt ja nicht sooo aussgekräftig... :cry:
Danke schonmal!
Schönen Gruss,
Sierra aka Jan