Die folgende Abbildung zeigt die jowidgets Architektur.

UI Code wird gegen das Widget API implementiert. Die Default Implementierung von jowidgets verwendet das Widget SPI ^[2], um die Features der API zu implementieren. Für die SPI existieren derzeit Implementierungen für Swing, SWT und RWT. Die SPI Implementierungen enthalten Adapter, welche die SPI Widget Schnittstellen implementieren.

Die Schnittstellen der SPI Widgets wurden bewusst schlank gehalten, um das Hinzufügen einer neuen UI Technologie möglichst einfach zu gestalten, ohne dabei Abstriche bei der Mächtigkeit der API machen zu müssen.

Dies soll am Vergleich mit dem Eclipse Standard Widget Toolkit (SWT) erläutert werden. Dort findet man eine ähnliche Architekur. Es gibt eine API, welche für verschiedenen Platformen implementiert ist. Die Implementierungen stellen im Prinzip Adapter bereit, welche mittels JNI Methodenaufrufe an das jeweilige native UI Toolkit delegieren.

Wer SWT kennt, weiß jedoch, dass sich die Verwendung der API zum Teil sehr low level anfühlt. Will man hingegen eine API Implementierung machen (zum Bespiel für Swing oder JavaFX), sieht aus dieser Perspektive betrachtet die API sehr mächtig und komplex aus. Bei der Definition der Schnittstellen musste immer ein Kompromiss aus einfacher Implementierbarkeit und komfortabler Nutzbarkeit gemacht werden.

Durch die Aufteilung in API und SPI kann die API mächtige Funktionen enthalten, welche aber nur ein mal implementiert werden müssen. Auf der anderen Seite ist eine SPI Implementierung für eine neue UI Technologie keine allzu komplexes Aufgabe, was die Option bietet, geschrieben UI Code auch für zukünftige UI Technologien wiederzuverwenden.

Im diesem Kontext liegt vielleicht der Vergleich nahe, die jowidgets SPI mit SWT zu vergleichen, und die jowidgets API mit JFace. Dieser Vergleich ist jedoch nicht ganz korrekt, denn: