java.lang.verifyError beim Casten nach JMenuItem

[Sierra]

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:

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:

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

 

[Wildcard]

Zeig mal die Klasse du die hier instanzieren willst.

 

[Sierra]

Hallo,

Zeig mal die Klasse du die hier instanzieren willst.

... ich konnte das Problem inzw. eingrenzen; es scheint doch "irgendwie" damit zu tun zu haben, dass sich wiedermal AWT- und SWT-Komponenten nicht mögen... :?

Ich paste hier einfach mal den Code rein, der letzten Endes das Problem verursacht:

public class Klasse extends JMenuItem implements ActionListener {
    
    public Klasse() {
        setText("Check for multiple credentials");
        setToolTipText("This will check the model for users which have multiple credentials for one" +
                "subject role. This can be a hint to unwanted ambiguities in the model.");
        addActionListener(this);
    }

    public void actionPerformed(ActionEvent e) {
                // alles mögliche, was hier sonst noch vorher drinsteht rausgelöscht, das verursacht alles keine Probleme
                // credentialCount ist jetzt vorher gemäss diverser Abfragen gesetzt; das Problem verursacht bei dieser Klasse jetzt rein die eine Zeile mit dem JOptionPane
                if (credentialCount > 1) {
                    JOptionPane.showMessageDialog(MoBaSec.getInstance(), "User " + user.getObjectName() +
                            " has multiple credentials for subject role " + sr.getObjectName(),
                            "Multiple credential warning", JOptionPane.WARNING_MESSAGE);
                }
            }
        }
            
        
        
    }

}

Das zuvor beschriebene Problem tritt - wie ich inzw. gemerkt habe - nicht nur beim Instanziieren auf, sondern auch bei allen anderen Gelegenheiten, z. B. auch, wenn ich ganz stupide über system.out.println(klasse.getDeclaredMethods().length); einfach nur die Anzahl der Methoden in der Klasse klasse ausgeben will.
Würde sowas auftreten, wenn ich konkret versuchen würde, auf irgendeine Methode der (AWT-) Klasse klasse zuzugreifen bzw. diese auszuführen könnte ich mir ja noch ansatzweise vorstellen, woher das kommt, aber soweit komme ich gar nicht erst (ich habe das ganze inzw. auch schon komplett in eine Runnable gepackt, so dass das alles im parallel laufenden AWT-Thread ausgeführt wird, aber das brachte auch nichts...)

Ich hoff mal, mit meinen inzw. bestimmt recht konfusen Beschreibungen kann überhaupt noch jemand was anfangen... :wink:


Gruss, Jan

 

[Wildcard]

Irgendetwas in deinen class Files scheint inkonsistent zu sein. Kannst du den Fehler so weit extrahieren, das du ein kompilierfähiges Beispiel erstellen kannst?

 

[Wildcard]

Hast du mal einen vollen build versucht?
Benutzt du irgendwelche Klassen aus einem sun package?

 

[Sierra]

Hallo,

Irgendetwas in deinen class Files scheint inkonsistent zu sein.

... das ist das, was Google auch immer wieder bei dieser Fehlermeldung als mäglichen Grund ausgespuckt hat (z. B., wenn ich für das im Ausgangsposting angesprochene Modell eine andere Java-Version zum Erstellen benutzt hätte als jetzt für das Programm, in dem ich das aus dem Modell erstellte Jar benutze). Deswegen hab ich (bereits mehrmals...) explizit alle Class-Dateien gelöscht (sowohl über Clean Project bei Ecplise, was ich benutze, als auch "manuell" über das Dateisystem), und sowohl das Modell wie auch alle dazu in Relation stehenden Projekte (auch inzw. mehrfach...) komplett neu erstellt - mit definitiv der gleichen Java-Version (einmal auf der einen Kiste die 1.5.0._05, und auf der anderen glaube ich die 1.5.0._09). Resultat gleich null... :bahnhof:

Gruss, Jan

 

[Sierra]

Hast du mal einen vollen build versucht?

... s. meine andere Antwort auf Deine andere Antwort... :wink:

Benutzt du irgendwelche Klassen aus einem sun package?

Nein.



Gruss, Jan

 

[Wildcard]

Wenn es vor der SWT Umstellung funktioniert hat wäre es doch anzunehmen das der Hund auch dort begraben liegt.
Was hat sich an der betreffenden Klasse geändert?
Wird dort irgendetwas von SWT verwendet?
Und wie oben schon gefragt, benutzt du Klassen aus einem sun package? EDIT: ok, schon beantwortet

 

[Sierra]

Hallo,

Was hat sich an der betreffenden Klasse geändert?

... hierbei muss man jetzt unterscheiden zwischen zwei Klassen bzw. zwei "Arten" von Klassen: zum einen die Klassen aus angesprochenem Modell, die geladen werden. In diesen hat sich *nichts* geändert und in diesen darf sich auch nichts ändern - es geht mir halt eben darum, diese alten Modelle, die für die AWT/Swing - Version des Programmes entwickelt wurden, weiter zu benutzen. Die andere Klasse ist die Klasse, in der die in den Modellen definierten Klassen geladen werden (ist bei mir der sog. "ClassManager", ich benutze diese Bez. jetzt einfach mal weiter). Die grobe Struktur dieses Classmanagers ist ebenfalls gleich geblieben, mein erster Ansatz ging schlicht nur in die Richtung, weiterhin ganz normal die Klassen zu laden, weiterhin die Klassen z. B. über "javax.swing.JMenuItem.class.isAssignableFrom(geladeneKlasse)" daraufhin abzufragen, was sie darstellen sollen (neben JMenuItem gibts noch einige andere Klassen, die dargestellt werden können), somit zu unterscheiden / zu erkennen, was ich da gerade lade, und dann z. B. im Falle des JMenuItems mir zunächst wieder dieses zu erzeugen (eben über "jMenuItem = (javax.swing.JMenuItem) geladeneKlasse.newInstance();"), und dann (hier beginnen die Änderungen bzw. Ergänzungen für den SWT-Kram) aus diesem erzeugten JMenuItem die Sachen herauszuziehen, die ich für die org.eclipse.jface.action.Action, die in das Menü des SWT-Fensters eingefügt wird, brauche. Das sind dann z. B. die Bezeichnung für die org.eclipse.jface.action.Action, die ich über jMenuItem.getText() bekomme, usw. Hier hätte ich dann im ersten Schritt der run()-Methode der org.eclipse.jface.action.Action schlicht und ergreifend auch das actionPerformed() des JMenuItems zugewiesen (in der entsprechenden AWT-Runnable = im AWT-Thread).

Aber soweit komme ich ja nicht einmal - sobald ich *irgendwie* versuche, auf die Methoden zuzugreifen, die in den Modell-Klassen angelegt sind (und sei es über geladeneKlasse.getMethods().length), kommt dann angesprochener Fehler...

Wird dort irgendetwas von SWT verwendet?

Wie gesagt: in den zu ladenden Klassen nicht; der ClassManager läuft natürlich im SWT-Thread. Am falschen Thread liegts aber m. M. nach nicht - da käme dann ein "Illegal Thread Access" (das kenn ich auch schon zur Genüge - so, wie ich deswegen mit den beiden Threads hin- und herjonglieren muss kann es gut sein, dass die Performance-Vorteile, die wir uns von der SWT-Umstellung versprochen haben, eh schon wieder obsolet sind...



Gruss, Jan

 

[Wildcard]

Tut mir Lied, andere Ideen habe ich derzeit nicht. Vielleicht hat noch jemand die zündende Idee und wenn nicht kannst du ja nochmal posten wenn sich eine Lösung gefunden hat.

so, wie ich deswegen mit den beiden Threads hin- und herjonglieren muss kann es gut sein, dass die Performance-Vorteile, die wir uns von der SWT-Umstellung versprochen haben, eh schon wieder obsolet sind...

Ich bin nicht der Meinung das diese Performance-Vorteile überhaupt exisitieren.
Ist Netbeans wesentlich langsamer als Eclipse? Ist Eclipse wesentlich langsamer als native Anwendungen mit ähnlichem Funktionsumfang?
Meiner Ansicht nach kann man beide Fragen mit 'nein' beantworten.

 

[Sierra]

Tut mir Lied, andere Ideen habe ich derzeit nicht. Vielleicht hat noch jemand die zündende Idee und wenn nicht kannst du ja nochmal posten wenn sich eine Lösung gefunden hat.

... werd ich - aber eher nicht mehr heute, nach knapp 10 Stunden solcher "lustiger" Sachen werd ich glaub ich jetzt erstmal Feierabend mache... :wink:
Aber trotzdem danke!

Ich bin nicht der Meinung das diese Performance-Vorteile überhaupt exisitieren.
Ist Netbeans wesentlich langsamer als Eclipse? Ist Eclipse wesentlich langsamer als native Anwendungen mit ähnlichem Funktionsumfang?
Meiner Ansicht nach kann man beide Fragen mit 'nein' beantworten.

Ich formuliers einfach mal so: Cheffe hat gemeint, das würde was bringen - Cheffe zahlt dafür, also friemel ich fröhlich vor mich hin... :roll: Abgesehen davon muss ich schon ganz ehrlich sagen, dass es mir teilweise doch durchaus schneller vorkommt - und "schöner" (und auch "ergonomischer") aussehen tut es mit den SWT-Komponenten m. M. nach auf jeden Fall...



Gruss & schönen Abend,
Jan

 

[Wildcard]

Ich formuliers einfach mal so: Cheffe hat gemeint, das würde was bringen - Cheffe zahlt dafür, also friemel ich fröhlich vor mich hin... :roll: Abgesehen davon muss ich schon ganz ehrlich sagen, dass es mir teilweise doch durchaus schneller vorkommt - und "schöner" (und auch "ergonomischer") aussehen tut es mit den SWT-Komponenten m. M. nach auf jeden Fall...

Jaja, das kennt man :wink:
OT:
Wirkich schneller finde ich's nicht, ich fand Swing auch noch nie langsam wenn es richtig programmiert ist.
Das SWT nativer aussieht ist klar, darum ging's ja auch.
Im Vergleich finde ich Swing allerdings deutlich komfortabler und das Ergebnis völlig zufriedenstellend, persönlich nehme ich also (wenn ich die Wahl habe) weiterhin Swing.

 

[Ariol]

Nur mal so ein Gedanke, aber könnts vielleicht am Actionlistener liegen?
was passiert denn, wenn du den als "private class" innerhalb deiner Klasse einbindest?

public class Klasse extends JMenuItem
{
   
    public Klasse() 
   {
        setText("Check for multiple credentials");
        setToolTipText("This will check the model for users which have multiple credentials for one" +
                "subject role. This can be a hint to unwanted ambiguities in the model.");
        addActionListener(new Action());
    }

   
    private class Action implements ActionListener
    {
         public void actionPerformed(ActionEvent e) 
        {
                if (credentialCount > 1) 
                {
                    JOptionPane.showMessageDialog(MoBaSec.getInstance(), "User " + user.getObjectName() +
                            " has multiple credentials for subject role " + sr.getObjectName(),
                            "Multiple credential warning", JOptionPane.WARNING_MESSAGE);
                }
          }
     }
}

Kenn mich leider fast garnicht mit swt aus, also bitte nicht hauen...

Viel Glück

 

[Sierra]

Hallo,

Nur mal so ein Gedanke, aber könnts vielleicht am Actionlistener liegen?
was passiert denn, wenn du den als "private class" innerhalb deiner Klasse einbindest?

... liegts nicht - es liegt in diesem Codebeispiel z. B. wirklich explitzit an der einen Zeile mit dem JOptionPane (bzw. im Beispiel wirkt das wie 3 Zeilen). Wenn ich diese Zeile auskommentiere läuft das ganze absolut problemlos - dummerweise (um auf Deinen Vorschlag mit der Private Class zurück zu kommen) kann ich an sich in dieser Klasse (bzw. in diesen Klassen da) nichts verändern, das sind halt die Klassen des angesprochenen Modells, die weiterhin genauso verwendet werden sollen, wie sie bisher auch waren... :cry:

Trotzdem danke!

Gruss, Jan