Ich wurde wegen einer neuen Funktionalität für dWb+ zum gründlichen Nachdenken gezwungen...

Problemstellung

Die Voraussetzungen für mein Nachdenken über System.out per Thread war die Idee, ganz normale Java-Programme als Module für dWb+ nutzen zu können. Normale Java-Programme meinte dabei solche, die über eine Methode verfügen wie

public static void main(java.lang.String[] args)

Ich wollte das mit einem Modul erreichen, das einen String-Eingang hat, der vom Anwender beliebig vervielfältigt werden kann - je nachdem, wieviele Parameter die Main-Methode erwartet. Als Property des Moduls wollte ich den Namen der Klasse mit der zu startenden Main-Methode definieren. Die Ausgänge des Moduls sollten Stdout, Stderr und Rückgabewert der Ausführung der Main-Methode sein. Diese drei wollte ich dabei noch in eine Bean kapseln.

An diesem Punkt stellte ich fest, dass die Umsetzung nicht so straightforward werden würde, wie ich mir das gewünscht habe: Wie sollte ich an die Streams herankommen? Wenn ich die Methode main einfach aufrufe - was ja per Reflection trivial ist - ist es keine eigene Anwendung und schreibt einfach alle Ausgaben auf die Streams von dWb+ - keine gute Idee...

Einen neuen Prozess zu starten ist ebenfalls nicht uneingeschränkt zu empfehlen: dWb+ benutzt einen eigenen ClassLoader - den könnte man einem neuen Prozess nicht auf einfache Art und Weise mitgeben.

Stdout und Stderr per Thread

Man könnte statt dessen die Streams für Stdout und Stderr der Anwendung dWb+ durch eine eigene Implementierung ersetzen, die abhängig vom Thread, der in diese hineinschreiben möchte, unterschiedlich reagiert. Dann könnte man zum Beispiel an dieser Implementierung Visitors registrieren. Setzt man das beschriebene Modul als ThreadedModule um, kann man auf den Threadnamen zugreifen und für die Ausführung der main-Methode dann Streams registrieren, in die alle Ausgaben dieses Threads umgeleitet werden.

Klingt wie eine elegante Methode - und der Geek in mir jubelte bereits darüber. Im Lichte der speziellen Anforderungen jedoch habe ich - unterstützt durch Informationen von Tante Unbubble - mich gegen diese Variante entschieden: Damit laufen Anwendungen im Kontext des Prozesses dWb+ , über die ich keine Kontrolle habe. Damit haben sie die Kontrolle über alle Singletons in der JVM. Das potentielle Problem damit lässt sich am einfachsten mit dem Szenario beschreiben, dass im Zuge der Ausführung der Anwendung, zu der die betreffende main-Methode gehört, die System.out und System.err Printwriter gesetzt werden - damit ist meine schöne Thread-spezifische Implementierung unwiederbringlich verloren und die Instanz dWb+ ist kaputt. Dazu kommt natürlich noch, dass in den Anwendungen, die über die main-Methode gestartet werden, unter Umständen die Methode System.exit aufgerufen werden könnte, was natürlich die Anwendung dWb+ sofort beenden würde - nein: für mich ist in diesem vorliegenden Fall eine Thread-spezifische Implementierung der Standard-Streams wirklich keine Option.

Die Lösung

Ich entschied mich daher dafür, die Lösung zwar trotzdem zu implementieren - und sei es auch nur als Fingerübung - das Problem für dWb+ aber anders zu lösen: Ich starte dort jetzt einen Prozess, der zunächst den in dWb+ benutzten ClassLoader aufsetzt und ihn zum ContextClassLoader macht. in diesem Prozess rufe ich dann einfach die main-Methode auf.