Vielen Dank!
jetzt sehe ich langsam wohin die Reise geht - ich hatte gehofft, dass es für meinen use-case irgendein "high-level-konstrukt" gibt. Ich werde jetzt mal versuchen konkret zu beschreiben was mein Programm tut und wie ich es bisher umgesetzt habe - auch mit Hilfe aus diesem Forum (
http://www.java-forum.org/allgemeine-java-themen/108576-api-methode-immer-laeuft-stop-gerufen.html):
also ich hab eine Klasse in der die Arbeit läuft (Ordner abarbeiten, wenn fertig warten bis neuer Ordner entsteht - "jNotify"). diese Arbeit läuft in einem separaten Thread mit while(!stop)-Schleife. Es gibt öffentliche Methoden Stop() und Start() die diese Schleife steuern (stop() setzt stop=true, start- startet den thread) - inziwschen funktioniert diese Steuerung auch über jmx.
Funktional ist das ganze also fertig die frage ist nur wie sieht die main-Methode dazu aus. Diese soll eben nur ewig laufen und nix tun außer das Start und Stop über jmx bereitstellen. Natürlich wäre ein "shutdown" auch nicht schlecht: stop(); return; (sich selbst beenden aber vorher warten bis stop() ausgeführt wurde).
Die Frage ist ob für diesen Use-Case "ScheduledExecutorService" geeignet ist. Die einzigen Ereignisse wären das Aufrufen von Methoden über JMX?! Deswegen finde ich polling ungünstig - entweder muss der benutzer warten bis das Programm reagiert oder man pollt zu oft - im schnitt pollt man eh viel zu oft (das Programm soll Wochen Monate laufen ohne das ein User irgendwas macht)
Die Alternativen von die Fart versthe ich leider noch weniger: "Thread#sleep, Thread#wait und Thread#notify" und "... implementieren (oder einen Observer) und fertig"
Wie sieht die Verwendung dieser Konstrukte in einem Beispiel oder Pseudecode aus? Gibt es irgendwo ein Beispiel (wonach googelt man) für eine ewig laufende, auf (user)-ereignisse wartende main()-methode?