Creating a remote file system browser, SWT vs Swing
Few days ago some of my friends at Scali AS, Norway were wondering of how to write a file select dialog in java, to browse a file system of a remote machine. They were writing a RCP application based on Eclipse framework and working with SWT/JFACE widgets. Remote machine was a Linux server which acts as the front node to a Linux Cluster.
Given the problem my first thought was to extend and override the SWT FileDialog class or related content provider classes with my own implementation that fetchs the remote file structure over SSH. So I went throgh the SWT source codes to find out the feasibility of this solution. As many of us know that the SWT uses higher level OS dependent graphical components and those are rendered by the operating system. Therefore I didn't find any way to solve my problem with SWT libraries. "Open" method of the SWT org.eclipse.swt.widgets.FileDialog just calls the native OS method. So I was not able to plug my own file system model to the SWT FileDialog.
So obviously the next choise was the Swing JFileChoser component. As the file browse dialog needs to be just a popup, it is possible to call Swing FileChooser withing a SWT view classes by a general java call.
During the analysis I found that the Swing classes are well designed based on the MVC model. Swing components are designed to be crosspatform so the model hides the platform differences from the view. In the case of Swing file select dialog, the View is implemented as "javax.swing.JFileChooser" class and the "javax.swing.filechooser.FileSystemView" class provides the file system model to be used. Swing has different FileSystemView sub classes for different OS'. (examples WindowsFileSystemView and UnixFileSystemView).
So it seemed to be ideal for my requirement. All I need to do is to provide a my own subclass of FileSystemView(model) and pass an instance to JFileChooser(View) constructor. My subclass of FileSystemView will fetch remote file structure through SSH and render it according to the FileSystemView interface agreement.
Further analysis showed that the FileSystemView(model) interface uses java.io.File instances heavily to model file objects. In my requirement the File objects will not represent real file instances of the hosting machine but logical view of a file on the remote machine. For this reason I wanted File objects to behave in a disconnected manner from the hosting OS.
But unfortunately some methods like "exists()" of the java.io.File class is bound to the OS via security constraints. The problem is these methods of java.io.File class are badly designed to repersent only the real file entities of the hosting OS. It is not designed to work in a disconnected nature. If they had moved the OS dependent operations on to a util class and made File to be used in a disconnected manner then problems like mine would be solved perfectly. (Here someone may argue that is not the OOP way, but still it will make java file framework much more extensible)
Anyway even with some constraints it is possible to implement my idea with Swing JFileChooser where SWT fails to do so. This simply shows the extensibility provided by Swing compared to SWT. But SWT itself has many pros with it. In my expierience SWT provides a better user expierience in the sence of porformance and look n feel. Also the APIs are more natural for simple GUI programming.
Thus in my openion these two technoligies can be (and should be) used to complement each-other and not to substitute each-other....