Swing Exception: Comparison method violates its general contract!

[Gelöschtes Mitglied 20545]

Hi!

In dem ActionListener eines Buttons rufe ich auf diesem Button setEnabled(false) auf, das funktioniert oft, ab und an fliegt aber folgende Exception:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: Comparison method violates its general contract!
	at java.util.TimSort.mergeLo(Unknown Source)
	at java.util.TimSort.mergeAt(Unknown Source)
	at java.util.TimSort.mergeCollapse(Unknown Source)
	at java.util.TimSort.sort(Unknown Source)
	at java.util.TimSort.sort(Unknown Source)
	at java.util.Arrays.sort(Unknown Source)
	at java.util.Collections.sort(Unknown Source)
	at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(Unknown Source)
	at javax.swing.SortingFocusTraversalPolicy.getFocusTraversalCycle(Unknown Source)
	at javax.swing.SortingFocusTraversalPolicy.getComponentAfter(Unknown Source)
	at javax.swing.LayoutFocusTraversalPolicy.getComponentAfter(Unknown Source)
	at java.awt.Component.getNextFocusCandidate(Unknown Source)
	at java.awt.Component.transferFocus(Unknown Source)
	at java.awt.Component.disable(Unknown Source)
	at javax.swing.JComponent.disable(Unknown Source)
	at java.awt.Component.enable(Unknown Source)
	at java.awt.Component.setEnabled(Unknown Source)
	at javax.swing.JComponent.setEnabled(Unknown Source)
	at javax.swing.AbstractButton.setEnabled(Unknown Source)
	at CubeEditor.FramePanel$PlayListener$1.run(FramePanel.java:368)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$000(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

Wieso und was kann ich dagegen tun?

 

[bERt0r]

Meine Allwissenheit sagt mir dass in deinem Code ein Fehler ist! Nur wo... hat jemand eine Glaskugel zur Hand?

 

[Gelöschtes Mitglied 20545]

Vielleicht kannst du aus den Eingeweiden einer Stubenfliege was lesen? ^^

Ok, ich erzähle mal mehr:
Der Compiler meckert zumindest nicht und wie gesagt: Die Exception wird nur gelegentlich beim Betätigen des Buttons geworfen, ich habe noch nicht herausgefunden, woran genau es liegt.
Kurz zum Code "drumrum": Das ist ein LED-Cube-Programmierer, in der Klasse DisplayPanel werden die Lämpchen des Würfels als JPanel dargestellt (sind also einige) und diese kann man per Mausklick "ein- und ausschalten".
Solch ein Arrangement kann man dann als "Frame" abspeichern und mehrere "Frames" als Animation abspielen, was mit eben besagtem ActionListener geschehen soll. Hier ist er:

private class PlayListener implements ActionListener{
		public void actionPerformed(ActionEvent e){
			if(!playing){
				playing = true;
				displayPanel.setPlaying(true);
				playTimer = new Timer(100,new PlayTimerListener());
				SwingUtilities.invokeLater(new Runnable(){
					public void run(){
						playBtn.setEnabled(false);
						stopBtn.setEnabled(true);
						playTimer.start();
					}
				});
			}
		}
}

Man kann in dieses DisplayPanel rein- und rauszoomen und wenn ich das vor dem Abspielen tue, kommt die Exception mit größerer Wahrscheinlichkeit, aber auch nicht immer, vermutlich bei größeren Würfeln ab vielleicht 8x8x8. Moniert wird in der Exception die Zeile "playBtn.setEnabled(false)", bei playBtn ist obiger Listener registriert.

Also: Wahrsager, Hellsichtige und Gurus, ich rufe euch! ^^ Fällt da wem was zu ein?

Wer lustig ist, kann sich den Quellcode ansehen, ich weiß eben leider nicht, was hierfür relevant sein könnte. Der playBtn befindet sich in der leider riesigen Klasse FramePanel.java
Wer sich das jar anschaut: Die Listen muss man mit Doppelklick bedienen.

 

[bERt0r]

Edit: Versuch einfach mal die zwei setEnabled umzudrehen.
Edit2: Eventuell hilft das Comparison method violates its general contract! | Java.net

I managed to solve this issue.
I dont exactly know why the error was thrown but know how to avoid this error.
I avoided it by writing a custom FocusTraversalPolicy for each panel of each Tab in my application's JTabbedPane. Once the custom FocusTraversalPolicy was in place and active all errors dissappeared. It is also worth mentioning that with java 1.6 these errros where not appearing. This means that java 1.7 is stricter which I welcome warmly as it helps us building robuster applications!

 

[eskimo328]

Hi, ich habe dieselbe Fehlermeldung. Bei mir tritt der Fehler beim Sortieren einer Tabelle in meinem TableSorter auf, bei der Zeile: Arrays.sort(viewToModel);

private Row[] getViewToModel()
	{
		if (viewToModel == null)
		{
			int tableModelRowCount = tableModel.getRowCount();
			viewToModel = new Row[tableModelRowCount];
			for (int row = 0; row < tableModelRowCount; row++)
			{
				viewToModel[row] = new Row(row);
			}

			if (isSorting())
			{
				Arrays.sort(viewToModel);
			}
		}
		return viewToModel;
	}

Die Fehlermeldung:

 Exception in thread "AWT-EventQueue-0" 
 java.lang.IllegalArgumentException: Comparison method violates its general contract!
 	at java.util.ComparableTimSort.mergeHi(Unknown Source)
 	at java.util.ComparableTimSort.mergeAt(Unknown Source)
 	at java.util.ComparableTimSort.mergeForceCollapse(Unknown Source)
 	at java.util.ComparableTimSort.sort(Unknown Source)
 	at java.util.ComparableTimSort.sort(Unknown Source)
 	at java.util.Arrays.sort(Unknown Source)
 	at de.integratedsystems.logimobile.gui.components.persistenttable.LM_TableSorter.getViewToModel(LM_TableSorter.java:301)
 	at de.integratedsystems.logimobile.gui.components.persistenttable.LM_TableSorter.modelIndex(LM_TableSorter.java:309)
 	at de.integratedsystems.logimobile.gui.components.persistenttable.LM_TableSorter.getValueAt(LM_TableSorter.java:355)
 	at javax.swing.JTable.getValueAt(Unknown Source)
 	at javax.swing.JTable.prepareRenderer(Unknown Source)
 	at javax.swing.plaf.basic.BasicTableUI.paintCell(Unknown Source)
 	at javax.swing.plaf.basic.BasicTableUI.paintCells(Unknown Source)
 	at javax.swing.plaf.basic.BasicTableUI.paint(Unknown Source)
 	at javax.swing.plaf.ComponentUI.update(Unknown Source)
 	at javax.swing.JComponent.paintComponent(Unknown Source)
 	at javax.swing.JComponent.paint(Unknown Source)
 	at javax.swing.JComponent.paintToOffscreen(Unknown Source)
 	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
 	at javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
 	at javax.swing.RepaintManager.paint(Unknown Source)
 	at javax.swing.JComponent._paintImmediately(Unknown Source)
 	at javax.swing.JComponent.paintImmediately(Unknown Source)
 	at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
 	at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
 	at javax.swing.RepaintManager.prePaintDirtyRegions(Unknown Source)
 	at javax.swing.RepaintManager.access$700(Unknown Source)
 	at javax.swing.RepaintManager$ProcessingRunnable.run(Unknown Source)
 	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
 	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
 	at java.awt.EventQueue.access$000(Unknown Source)
 	at java.awt.EventQueue$3.run(Unknown Source)
 	at java.awt.EventQueue$3.run(Unknown Source)
 	at java.security.AccessController.doPrivileged(Native Method)
 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
 	at java.awt.EventQueue.dispatchEvent(Unknown Source)
 	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
 	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
 	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
 	at java.awt.WaitDispatchSupport$2.run(Unknown Source)
 	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
 	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
 	at java.awt.EventQueue.access$000(Unknown Source)
 	at java.awt.EventQueue$3.run(Unknown Source)
 	at java.awt.EventQueue$3.run(Unknown Source)
 	at java.security.AccessController.doPrivileged(Native Method)
 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
 	at java.awt.EventQueue.dispatchEvent(Unknown Source)
 	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
 	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
 	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
 	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
 	at java.awt.EventDispatchThread.run(Unknown Source)

Liegt hier das Problem in der compareTo MEthode?

private class Row implements Comparable<Object>
	{
		private int modelIndex;

		public Row(int index)
		{
			this.modelIndex = index;
		}

		public int compareTo(Object o)
		{
			int row1 = modelIndex;
			int row2 = ((Row) o).modelIndex;

			if (firstUnsortableRow > -1 && row2 >= firstUnsortableRow)
				return 0;

			for (Iterator<Directive> it = sortingColumns.iterator(); it.hasNext();)
			{
				Directive directive = (Directive) it.next();
				int column = directive.column;
				Object o1 = tableModel.getValueAt(row1, column);
				Object o2 = tableModel.getValueAt(row2, column);

				int comparison = 0;
				// Define null less than everything, except null.
				if (o1 == null && o2 == null)
				{
					comparison = 0;
				}
				else if (o1 == null)
				{
					comparison = -1;
				}
				else if (o2 == null)
				{
					comparison = 1;
				}
				else
				{
					comparison = getComparator(column).compare(o1, o2);
				}
				if (comparison != 0)
				{
					return directive.direction == DESCENDING ? -comparison : comparison;
				}
			}
			return 0;
		}
	}

Irgendwelche Lösungsvorschläge?

 

[eskimo328]

Das Problem liegt in den Zeilen:

if (firstUnsortableRow > -1 && row2 >= firstUnsortableRow)
                return 0;

Damit bezwecke ich, dass die letzte Zeile oder die letzten paar Zeilen nicht mit sortiert werden, sondern immer unten stehen bleiben.
Nur wie kann man das nun besser lösen?

 

[bERt0r]

Du meine Güte, ist firstUnsortableRow eine globale Variable?? Ganz, ganz, ganz, ganz schlechter Stil.
Ausserdem kannst du in einer compare Methode keine getAufrufe auf dein Model machen. Compare wird so oft aufgerufen, das killt die Performance. Nebenbei ist es meist nicht so klug, während eines Sortiervorgangs wahllos auf das zu sortierende Feld zuzugreifen.

 

[SlaterB]

            if (firstUnsortableRow > -1 && row2 >= firstUnsortableRow)
                return 0;

firstUnsortableRow ist unbekannt

bei solchem Code ist jedenfalls vorstellbar, dass Objekt a mit row1 vergleicht mit Object b mit row 2 als Vergleich 0 zurückgibt, da row2 hoch ist,
aber row1 ist niedrig, deswegen würde b vergleicht mit a nicht hier schon 0 zurückgeben, sondern vielleicht im weiteren Verlauf was anderes

-> damit hätte man einen Bruch wie die Exception ihn anspricht,
zwei Objekte a und b würden je nach beliebig gewählten Vergleichsaufruf unterschiedliches Vergleichsergebnis geben,
so kann man nicht arbeiten..


oder ist dieser Fall sicher ausgeschlossen?

----

bei

                if (o1 == null && o2 == null)
                {
                    comparison = 0;
                }
                else if (o1 == null)
                {
                    comparison = -1;
                }
                else if (o2 == null)
                {
                    comparison = 1;

ist dagegen sicher gebaut worden, nur die beiden else-Fälle würden je nach Reihenfolge wieder unterschiedliches liefern,
Blick auf beide gleichzeitig repariert das


edit:
> Nur wie kann man das nun besser lösen?
wie gesagt auch row1 prüfen, wenn auf beide gleich reagiert wird, ist das eher ungefährlich



-----


wenn du im Code/ Programm an sich selber nicht genug erkennst und auch begrenzte Tests nichts aufdecken,
kannst du noch versuchen, in der compare-Methode zu loggen, was wird verglichen mit welchem Ergebnis?
bei vielen Ausgaben kann man da Probleme haben,
evtl. ist es machbar, die Ergebnisse in einer Map zu speichern "compare "..+.. -> 1, 0, oder -1,
vor den Abspeichern nachschauen ob schon vorhanden, wenn ja und anderes Ergebnis gespeichert,
dann hast du direkt ein Fehler-Beispiel gefunden,
welches aber nicht notwendigerweise die Ursache für den Fehler sein muss, das kann im Sortieralgorithmus auch untergehen,

andersrum kann es aber auch die Exception geben, ohne einen direkten Widerspruch,
z.B. wenn der Kreis über mehrere Elemente geht: a gilt als kleiner als b, b < c, aber auch c < a, das kann nicht sein,
und führt zu Problemen, je nachdem wie sich die Vergleiche intern auswirken,

ebenso muss nicht der letzte Vergleich vor dem Fehler die Problemstelle sein, das kann erst nach einiger Zeit durchwirken,
wenn Listen aufgefüllt werden,

die letzten Sätze sind gerade ziemliche Details,
ich habe nämlich das ComparableTimSort kopiert und mir selber ein Beispiel zusammengeschrieben, welches nicht ganz so leicht aufgeht

public class Test
{
    public static void main(String[] args)
    {
        int k = 32; // unter 32 kommt anscheinend nicht der Code mit der Exception dran
        Entry[] e = new Entry[k];
        for (int i = 0; i < k; i++)
        {
            e[i] = new Entry();
        }
        ComparableTimSort.sort(e);
    }

    static Map<String, Integer> map = new HashMap<String, Integer>();

    static class Entry
        implements Comparable<Entry>
    {
        static int count;
        int number = count++; // jeder Entry eine number

        public int compareTo(Entry other)
        {
            int c = number % 2 == 0 ? -1 : 1; // mieser Vergleich
            int[] keys =   {number, other.number};
            Arrays.sort(keys); // unabhängig von der Reihenfolge, sonst schlecht zu vergleichen
            String key = Arrays.toString(keys); 
            Integer oldC = map.get(key);
            System.out.println("Keys " + key + " -> " + c);
            if (oldC != null && oldC.intValue() != c)
            {
                System.out.println("Keys " + key + " formerly compared to " + oldC + "! expect Boom soon");
            }
            return c;
        }
    }
}

führt bei mir zu der Exception, aber nicht so leicht analysierbar wie ich es vorhin gerne hätte

na vielleicht kannst du schon ganz schnell beim deinem comparable etwas verbessern, bevor ich noch mehr Blahblah erzähle?

 

[SlaterB]

Ausserdem kannst du in einer compare Methode keine getAufrufe auf dein Model machen. Compare wird so oft aufgerufen, das killt die Performance. Nebenbei ist es meist nicht so klug, während eines Sortiervorgangs wahllos auf das zu sortierende Feld zuzugreifen.

es gibt schnelle Aufrufe genauso wie es lahmen Code innerhalb der eigenen Methode gibt,
hinweisen darauf ja, generelle Verbote, nein,

ein Comparator für die Klasse Auto, der in der compareTo-Methode bei beiden Objekten den Namen abfragt
ist nicht viel anders als hier je Objekt die Werte aus einem Model zu holen,

Cache ist etwas besser, aber nicht entscheidend,
der Aufwand steigt nur um einen konstanten Faktor, die Komplexität bleibt beim gleichen O wie zuvor
je nach Sortieralgorithmus n^2 oder n log n

 

[eskimo328]

So ganz hab ich das mit dem Problem noch nicht verstanden, meine Lösung sieht aber nun wie folgt aus: In dem Array, das zum Sortieren dem Sortieralgorithmus übergeben wird, lasse ich einfach die letzten, nicht zu sortierenden Zeilen weg. Und füge Sie im Anschluss wieder ein.

private Row[] getViewToModel()
	{
		if (viewToModel == null)
		{
			int tableModelRowCount = tableModel.getRowCount();
			
			/* Nur die Zeilen bis zur Zeile mit dem Index firstUnsortableRow sortieren */
			if(firstUnsortableRow > -1) {
				tableModelRowCount = tableModelRowCount - (tableModelRowCount-firstUnsortableRow);
			}
			viewToModel = new Row[tableModelRowCount];
			for (int row = 0; row < tableModelRowCount; row++)
			{
				viewToModel[row] = new Row(row);
			}

			if (isSorting())
			{
				Arrays.sort(viewToModel);
			}
		}
		
		/* Nicht sortierte Zeilen wieder anhängen */
		if(firstUnsortableRow > -1) {
			Row[] viewToModel2 = new Row[tableModel.getRowCount()];
			for (int i = 0; i < viewToModel.length; i++) {
				viewToModel2[i] = viewToModel[i];
			}
			for (int i = firstUnsortableRow; i < viewToModel.length; i++) {
				viewToModel2[i] = new Row(i);
			}
			viewToModel = viewToModel2;
		}
		
		return viewToModel;
	}

 

[bERt0r]

@SlaterB hast du dir den Code beim getAufruf genau angeschaut?
Er speichert in seinem Row Objekt den index, den diese Row im Model hat ab. Wenn jetzt aber sortiert wird, kann dieser Index nicht immer gleich der tatsächlichen Position sein. Dadurch ist nichtmal sichergestellt, dass wenn er auf RowObjekt #1 compareTo(RowObject#2) aufruft, er auch wirklich die zwei vergleicht. Schließlich wird beim herumschieben/sortieren der Rows deren lokal gespeicherter RowIndex nicht aktualisiert.

 

[SlaterB]

gerade dadurch, dass hoffentlich das interne Attribut modelIndex gleichbleibt, gehört jedes Row-Objekt fest zu genau einem Eintrag im Model,
das Model bleibt gleich, die Rows werden durcheinandergewirbelt, der Inhalt der Rows bleibt gleich
(ich gebe aber zu dass ich da vorher nicht allzu sehr drauf geachtet habe )

 

[bERt0r]

Bist du dir sicher? Die rows liegen im Model, die rows haben ein index attribut, die rows werden sortiert, das row Attribut aber wird nicht aktualisiert.
Das heist: Sortieralgorithmus vergleicht Row 1 und 2; Row 2 < Row 1 -> vertauschen
Jetzt liegt Row 2 über Row 1, der Index von Row 1 zeigt aber immer noch auf Platz 1 des Models, also jetzt auf Row 2. Beim nächsten Vergleich von Row 2 und Row 3 wird nicht Row 2 sonder Row 1 mit Row 3 verglichen.

 

[SlaterB]

das Model bleibt die ganze Zeit unverändert, sonst wäre es sinnlos überhaupt Row-Objekte zu haben,
nicht dass man nicht sinnloses auch wirklich einbauen könnte, aber das beschreibt ein an sich bekanntes sinnvolles Konzept,
die JTable hat das selber auch mit

public int convertRowIndexToModel(int viewRowIndex)

Maps the index of the row in terms of the view to the underlying TableModel. If the contents of the model are not sorted the model and view indices are the same.

Parameters:
viewRowIndex - the index of the row in the view
Returns:
the index of the corresponding row in the model

insofern ist fraglich was und warum hier überhaupt nachgebaut wird, funktionieren kann es aber absolut

auch technisch wäre es fraglich wo es da Probleme geben soll,
tableModel.getValueAt() kann nicht wieder auf die Row-Objekte gehen, die haben gar keine Daten,

sortiert wird der View, das Model bleibt gleich