Thread Exchanger

Adriano10

Bekanntes Mitglied
Ruft z.B ein Thread A für ein Exchanger-Objekt obj die Methode tauschen auf, wird er blockiert bis ein anderer Thread B ebenfalls für obj die Methode aufruft. In diesem Moment tauschen die beiden Threads ihre jeweils der Methode tauschen als Parameter übergebenen Daten aus.

das Object wird eigentlich getauscht, aber habe ich immer Verklemmung. Kann jemand mir bitte helfen?

Vielen Dank im Voraus

Java:
package vermittler;


public class Exchanger<T> {
    private boolean flag = false;

    public synchronized T tauschen(T daten) {
        return daten;
    }

    public boolean isFlag() {
        return flag;
    }

    public void setFlag(boolean flag) {
        this.flag = flag;
    }
}

class Worker implements Runnable {
    private String msg;
    Exchanger<String> exchanger;
    Object object;

    public Worker(String msg, Exchanger<String> exchanger, Object o) {
        this.msg = msg;
        this.exchanger = exchanger;
        this.object = o;
    }

    @Override
    public void run() {
        synchronized (object) {
            if (!Thread.currentThread().isInterrupted()) {
                System.out.println("Producer: " + exchanger.tauschen(msg));
                try {
                    Thread.sleep(1000);
                    object.wait();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            } else {
                System.out.println("Consumer: " + exchanger.tauschen(msg));
                object.notify();

            }
        }
    }
}

class Main {
    public static void main(String[] args) throws InterruptedException {
        Exchanger<String> exchanger = new Exchanger<>();
        Worker worker = new Worker("I am Producer", exchanger, Lock.lock1);
        Worker worker1 = new Worker("I am Consumer", exchanger, Lock.lock1);

        Thread thread = new Thread(worker);
        Thread thread1 = new Thread(worker1);

        thread.start();
        thread.interrupt();
        //Thread.sleep(500);
        thread1.start();
    }
}

class Lock {
    final static Object lock1 = new Object();
    final static Object lock2 = new Object();
}
 

mihe7

Top Contributor
das Object wird eigentlich getauscht, aber habe ich immer Verklemmung. Kann jemand mir bitte helfen?
Nein, Dein Exchanger hat praktisch nichts mit der Aufgabenstellung zu tun:
Ruft z.B ein Thread A für ein Exchanger-Objekt obj die Methode tauschen auf, wird er blockiert bis ein anderer Thread B ebenfalls für obj die Methode aufruft.
Die Methode tauschen blockiert nichts (ok, zwei Threads können sie nicht gleichzeitig aufrufen), sie gibt lediglich das zurück, was an sie übergeben wurde.
 

Adriano10

Bekanntes Mitglied
Nein, Dein Exchanger hat praktisch nichts mit der Aufgabenstellung zu tun:

Die Methode tauschen blockiert nichts (ok, zwei Threads können sie nicht gleichzeitig aufrufen), sie gibt lediglich das zurück, was an sie übergeben wurde.
könntest Du mir bitte paar Tips geben, wie die Methode tauschen verbessern kann, so dass sie blockiert.

Vielen Dank im Voraus
 

KonradN

Super-Moderator
Mitarbeiter
Hast Du Dir denn die Abläufe mal genau überlegt? Bei dem Code bezweifle ich das extrem!

Bitte setz Dich doch erst einmal hin und überlege Dir den Ablauf! Papier und Stift, eine Sprache, die Du beherrscht (also vermutlich Deutsch) und sonst nichts!

Was soll denn da passieren? Da kommt der erste Thread mit Daten? Was soll der machen? Der hinterlegt die Daten für den anderen Thread und legt sich schlafen.
Dann kommt der zweite Thread: Woran kann er sehen, dass er nicht der erste ist? Er weiss, dass er der zweite ist, also hinterlegt der das Paket für den ersten Thread und nimmt sich das Paket vom ersten Thread. Danach weckt er den ersten Thread auf und geht.
Der erste Thread wurde aufgeweckt - also was macht er? Er nimmt sich das Paket, das für ihn hinterlegt wurde und geht auch.

Das wäre ein erster, grober Ansatz. Da muss man dann noch paar Dinge überlegen, z.B. was heisst das "Paket nehmen" - da ist halt doch noch etwas zu beachten.

Aber mit so einer einfachen Beschreibung bekommt man wenigstens etwas Funktionalität hin, die man dann testen könnte. Bei der man auch überlegen kann: Dürfen andere Threads jederzeit dazu kommen? Oder was muss man wie synchronisieren.

Aus meiner Sicht ist das ein Vorgehen, das immer existenziell ist! Immer, wenn eine Aufgabe für einen nicht trivial ist wird so in der Art ein Verständnis aufgebaut. Das läuft auch bei den "Profis" nicht anders.
 

Arrive5784

Aktives Mitglied
Ich hätte das "Beispiel" so geschrieben:

Java:
package threads;

import java.util.concurrent.ThreadLocalRandom;

public class Producer implements Runnable {
    public final Consumer consumer;

    public Producer(Consumer c) {
        consumer = c;
    }

    @Override
    public void run() {
        try {
            for (int i = 0; i < 10; i++) {
                produce(ThreadLocalRandom.current().nextInt(1, 15 + 1));
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    private void produce(int menge) throws InterruptedException {
        while (menge > 0) {
            int j = ThreadLocalRandom.current().nextInt(1, menge + 1);
            Thread.sleep(500);
            consumer.add(j);
            menge -= j;
        }
    }
}

class Consumer implements Runnable {
    private int menge = 0;

    public synchronized void add(int menge) {
        this.menge += menge;
        System.out.println("+++");
        System.out.println(this + " add menge: " + menge);
        System.out.println(this + " new menge: " + this.menge);
        System.out.println("+++");
        notifyAll();
    }

    @Override
    public void run() {
        try {
            for (int i = 0; i < 10; i++) {
                consume(ThreadLocalRandom.current().nextInt(1, 10 + 1));
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    private synchronized void consume(int menge) throws InterruptedException {
        while (this.menge < menge) {
            wait();
        }
        this.menge -= menge;
        System.out.println("---");
        System.out.println(this + " del menge: " + menge);
        System.out.println(this + " new menge: " + this.menge);
        System.out.println("---");
    }
}

class Mng {
    public static void main(String[] args) {
        Consumer c = new Consumer();
        Thread consumer = new Thread(c);
        Thread producer = new Thread(new Producer(c));
        consumer.start();
        producer.start();
    }
}

Scheint zu funktionieren, oder übersehe ich was?

@Adriano10 Wenn das Ding Producer und Consumer heißt, dann nenn es auch so...
 

KonradN

Super-Moderator
Mitarbeiter
Die Frage ist, was die Anforderungen genau sind. Von der Beschreibung her sollen die Werte zwischen den zwei Threads ausgetauscht werden - also kein typisches Producer -> Consumer Verhalten.

Und das ist relativ einfach aufzubauen. Die Beschreibung habe ich ja ansonsten auch schon geliefert. Und wenn wir jetzt schon dabei sind, dem TE Code zu liefern (Was ich extrem kontraproduktiv finde. So bringt er eine weitere Aufgabe hinter sich ohne die Aufgabe / den Lösungsweg verstanden zu haben. Das wird ihm ggf. später auf die Füße fallen.)

Der Code eines solchen "Exchangers" könnte also sowas sein:
Java:
package forum;

public class Exchanger<T> {
    private volatile T fromFirstThread;
    private volatile T fromSecondThread;

    public synchronized T exchange(T data) {
        if (fromFirstThread == null) {
            fromFirstThread = data;
            try {
                this.wait();
            } catch (InterruptedException ex) {}
            return fromSecondThread;
        } else {
            fromSecondThread = data;
            this.notify();
            T result = fromFirstThread;
            fromFirstThread = null;
            return result;
        }
    }
}

Code:
package forum;

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class ExchangerTest {
    @Test
    public void testExchanger() throws InterruptedException {
        final Exchanger<String> exchanger = new Exchanger<>();

        Runnable r1 = () -> {
            String result1 = exchanger.exchange("Hallo");
            assertEquals("Du!", result1);
        };
        Runnable r2 = () -> {
            try {
                Thread.sleep(500);
            } catch (Exception e) {}
            String result2 = exchanger.exchange("Du!");
            assertEquals("Hallo", result2);
        };

        Thread t1 = new Thread(r1);
        Thread t2 = new Thread(r2);
        t1.start();
        t2.start();
        t1.join();
        t2.join();

        t1 = new Thread(r1);
        t2 = new Thread(r2);
        t1.start();
        t2.start();
        t1.join();
        t2.join();
    }

}

Der Test wäre noch besser auszuarbeiten. Zwei Threads, die sich regelmäßig austauschen und die Reihenfolge regelmäßig wechselt wäre eine Idee. Aber das soll jetzt mal nicht das große Thema sein.
 

Robert Zenz

Top Contributor
Kurze Zwischenfrage von mir weil ich es gerade nicht weisz. Das volatilemuesste doch eigentlich unnoetig sein, oder? Der Zugriff auf die Variablen fromFirstThread/fromSecondThread befindet sich ja in einer synchronized Methode, und wenn ich mich richtig erinnere ist dann garantiert dass man immer die "richtigen" Werte sieht. Ich meine, es ist definitiv klarer wenn man volatile dabei stehen hat, aber notwendig muesste es nicht sein, oder?
 

Arrive5784

Aktives Mitglied
Ne, es kann der seltene Fall auftreten, dass ohne volatile ein Thread auf einer veralteten Kopie seiner Variablen arbeitet. Dann treten unerwünschte Effekte auf.

Btw, Halbwissen ist immer suboptimal, wenn man SW Entwickler sein möchte...
 

Adriano10

Bekanntes Mitglied
Hast Du Dir denn die Abläufe mal genau überlegt? Bei dem Code bezweifle ich das extrem!

Bitte setz Dich doch erst einmal hin und überlege Dir den Ablauf! Papier und Stift, eine Sprache, die Du beherrscht (also vermutlich Deutsch) und sonst nichts!

Was soll denn da passieren? Da kommt der erste Thread mit Daten? Was soll der machen? Der hinterlegt die Daten für den anderen Thread und legt sich schlafen.
Dann kommt der zweite Thread: Woran kann er sehen, dass er nicht der erste ist? Er weiss, dass er der zweite ist, also hinterlegt der das Paket für den ersten Thread und nimmt sich das Paket vom ersten Thread. Danach weckt er den ersten Thread auf und geht.
Der erste Thread wurde aufgeweckt - also was macht er? Er nimmt sich das Paket, das für ihn hinterlegt wurde und geht auch.

Das wäre ein erster, grober Ansatz. Da muss man dann noch paar Dinge überlegen, z.B. was heisst das "Paket nehmen" - da ist halt doch noch etwas zu beachten.

Aber mit so einer einfachen Beschreibung bekommt man wenigstens etwas Funktionalität hin, die man dann testen könnte. Bei der man auch überlegen kann: Dürfen andere Threads jederzeit dazu kommen? Oder was muss man wie synchronisieren.

Aus meiner Sicht ist das ein Vorgehen, das immer existenziell ist! Immer, wenn eine Aufgabe für einen nicht trivial ist wird so in der Art ein Verständnis aufgebaut. Das läuft auch bei den "Profis" nicht anders.
Ich danke Dir, das hast du mich super aufgeklärt.
 

KonradN

Super-Moderator
Mitarbeiter
Kurze Zwischenfrage von mir weil ich es gerade nicht weisz. Das volatilemuesste doch eigentlich unnoetig sein, oder? Der Zugriff auf die Variablen fromFirstThread/fromSecondThread befindet sich ja in einer synchronized Methode, und wenn ich mich richtig erinnere ist dann garantiert dass man immer die "richtigen" Werte sieht. Ich meine, es ist definitiv klarer wenn man volatile dabei stehen hat, aber notwendig muesste es nicht sein, oder?
Ich habe jetzt nicht die Zeit und Musse, mir das jetzt in der JLS im Detail anzusehen. Es wird zwar geschrieben, dass das volatile einen synchronen Zugriff gibt, aber ob die synchronized Methode da schon ausreicht? Das gibt ja nur eine Lock Action auf dem Monitor der Instanz.
Das ist aber doch nicht ausreichend, denn damit wird ja auch nur der Zugriff auf eben diesen Monitor gesperrt. Die Felder können ja prinzipiell weiterhin beliebig verändert werden - der Lock bezieht sich ja nicht auf diese.

Da die Felder aber nur in synchronized Methoden verändert werden, dürfte es nach meinem aktuellen Verständnis ohne große Analyse der JLS, auch ohne volatile funktionieren.

Daher würde ich auf jeden Fall immer volatile nutzen. Wie @Robert Zenz schon richtig bemerkte: Es ist definitiv klarer und man vermeidet mögliche Nebeneffekte die man sich nicht erklären kann. Ich denke, es gibt nichts schlimmeres als einen Bug zu haben, der durch die Unit Tests nicht abgedeckt werden kann. Alle Unit-Tests laufen (evtl. hat man auch die tolle Situation, dass sie hin und wieder mal einen Fehler zeigen, wer weiss? Den Luxus hat man aber in der Regel nicht einmal) und nun finde mal den Fehler. Das was man eigentlich schon lange nicht mehr hatte: Debug-Sessions (bei denen der Fehler nicht auftritt weil man ja Schritt für Schritt durchgeht und dabei dann die Timining-Probleme mit großer Chance nicht haben wird) oder ein Durchgehen von Traces .... Wie viele Tage oder Wochen sollen sich wie viele Entwickler damit beschäftigen? :)

Das wäre meine Position dazu. Ein volatile zu viel bringt diese Situation nicht und ein volatile zu wenig kann zu so einer Situation führen. Alles volatile machen ist natürlich nicht sinnvoll, aber da wo mehrere Threads zugreifen kann das durchaus Sinn machen.
 

KonradN

Super-Moderator
Mitarbeiter
Obwohl ich es könnte,
Wenn man etwas beurteilt, dann muss man Argumente liefern. Nur irgendwie sind die bisher ausgeblieben. Wenn Du Argumente für Deine Position bringen würdest ggf. mit klaren Hinweisen auf die Stellen der JLS, aus denen Du genau deine Position schlussfolgerst, dann wäre diese ganze Meta-Diskussion hinfällig und auch Robert würde sich bestimmt positiv äußern von wegen "Vielen Dank, das war so nicht bekannt" oder so ähnlich,

So ist das leider nur eine einfache These von Dir ohne wirkliche Erläuterung.

Aber das ist nur meine einfache Sicht und das muss man nicht vertiefen.
 

mrBrown

Super-Moderator
Mitarbeiter
Ich habe mich im Ton vergriffen. Obwohl ich es könnte, steht es mir nicht zu, @Robert Zenz zu beurteilen.

Der letzte Satz sollte eine wertfreie Aussage sein, ist mir aber misslungen. Mea culpa. 🙈
Nur falls das nicht deutlich genug war: Die Aussage von @Robert Zenz ist völlig korrekt (und explizit auf diesen Fall beschränkt, als nicht sicheres Wissen gekennzeichnet und explizit um einen Teil zur Verständlichkeit ergänzt, alles ziemlich wichtig bei professioneller Software-Entwicklung) - deine Aussage dagegen war absolut formuliert, aber schlicht.
Dein Vergreifen im Ton sagt also nur über dich was aus - einerseits über deinen Umgang mit anderen, und andererseits über dein „Halbwissen“ und damit deine eigene Meinung über deine Eignung zur Software-Entwicklung ;)
 

mrBrown

Super-Moderator
Mitarbeiter
Daher würde ich auf jeden Fall immer volatile nutzen. Wie @Robert Zenz schon richtig bemerkte: Es ist definitiv klarer und man vermeidet mögliche Nebeneffekte die man sich nicht erklären kann. Ich denke, es gibt nichts schlimmeres als einen Bug zu haben, der durch die Unit Tests nicht abgedeckt werden kann. Alle Unit-Tests laufen (evtl. hat man auch die tolle Situation, dass sie hin und wieder mal einen Fehler zeigen, wer weiss? Den Luxus hat man aber in der Regel nicht einmal) und nun finde mal den Fehler. Das was man eigentlich schon lange nicht mehr hatte: Debug-Sessions (bei denen der Fehler nicht auftritt weil man ja Schritt für Schritt durchgeht und dabei dann die Timining-Probleme mit großer Chance nicht haben wird) oder ein Durchgehen von Traces .... Wie viele Tage oder Wochen sollen sich wie viele Entwickler damit beschäftigen? :)
Vor allem wäre es auch ein Fehler, der durch auf den ersten Blick harmloses Refactoring auftreten würde, zB wenn man synchronized durch Locks ersetzt.

Und das fiese dabei ist, dass mit Debugger die Optimierung nicht greift und der Fehler gar nicht erst auftritt, und ähnliches dürfte auch für die meisten Unit Tests gelten.
 

temi

Top Contributor
Es wird zwar geschrieben, dass das volatile einen synchronen Zugriff gibt, aber ob die synchronized Methode da schon ausreicht? Das gibt ja nur eine Lock Action auf dem Monitor der Instanz.
Das ist aber doch nicht ausreichend, denn damit wird ja auch nur der Zugriff auf eben diesen Monitor gesperrt.
Ich weise ausdrücklich darauf hin, dass es sich nur um Halbwissen handelt, aber im ober verlinkten Auszug aus der JLS steht:
This prevents method one and method two from being executed concurrently, and furthermore guarantees that the shared values of i and j are both updated before method one returns. Therefore method two never observes a value for j greater than that for i; indeed, it always observes the same value for i and j.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
Leyla Thread isInterrupt Java Basics - Anfänger-Themen 18
P Meldung aus Java-Klasse in Thread an aufrufende Klasse Java Basics - Anfänger-Themen 1
A Thread XML-Dateien zusammenfügen Java Basics - Anfänger-Themen 11
F influxdb Upload in eigenem Thread Java Basics - Anfänger-Themen 2
frager2345 Thread - Methoden synchronized deklarieren Java Basics - Anfänger-Themen 10
berserkerdq2 Größter unterschied von extends thread und implements runnable? Java Basics - Anfänger-Themen 2
T Thread beenden aus zweiter Klasse Java Basics - Anfänger-Themen 4
A Thread - Synchronized Java Basics - Anfänger-Themen 10
A Thread Producer - Consumer Java Basics - Anfänger-Themen 1
A Thread-Semhapore Java Basics - Anfänger-Themen 0
A Thread-Cyclicbarrier Java Basics - Anfänger-Themen 4
B In einem Thread Endlosschleife beenden Java Basics - Anfänger-Themen 19
A Thread-Verklemmung Java Basics - Anfänger-Themen 10
A Thread-Schreibe-Lese-Problem Java Basics - Anfänger-Themen 4
A Thread find number Java Basics - Anfänger-Themen 8
F Thread.sleep() Java Basics - Anfänger-Themen 5
F Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 11 at main.main(main.java:11) Java Basics - Anfänger-Themen 2
A Thread Java Basics - Anfänger-Themen 3
M Exception in thread "main" java.util.NoSuchElementException Java Basics - Anfänger-Themen 2
A Thread Java Basics - Anfänger-Themen 8
B Compiler-Fehler Fehlermeldung Exception in thread, falsche Eingabewert Java Basics - Anfänger-Themen 2
M Thread-Zustände Java Basics - Anfänger-Themen 6
CptK For-Schleife in Thread nach jedem Durchlauf pausieren Java Basics - Anfänger-Themen 35
S Kriege Fehler "Exception in thread" beim Benutzen von SubStrings. Java Basics - Anfänger-Themen 2
B Endlosschleife Thread sauber beenden Java Basics - Anfänger-Themen 19
D Java Thread wartet nur ein mal Java Basics - Anfänger-Themen 1
D Java Thread wartet nur ein mal Java Basics - Anfänger-Themen 0
O Exception in thread "main" java.lang.ArithmeticException: / by zero Java Basics - Anfänger-Themen 4
C Thread und TimerTask, Verstädnisproblem Java Basics - Anfänger-Themen 10
amgadalghabra Sorting Thread Launcher Java Basics - Anfänger-Themen 3
B Exception in thread "AWT-EventQueue-0" java.util.ConcurrentModificationException Java Basics - Anfänger-Themen 8
A Thread Java Basics - Anfänger-Themen 4
A Thread Java Basics - Anfänger-Themen 1
A Thread Java Basics - Anfänger-Themen 0
R Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException Java Basics - Anfänger-Themen 5
S Compiler-Fehler Exception in thread "main" java.lang.Error: Unresolved compilation problem: Java Basics - Anfänger-Themen 6
L Liste in anderem Thread laden Java Basics - Anfänger-Themen 1
B Thread / Prozess stoppen? Java Basics - Anfänger-Themen 22
I Compiler-Fehler Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 5 Java Basics - Anfänger-Themen 3
B Threads Thread sleep() Method einfache Frage Java Basics - Anfänger-Themen 8
W Thread Aufgabe - Vorgehensweise Java Basics - Anfänger-Themen 8
L Liste in anderem Thread laden Java Basics - Anfänger-Themen 0
J Threads PrograssBar update während thread Java Basics - Anfänger-Themen 13
D Compiler-Fehler Wert auf Datenbank übertragen und Sleep Thread Java Basics - Anfänger-Themen 3
Spencer Reid JavaFX Memory Thread.sleep Java Basics - Anfänger-Themen 1
S Thread.sleep mit JProgressBar Java Basics - Anfänger-Themen 1
ralfb1105 Frage zu Thread Synchronisation mit wait() und notify() Java Basics - Anfänger-Themen 3
R Exception in thread "main" java.lang.NullPointerException Java Basics - Anfänger-Themen 10
J JavaFX -> SocketIO -> Thread -> Update Label Java Basics - Anfänger-Themen 13
J Thread Handling Java Basics - Anfänger-Themen 9
A Problem mit Thread.sleep Java Basics - Anfänger-Themen 4
C Thread in Methode + raus aus der Schleife Java Basics - Anfänger-Themen 10
E Threads Thread in While-Schleife nur einmal starten Java Basics - Anfänger-Themen 2
F Daten von Thread an den aufrufenden zurückgeben Java Basics - Anfänger-Themen 22
C Compiler-Fehler Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2 Java Basics - Anfänger-Themen 3
B Thread Problem Java Basics - Anfänger-Themen 7
N KeyListener in Thread Java Basics - Anfänger-Themen 0
M Thread.sleep() Funktion Java Basics - Anfänger-Themen 1
W JLabel in Main aus Thread verändern. Java Basics - Anfänger-Themen 4
D Ausgeben welcher Thread gerade Arbeitet Java Basics - Anfänger-Themen 8
N Threads Thread-Fehler Java Basics - Anfänger-Themen 2
F Thread um Uhrzeit ausführen Java Basics - Anfänger-Themen 5
F Get/Post als eigener Thread mit Rückgabe Java Basics - Anfänger-Themen 5
J Exception in thread "main" Java Basics - Anfänger-Themen 1
F Thread der auf eine Queue wartet, sicher beenden Java Basics - Anfänger-Themen 4
B Animation mit Thread(s) Java Basics - Anfänger-Themen 23
I Thread.sleep (1000); Java Basics - Anfänger-Themen 1
M Threads Jede Klasse einem Thread zuweisen Java Basics - Anfänger-Themen 7
J Java Thread cancel() und wiederbeleben Java Basics - Anfänger-Themen 4
J BouncingBalls 1 Thread Java Basics - Anfänger-Themen 3
L Fehler: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException Java Basics - Anfänger-Themen 4
J Timer oder Thread programmieren ? Java Basics - Anfänger-Themen 10
fLooojava Laufender Thread | Boolean ändern Java Basics - Anfänger-Themen 9
T Thread Pool mit Work Stealing Java Basics - Anfänger-Themen 1
R Java Thread Java Basics - Anfänger-Themen 10
J Welche Methoden laufen im neuen thread ?? Java Basics - Anfänger-Themen 9
S Java memory fehler: Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap spa Java Basics - Anfänger-Themen 5
K Thread - Methoden in die run Methode Schreiben Java Basics - Anfänger-Themen 5
N Threads Exception in thread "main"... Feher bei dem Versuch ein Radius zu berechnen Java Basics - Anfänger-Themen 4
A Code läuft nicht, Fehlermeldung Exception in thread "main" java.lang.Error: Unresolved compilation " Java Basics - Anfänger-Themen 11
V Threads Exception in Thread behandeln Java Basics - Anfänger-Themen 3
S Methoden Multi-Thread und Methoden Objects. Java Basics - Anfänger-Themen 1
J Thread erstellen (BlueJ Projekt) Java Basics - Anfänger-Themen 3
P Exception in thread "main" java.lang.NoClassDefFoundError: Java Basics - Anfänger-Themen 1
F Threads Variable aus einem Thread in main Methode? Java Basics - Anfänger-Themen 9
K Exception in thread "main" Java Basics - Anfänger-Themen 7
L Thread-Frage Java Basics - Anfänger-Themen 2
E Was ist ein idle-thread? Java Basics - Anfänger-Themen 1
D Exception in thread "AWT-EventQueue-0" Java Basics - Anfänger-Themen 8
J Threads Prozess in Thread auslagern Java Basics - Anfänger-Themen 2
G Thread mehrmals starten und schliessen Java Basics - Anfänger-Themen 6
F Thread Koordination (Vorteile/Nachteile) Java Basics - Anfänger-Themen 0
O Thread aus dem Thread stoppen Java Basics - Anfänger-Themen 6
O Swingworker/Thread Java Basics - Anfänger-Themen 3
R Focus auf JPanel im Thread Java Basics - Anfänger-Themen 9
S musik in eigenem thread Java Basics - Anfänger-Themen 2
A Klasse,Vererbung,Interface,Singleton,Thread Java Basics - Anfänger-Themen 5
IngoF GUI mit Thread Daten austauschen. Java Basics - Anfänger-Themen 6
L Compiler-Fehler Exception in thread "main" java.lang.NullPointerException Java Basics - Anfänger-Themen 2
F Exception in thread main java.lang.StackOverflowError Java Basics - Anfänger-Themen 3

Ähnliche Java Themen

Neue Themen


Oben