Java platform is excellent for software development because it enables high productivity, has a very large community, there are many tools, libraries and frameworks for Java. Unfortunately there is no large number of Java-based desktop applications in everyday use. There are very few smaller utility applications especially for desktops. Simple indicators for this are popular computer magazines (for general public). Reviews of Java-based desktop applications are rare and accompanying CD/DVDs seldom contain Java desktop applications.
These are the main premises of the project and they will not be discussed here any further. A detailed discussion about Java's bad reputation on desktops (even today) is out of the scope of this documentation.
JavaQx framework proposes a hybrid approach to solve this problem. There already
are good toolkits and frameworks proven in both implementation and API.
So, it would be reasonable to combine them to address the problem. Generally,
there is no need to introduce any new concepts or to reinvent the wheel
.
Swing already has a pretty good API. But Swing certainly has some problems (if it were enough, Eclipse would not have been built on top of SWT). Dependency on AWT (the layer beneath) and implementation issues are probably the major ones. JavaQx takes Swing's good API but drops the legacy code and dependency. To implement the API JavaQx takes SWT approach. SWT has a successful implementation but its API is less flexible then Swing's. It would be ideal to implement a Swing-like API over SWT but it is hard to achieve, even impossible in some aspects (although there are ongoing projects). To avoid reinventing the wheel, JavaQx uses Qt as the main underlying layer for implementation. This is because Qt is a mature toolkit and has an API close to Swing's (Qt has already a Java port called QtJambi but it is more suited for Qt developers - signals, slots and resource compiling are strange concepts in Java world). The following figures illustrate this.
![]() |
![]() |
Figure 1: JavaQx Surroundings | Figure 2: JavaQx Position |
JavaQx uses JNI to bridge Java and Qt. It has fat
native layer
(opposite of SWT) and mid
Java layer. Java layer is not thin because it
caches some information to lower the frequency of JNI calls (Java to C/C++
switches are performance expensive). Also, the framework has a single source
code for all supported platforms.
The framework dependency and relation to other components are shown in following figure.
One of the most important parts of the framework for its users is the component hierarchy. QSwing component hierarchy is shown in Figure 4. It is simpler and more consistent then Swing component hierarchy. Not all of the components are containers. Also, there are few new components like: status bar, tool button, tool window and font chooser.
The main design patterns behind the implementation of the framework are proxy and adapter pattern (as defined by GoF). They are combined into Bridge classes. These classes bridge JavaQx and Qt objects (not true bridge pattern because both ends of the bridge are known). This is illustrated in Figure 5.
JavaQx requires Java 1.4 or higher. It has been tested on Sun, GCJ and Apache Harmony Java implementations both on Windows and Linux.
To use the framework add yu-ac-bg-etf-javaqx.jar to your application's classpath and copy shared library yu-ac-bg-etf-javaqx (.dll for Windows or .so for Linux) into the working directory of your application. The shared library can also be placed in a folder where yu-ac-bg-etf-javaqx.jar file is (just keep these two files together). The native part of the framework is not packed inside the jar file (like SWT) because of its size. Unpacking it could degrade the application's startup performance. Figure 6. illustrates JavaQx deployment and manifestation.
Also, JavaQx applications can be compiled with native (ahead-of-time) compilation with GCJ (to solve the problem of smaller applications). Natively compiled applications are stand-alone (without JRE) desktop applications equal with other ones on a particular operating system. They have its own name in task manager, its own taskbar group on taskbar, and they can have an application icon. Also, they could easily be packed into stand-alone installers using installer generators like NSIS. As an illustration of this, you can try the native QSwingSet for win32 packed into QSwingSetInstaller.exe (6.5MB).