Final Methode dennoch überschreiben!

[tuxedo]

Hi,

gibts irgend einen Trick per Reflection oder so mit dem ich eine final Methode, obwohl man es nicht können sollte, doch überschreiben kann?

Hintergrund:

Wir haben eine SWT Anwendung die jede Menge Runnables in den UI-Thread steckt um Dinge zu Zeichnen oder zu aktualisieren. Das führt, je nachdem wie der Benutzer die Anwendung konfiguriert, zu einem Overload so dass die Anwendung nicht mehr richtig reagiert, weil der UI Thread einfach zu viel zu tun hat.

Ich hab jetzt die Aufgabe einen Health-Monitor zu bauen der Auskunft darüber gibt "wie gut" es der Anwendung denn gerade geht.
Hab ein wenig geforscht und herausgefunden, dass in org.eclipse.swt.widgets.Synchronizer, eine Liste mit den Runnables (bzw. RunnableLocks) geführt wird. Ich kann Synchronizer zwar überschreiben und dem Display diesen eigenen Synchronizer als standard Synchronizer übergeben, doch hab ich nur 2 final Methoden die ich überschreiben/erweitern kann:

- syncExec()
- asyncExec()

Damit könnte ich selbst einen Zähler inkrementieren den ich von aussen abfragen kann. Aber zum dekrementieren des zählers müsste ich in die Methoden, die direkt von der Displayklasse genutzt werden eingreifen.

Wenn das mit dem "doch überschrieben" nicht geht: Hat jemand ne andere Idee für mich wie ich das generisch lösen kann ohne die bereits bestehenden Runnables so zu modifizieren dass sie mit dem letzten Statement in run() den Zähler dekrementieren?!

Gruß
Alex

P.S. Methodennamen die mit einem blauen dreieck im Eclipse Outline-View gekennzeichnet sind, sind dich final, oder?

 

[SlaterB]

kannst du nicht run() überschreiben
und

..
super.run()
..

ausführen?

 

[tuxedo]

Sorry, war etwas spät mit meinem Edit. Methoden sind offensichtlich final, nicht private.

Um run() zu Überschreiben, müsste ich doch alle Runnables nochmal in die Hand nehmen und anpassen. Und die Lösung wäre dann nur für angepasste, spezielle Runnables tauglich.

An das field "messages" und "messageCount" (das wäre schon der optimale Zähler) komm ich leider auch nicht ran ...

 

[Wildcard]

Eclipse Anwendung, oder reine SWT Anwendung? Wenn es eine Eclipse Anwendung ist, verwende Jobs.

 

[tuxedo]

Eclipse-Anwendung.
Was ist an Jobs besser? Hast du da vllt. nen Link parat (ausser nen APIDoc Link)?

BTW: Die Tasks hier MÜSSEN im UI Thread (sämtliche Aufgaben stehgen da in Verbindung mit SWT (UI updated, SWT-Ole-Kommunication, ...)) laufen. Laufen die Jobs da auch drin oder laufen die in nem eigenen Thread?!

Hab die Sache mit dem MessageCount lösen können:

 Method m = display.getClass().getDeclaredMethod("getMessageCount",null);
		    m.setAccessible(true);
		    int result = (Integer) m.invoke(display, null);
		    System.out.println("messageCount="+result);

Das Display selbst hat intern eine Methode um die Anzahl der zu verarbeitenden Messages abzufragen. Aber eben nur intern. Aber mit dem Workaround kommt man auch so dran.

Nebenbei:
Ist die eine Technik bekannt mit dem man einen im UI Thread blockierenden Task (jetzt mal losgelöst von den Runnables, also mehr allgemein) abschießen kann so dass die Anwendung wieder läuft?

Gruß
Alex

 

[Wildcard]

Jobs sind mit das beste was Eclipse zu bieten hat...
http://www.eclipse.org/articles/Article-Concurrency/jobs-api.html
Jobs laufen in Workerthreads, aber du kannst auch dort Arbeit in den UI Thread verschieben. Der große Vorteil den dir ein Job für dein Vorhaben bieten kann, ist das du größeren Einfluss auf das Scheduling hast. Du kannst beispielsweise die maximale Anzahl von Jobs aus der gleichen Familie beschränken und soweit ich das Problem verstanden habe, ist das genau was du suchst.

 

[tuxedo]

Die einzige Arbeit die zu verrichten ist, ist bei mir UI arbeit. Das ist ja die Sache. Ich hab nahezu keine Zeile Code in meinen Runnables die nicht die UI betreffen. Sprich, ich hab keine Programmlogik im UI Thread laufen, sondern SWT-Stuff (Message Ticker zeichnen und updaten, mit SWT geladenen OleControlSites mit Methodenaufrufen befeuern und und und. Eben alles was definitiv den UI Thread brauch weil ich sonst Exceptions bekomme weil ich nicht im UI Thread bin.

Von daher bin ich mir nicht sicher ob da Jobs hilfreich sind.

Gruß
Alex

P.S. Ist keine normale "Büroanwendung". Hier gehts um dutzendweise Videos und allerlei grafische Spielereien mit den Videos, gefolgt von der Tatsache, dass die meisten Videos über die SWT-Ole Brücke (also ActiveX Controls) angebunden sind, und diese Kommunikation eben auch wieder den UI Thread beansprucht (bzw. beanspruchen muss).

 

[Ariol]

EDIT: So ist's besser (Reihenfolge der Threads):

Eine sich selbst abarbeitende Queue:

import sun.misc.Queue;

public class RunnableQueue extends Queue {

	int maxRunnables = 2;
	
	Thread queueManager = new Thread() {		
		public void run() {
			while (true) {
				try {
					if (!isEmpty() && Counter.getValue() < maxRunnables) {
						try {
							Thread t = new Thread((Runnable) dequeue()) {
								@Override
								public void run() {

									Counter.increase();
									super.run();
									Counter.decrease();
								}
							};
							t.start();

						} catch (InterruptedException e) {
							e.printStackTrace();
						}
					}
					sleep(10);
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		}
	};
	
	public RunnableQueue(int maxRunnables) throws Exception {
		if(maxRunnables <= 0)
		{
			throw new Exception("maxRunnables must be >= 1");
		}
		
		this.maxRunnables = maxRunnables;		
		queueManager.start();
	}

}

Ein statischer Zaehler:

public class Counter {

	private static Integer count = 0;
	
	public static synchronized void decrease()
	{
		synchronized (count) {
			count--;
		}
	}
	
	public static synchronized void increase()
	{
		synchronized (count) {
			count++;
		}
	}
	
	public static synchronized int getValue()
	{
		return count;
	}
}

Und zum Testen:

public class CounterTest {
	public static void main(String[] args) {
		startSynchronized();

	}

	public static void startSynchronized() {

		try {
			RunnableQueue rQueue = new RunnableQueue(10);

			for (int i = 0; i < 100; i++) {

				final int j = i;

				rQueue.enqueue(new Thread() {

					public void run() {
						System.out.println(j + " - " + Counter.getValue());
						try {
							sleep(1000);
						} catch (InterruptedException e) {
							e.printStackTrace();
						}
					}

				});
			}

		} catch (Exception e) {
			e.printStackTrace();
		}

	}
}

Thread hab ich in der Testklasse nur benutzt um mit sleep arbeiten zu koennen.

 

[tuxedo]

Dumme Frage @Ariol, aber hast du meinen ersten Post zuende gelesen oder nur die ersten Paar brocken?!

AFAIK ist mit SWT eine solche Queue icht möglich, der queued selbst.

Sorry, aber dein Post ist leider am Ziel vorbei gegangen.

- Alex

 

[Ariol]

Wieso sollte der nicht moeglich sein?

 

[tuxedo]

Fragen beantwortet man doch nicht mit gegenfragen?!

Nochmal:

In SWT gibt es die Klasse Display. Die brauch ich um überhaupt was auf den Schirm zu kriegen. Display verwendet intern eine Klasse "Synchronizer", welcher eine "List" mit RunnableLocks führt.

Ich kann zwar Display meine eigene "Synchronizer" Implementierung mitteilen (also so in etwa wie du's dort oben aufgeführt hast), nur muss diese Implementierung von "Synchronizer" erben. Und dort gibt es nur 2 Methoden die sich überschreiben lassen.

Und das sind die Methoden um neue Tasks in die Liste einzufügen. Alle anderen Methoden, die Display z.B. verwendet um einen Eintrag aus der Liste zu holen, sind final. Sprich ich kann sie nicht überschreiben. Folglich kann ich zwar einen Zähler inkrementieren wenn ein neuer Task reinkommt, aber beim entfernen des Tasks durch "Display" kann ich den Zähler nicht dekrementieren weil ich an die Methoden nicht rankomme.

Schau dir doch mal den Source zu "Display" und "Synchronizer" an. Dann siehst du was ich meine.

Aber wie schon gesagt: Ich hab eine Lösung gefunden, und die besteht darin "Display" direkt nach dem Zählerstand zu fragen. Das geht auch über eine "private final" Methode. Aber die muss ich nciht überschrieben, ich muss lediglich konfigurieren dass die Methode doch "accessible" ist und schon kann ich sie aufrufen (siehe oben). Sprich: Ich brauch ncith rund 100 Zeilen Code für eine eigene Queue implementierung die so gar nicht zum Ziel führt, sondern nur 2-3 Zeilen um die "gesperrte" Methode doch aufrufen zu können.

- Alex