Kommt drauf an was du damit machen willst.
Wenn du z.B. eine Figur in einer Animation (z.B. in einem Spiel) steuern willst, dann wirst du sowieso eine Animationsschleife haben (d.h. ein separater Thread, der in einer Schleife in regelmäßigen Abständen alle Elemente bewegt). Btw.: Falls du so etwas nicht hast, dann kann man so einen Thread auch nur für die Tastatur schreiben, alternativ zur Schleife ist auch ein ein Timer möglich.
Dann braucht man nur mehr eine Variable, in der der letzte Tastendruck gespeichert wird (bei keyPressed), bzw. beim Loslassen (keyReleased) wieder gelöscht wird. Nun kann man in der Animationsschleife diese Variable abprüfen und hat in regelmäßigen Abständen die Möglichkeit das zu tun was immer man mit diesem Tastendruck tun möchte. Will man mehrere Tasten gleichzeitig auswerten (z.B. Pfeiltasten links und oben für eine Bewegung einer Spielfigur nach links oben), so muss man eben mehrere Tasten separat speichern (d.h. mehrere boolsche Variablen für die jeweiligen Tasten).

Nachteil des ganzen: Die Taste wird erst eine Kleinigkeit verzögert ausgewertet (max. einen Schleifendurchlauf zu spät). Macht aber bei z.B. 30 Animationsschritten pro Sekunde in einem Spiel normalerweise nichts. Braucht man eine sofortige Reaktion, so muss man die Schleife (Thread) beim ersten Tastendruck starten und beim Loslassen wieder stoppen.

Hoffe es war verständlich. Ich musste allerdings etwas allgemein bleiben, da ich die näheren Umstände nicht kenne.

Edit: Das Ändern der Verzögerung/Wiederholrate im Betriebssystem bringt nichts, und zwar aus mehreren Gründen:
- Man kriegt diese Verzögerung normalerweise nie ganz weg (zumindest nicht unter Windows, unter Linux habe ich das noch nie ausprobiert)
- Man will wohl kaum jedesmal am Betriebssystem herumpfuschen, wenn man in einem einzelnen Programm keine Tastenverzögerung haben möchte.

Ein paar Bemerkungen:
- Bubble-Sort ist nicht schnell, ja. Allerdings sollte man hier anmerken, dass hier in diesem Fall (sortieren von 5 Elementen) weder Quicksort, noch Radixsort irgendwelche Vorteile bringen. Die bringen erst Laufzeitvorteile bei (sehr) vielen Elementen. Das liegt daran, dass die O-Notation konstante Faktoren bzw. konstante Zeiten vernachlässigt, die bei den schnelleren Sortierverfahren bei großem n nicht mehr ins Gewicht fallen und daher nur dort verwendet werden. Bei etwa 10 Elementen oder weniger sind die Klassiker ähnlich gut oder oft sogar besser.
- Das Einfügen in eine int-Liste alleine ist wahrscheinlich schon langsamer als obiger Bubble-Sort. Vom Sortieren ganz zu schweigen. Sortieren per int-List wird daher wohl eher Laufzeitnachteile bringen.
- Die Idee des Vermeidens eines Arrays ist schon ganz gut (keine Indexberechnungen und keine Range-Checks). Die Anzahl der Vergleiche (10 Stück) ist bei 5 Elementen ja schon nicht sööo schlecht, die im Schnitt 10/2 Vertauschungen (= 15 Zuweisungen) plus 5 Zuweisungen von in nach out sind jedoch vermutlich etwas mehr als notwendig.
- Auch mich täte interessieren wo man 1000 Milliarden mal 5 Zahlen sortieren muss.
- 1000 Milliarden mal sortieren "geht in die Sekunden hinein"? Bei welchem Computer bitte? Bei einer Sortierung pro Nanosekunde (unrealistisch schnell) würde man schon eine Viertelstunde dafür brauchen. Oder reden wir hier von Großrechnern mit zig-tausenden parallel arbeitenden CPUs?

Meine Vorschläge zur Optimierung:
- Wenn sonst keinerlei Informationen über die Zahlen vorliegen: Ein klassisches Sortierverfahren (dann bleibt es einfach).
- Bubblesort ist eigentlich kein Klassiker, sondern lediglich ein intuitives Verfahren für Programmieranfänger. Besser man nimmt z.B. Insertionsort oder Selectionsort, bei ähnlich vielen Vergleichen, einige Zuweisungen weniger.
- Man könnte zusätzlich noch die Zuweisung von in nach out in eine Sortierrunde einweben. z.B. bei Selectionsort. Dann hätte man die 5 Zuweisungen nicht mehr extra.
- Eine Idee noch: Sortieren der ersten beiden Zahlen (1 Vergleich, 0 oder 3 Zuweisungen), sortieren der Zahlen 3 bis 5 (2-3 Vergleiche, 0-4 Zuweisungen) und dann ein Merge auf out (2-4 Vergleiche, 5 Zuweisungen). Ergäbe insgesamt 5-8 Vergleiche und 5-12 Zuweisungen. Allerdings ohne Schleifen/Arrays wären das viele Sonderfälle (also viele ifs) und etwas unübersichtlich.
- Eventuell noch inlining.

Nein, das ist nicht möglich. Entscheidend bei der Fokussierung ist der Abstand zum Monitor. Man kann mit dem Monitor nur Sehschwächen (Unschärfen verschiedenster Art) für Normalsichtige simulieren aber nicht umgekehrt. Entscheidend für die Fokussierung (des Auges) ist der Winkel der Lichtstrahlen, und der kann durch ungerichtet wegstrahlendes Licht vom Monitor nicht simuliert werden.
Momentan werden aber Monitore entwickelt, die 3D-Fernsehen ermöglichen sollen. Ein paar dieser Typen sollen mal ohne 3D-Brille auskommen (d.h. die Bilder werden richtungsabhängig abgestrahlt). Würde man solche Monitore danach nochmals(!) weiterentwicklen, könnte man die Idee allerdings wieder aufgreifen. Aber das ist wohl noch ferne Zukunftsmusik.
Ansonsten hilft nur eine Vergrößerung des Monitorbildes (wie davide schon bemerkte).

Deine Schleife blockiert wohl den Thread, der für das Zeichnen verantwortlich ist (ist derselbe, der Events abarbeitet). repaint stellt nämlich nur einen Auftrag für das Neu-Zeichnen in eine Warteschlange, es ist aber kein Thread da, der diese Warteschlange abarbeitet.
Lösung: Entweder das repaint in den Ball, oder separater Thread für das repaint (inkl. Wartepausen, ansonsten geht die Prozessorlast gegen 100 %).

Java: Integer.parseInt

Ein Array dieser Größe deutet eher darauf hin, dass es ein Problem im Programm(-Design) gibt. Immerhin ist das Array in einer Größe, die in etwa der heute üblichen Hauptspeichergröße entspricht.
1 Mrd. Elemente ist mit int ja noch möglich, wie viele sollen es denn maximal sein?
Bei welchem Element-Datentyp? Ab 3 Mrd. Elementen (byte) oder < 1 Mrd. Elementen (int) wird man wohl ohne 64-Bit Betriebssystem schon mal sowieso nicht mehr auskommen und 4GB Hauptspeicher sind dann wohl auch schon etwas knapp bemessen.
Hinzu kommt, dass man bei der JVM wohl erst mal die max. Heapgröße raufsetzen muss, um überhaupt so viel Speicher zur Verfügung zu haben.

Also ich würde generell mal empfehlen die Daten in eine Datenbank/auf die Festplatte auszulagern oder eine bessere Datenstruktur zu überlegen. Kommt ganz auf die Problemstellung an. Darf man denn da näheres wissen?

Nun ja, wenn value null ist, dann ist das wohl ein Problem im Modell, dass dort Werte nicht gesetzt sind (oder die Zeilen/Spaltenanzahl nicht stimmt).

Im Hauptprogramm:

JTable table = new JTable(new TestTableModel());
table.setDefaultRenderer(String.class, new TestTableCellRenderer());

getColumnClass bringt auch nichts? Ich dachte eher, dass dort das Problem liegt.

Im TableModel die Methode getColumnClass überschreiben und String.class zurückgeben (sofern nur Strings dargestellt werden sollen, was laut setDefaultRenderer wohl der Fall ist).
Ansonsten ist der Teil des Hauptprogramms unvollständig, da könnte auch noch die eine oder andere Kleinigkeit falsch sein.

Meine CellRenderer sehen übrigens meist so aus:

public Component getTableCellRendererComponent(JTable table, Object value,
			boolean isSelected, boolean hasFocus, int row, int column) {
		Component c = super.getTableCellRendererComponent(table, value, isSelected, hasFocus, row, column);
		if (row % 2 == 0) {
			c.setBackground(Color.RED);
		}
		else {
			c.setBackground(Color.GREEN);
		}
		return c;
	}

Zitat

Das nimmt aber das ganze Tetris-feeling, wenn der Sound hinterher hinkt

Es hinkt nicht hinterher, wenn man die Sound-Ausgabe vorher stoppt und dann noch einmal startet. Die überlagern sich dann zwar nicht, aber es hinkt auch nichts hinterher.
Ob mehrere Threads oder nicht ist nicht so wichtig (man kann ja mit Thread.join schön auf das Ende eines anderen Threads warten), aber dem "Audiodaten zwischenspeichern und nicht jedesmal neu laden" schließe ich mich an.

Beim Ansehen fallen mir ein paar Dinge auf (mit dem Hinweis, dass ich mit Jumble noch nichts gemacht habe und ich mich mal auf JUnit beziehe, aber ich denke die Probleme liegen bereits dort):

Gehört vor die Methode nicht ein @test damit die Methode als Testmethode für JUnit erkannt wird?

@Test public void testkillmutant2() { ... }

Sollte es außerdem nicht heissen:

@Test(expected=FullStackException.class) public void ...

Damit sollte das ganze Werfen und Fangen der Exception inkl. Fehlermeldung JUnit übernehmen. Man braucht in der Testmethode dann nur noch den Overflow provozieren (dh. kommt die Exception nicht, ist der Test fehlgeschlagen).

Das failNotEquals hat zudem folgende Schnittstelle:

static void failNotEquals(String message, Object expected, Object actual)

Scheint mir nicht sonderlich stimmig zu sein, wenn da "String is full" mit dem Ergebnis einer "is..."-Methode (boolean?) verglichen wird.

Und evtl. könnte man das one = new Stack(2); noch in eine @Before-Methode stecken, wenn mehrere Testfälle damit abgedeckt werden sollen.

Und noch was:
- Sprechende Variablennamen verwenden (one, two?)
- Wenn new Stack(2) bedeuten soll, dass 2 Elemente reingehen sollen, warum dann schon beim 2. Element eine FullStackException?
- "Messages do not correspond" Scheint mir für diesen Fall keine passende Fehlermeldung zu sein, genauso wenig wie "String is full" zu einem Stack passt.
- Der Name des Tests an sich sagt nicht wirklich viel aus (obwohl ich natürlich den Kontext nicht kenne)

Ich würde es also so probieren:

@Test (expected=FullStackException.class) public void testStackoverflow(){
[INDENT]myStack=new Stack(2);
myStack.push("erstes");
myStack.push("zweites");
myStack.push("das dritte ist eins zu viel");[/INDENT]}