Klassen in "abgeschirmten Bereich" laden?

[Volvagia]

Ich vermute zwar, dass es nicht geht, aber gibt es eine Möglichkeit, Klassen in einen sozusagen abgeschirmten Bereich zu laden? Eventuell sogar in einer eigenen Sandbox? Aber schon nur als Klasse und nicht als Anwendung. Ich will verhindern, dass ein Fehler in einen Plugin Auswirkungen auf das Hauptprogramm hat. Mir ist schon öfters passiert, dass dann garnichts mehr funktioniert hat. :bahnhof:

 

[Marco13]

Abgesehen von "Killern" wie einem OutOfMemoryError und so sollte es doch reichen, wenn man alles, was das Plugin macht, in ein

try
{   
    plugin.doit();
}
catch (Throwable t) 
{
    System.out.println("Alles ist gut, alles ist gut, alles ist gut...");
}

einwickelt... oder was meintest du?

 

[Volvagia]

Theoretisch schon. Aber ich hab schon Fälle gebaut, in denen ich versehendlich den EDT blockiert hatte, und dann ging natürlich so gut wie gar nichts mehr. Fehler passieren halt, aber dann hätte ich gerne die Möglichkeit, wenigstens noch die anderen Programmteile zu benutzen.

 

[Marco13]

Hmja. Wenn man davon ausgeht, dass Plugins normalerweise in einem eigenen Thread laufen, können die natürlich an sich schon blockieren - da hilft ggf. auch ein interrupt() nichts. Aber beim EDT ist es natürlich noch kritischer. Theoretisch wäre die einzige Möglichkeit da ja, einen weiteren Thread zu haben, der regelmäßig prüft (wie auch immer) ob der EDT noch "lebt" und nicht blockiert ist - und ihn ggf. killt und neustartet Spontan wüßte ich nicht, wie das gehen sollte. Vielleicht könnte man was tricksen, aber schön würde es sicher nicht werden...

 

[Volvagia]

Derzeit ist es ja so, dass die Plugin-Mainclass von einer Subklasse von JInternalFrame erbt und so zum Hauptprogramm geadded wird. Dadurch kann ich dabei auf den EDT natürlich nicht verzichten, weil er ständig gebraucht wird. Und wenn ich bei jeden Listener-Aufruf etc. einen Thread starte, wird das vor allem zusammen mit den Aufrufen der EventQueue für GUI-Änderungen sogar noch unlesbarer. :autsch:

Eine Idee hätte ich dazu schon: Bei Programmstart im EDT einen neuen Thread starten, und ihm eventuell mit join blockieren damit sie sich nicht in die Quere kommen. Dieser hohlt sich per Toolkit#getSystemEventQueue()#getNextEvent() in einer Schleife alle Events, und dispatcht sie so wie sie es erwarten. (ActionEvent z. B. dispatch() aufrufen, Component-Events per dispatchEvent am Source weiterleiten etc.). Bevor er das jedes mal macht updatet er eine Variable mit Timestamp damit er überprüft werden kann. Sobald der erste Thread festhängt startet der Kontrollthread einen neuen Dispatcher und setzt bei den alten eine boolean falls er doch irgendwann nochmal weiterarbeitet, damit er die Schleife verlässt und stirbt.

Das würde mich testweiße interessieren, aber ich denke ein Einbau wäre eine schlechte Idee.

 

[Marco13]

Eine Idee hätte ich dazu schon: Bei Programmstart im EDT einen neuen Thread starten, und ihm eventuell mit join blockieren damit sie sich nicht in die Quere kommen. Dieser hohlt sich per Toolkit#getSystemEventQueue()#getNextEvent() in einer Schleife alle Events, und dispatcht sie so wie sie es erwarten. (ActionEvent z. B. dispatch() aufrufen, Component-Events per dispatchEvent am Source weiterleiten etc.).

Das klingt etwas konkreter, als ich das spontan hätte sagen können, aber ... hast du das schon... "evaluiert"? Also, dass er "alle Events so dispatcht, wie sie es erwarten" klingt schwierig: Dort kommen auch Events, deren Typen nicht 'public' sind, und das dispatching an sich ist... .... ... kompliziert (sehr, sehr, sehr kompliziert). Allein das coalescing von Events, und das Filtering... Und wenn z.B. ein Modaler Dialog aufgeht könnte der leicht als "aufgehängter Thread" mißverstanden werden - da muß man schon ziemlich aufpassen....

 

[Volvagia]

Da hast du wohl recht. Coalescing ist das zusammenfügen von Events, z. B. vom RepaintManager? Wobei ich so etwas ähnliches schon benutze um selbst modale Fenster anzeigen zu können:

public void startModal(Component parent)
{
	if(!EventQueue.isDispatchThread())
		throw new IllegalAccessError("Error: No Dispatcher!");
	
	if(parent == this)
		parent = null;

	while(parent != null && !(parent instanceof ApplicationFrame))
		parent = parent.getParent();
	
	setAlwaysOnTop(true);
	setUndecorated(true);
	setLocationRelativeTo(parent);

	if(parent != null && parent instanceof ApplicationFrame)
	{
		ApplicationFrame parentFrame = (ApplicationFrame) parent;
	
		parentFrame.setCatchingEvents(true);
		modalParentFrame = parentFrame;
		modalParentFrameLayer = modalParentFrame.getLayer();
		lastModalLayer++;
		modalParentFrame.setLayer(lastModalLayer);
		usedModalLayerSet.add(lastModalLayer);
	}
	start();
	startDispatchingEvents();
}
protected void startDispatchingEvents()
{
	if(!EventQueue.isDispatchThread())
		throw new IllegalAccessError("Error: No Dispatcher!");
	
	dispatchingEvents = true;
	
	EventQueue queue = Toolkit.getDefaultToolkit().getSystemEventQueue();
	while(dispatchingEvents)
	{
		AWTEvent event = null;
		try
		{
			event = queue.getNextEvent();
		}
		catch (InterruptedException e)
		{
			Thread.interrupted();
		}

		if(event == null)
			continue;
		
		Object source = event.getSource();

		if (event instanceof ActiveEvent)
			((ActiveEvent)event).dispatch();
		else if (source instanceof MenuComponent)
			((MenuComponent)source).dispatchEvent(event);
		else if (source instanceof Component)
			((Component)source).dispatchEvent(event);
		else
			System.out.println("Not dispatchable Event \"" + event + "\" with source \""+ source+"\"");
	}
}

 

[Marco13]

Hmja, wie schon angedeutet: Die Lösung ist sicher nicht trivial (im Sinne eines "EventQueue#setAutoRestartOnHangup(boolean autoRestart)" ) und man wird wohl ein bißchen den Code von EventQueue und Co durchpflügen und vor allem vieeel ausprobieren müssen. Aber vielleicht hat einer von den Leuten, die demnächst aufwachen, da noch eine Idee...