This article introduces the JyRCP demo combining Eclipse's Rich Client Platform platform with the Jython scripting language. It anticipates on the release of the Rich AJAX Platform later this year and investigates the added value of Jython scripting to make RCP apps run on RAP with minimal effort. For internal company web applications running on an intranet, this post predicts the end of classic AJAX webapp technology and encourages the early adoption of its improved successor(s). The current client side RCP framework is tipped as a relevant training environment in order to start using RAP as soon as it is released. The combination of Jython scripting and the RCP/RAP programming model should blow away any classic webapp in terms of productivity, usability and maintainability.
A modest attempt to predict the near future
The power of Python and Ruby scripting languages for rapid improvements in the usability of GUIs is already acknowledged by a growing number of software professionals. With the current focus on both productivity and usability, we can predict that the next step in upcoming technologies addresses the exact same concerns.
The most fundamental flaw in current rich web applications is the HTML language describing interfaces to the browser. HTML can describe document models very accurately. Rich UIs follow a model very different from documents. Most of the current developer effort is wasted translating the GUI model into the inaccurate document description language. Most usability flaws are a result of limitations and lack of insight in the resulting forest of workarounds.
The next step improving both productivity and usability is the introduction of a language or programming model natively designed for rich GUI modeling. This doesn't mean the death of HTML and AJAX in general. Those are still great for document-based sites on the public internet. For web based company applications running on an intranet the new GUI technologies should be quite valuable.
Evolving intranet UIs into more usable, better maintainable applications should be possible with a minimal amount of development effort. These applications will be as rich as client side applications while they remain web based, connected and easily deployed like their classic ancestors.
Developers should be early adopters and always be two steps ahead of the current hypes. After years of struggling with request/response-interaction and inappropriate presentation languages, I recommend spending some time studying the good old client side GUI programming models again anticipating their upcoming availability in web environments in the near future.
The current Rich Client Platform (RCP) programming model allows you to create extremely rich interfaces in an absolute minimum of code and effort. The class models are designed by the world's top architects and were continuously improved over several years. The platform has proven to be capable of managing very large applications because of a flexible extension and plugin model.
The release of Rich AJAX Platform (RAP) introduces a new programming paradigm for the web. The most important question is whether experienced web developers can quit their bad habits and recognize the value of this different approach. RAP only changes the programming model, but keeps using web browser technology under the hood. Potential competitors for RAP are likely to use browser plugins. For classic web developers RAP might be more appealing than the plugin-dependent counterparts.
This article discusses an early preview release of the Eclipse Rich AJAX Platform which ports the Rich Client Platform to the browser. By familiarizing with the classic RCP framework right now, you will be ready to take advantage of the full RAP platform at the end of the year. RAP completely abstracts away from technical details like HTML, AJAX, Request/Response interaction and web server management. Most code running on client side RCP can be ported to RAP with minimal modification.
The only thing they forgot in the RCP and RAP platform, is the advantage of scripting languages like Python and Ruby. For the current RCP platform, this article explains how you can fix this by introducing Jython in your own projects. And more importantly, it explains how Jython helps with the migration from RCP to RAP once it's there!
My first open source mini-project on Google Code
This week's experiment was to create an Eclipse Rich Client Platform application in Python. The outcome of this experiment is a tiny RCP app written in Java with the sole purpose of launching Jython scripts. The Jython classes are responsible for the actual implementation of GUI logic for your application. I created a mini-project in Jython to demonstrate some basic possibilities.
To share these preliminary results with the rest of the world, I created a Google Code project containing a Subversion repository, a Win32 binary ZIP and some open issues. The project description says:
JyRCP: Create GUIs in Jython based on the Eclipse RCP platform
Minimal set of Java classes in a Rich Client Platform application launching a minimal set of Jython files (demo app) to set up a client side GUI screen.
This project intends to allow GUI developers to be able to specify an interface using limited developer tools. Notepad should be enough; a text editor with Python syntax highlighting is recommended
This does not pretend to offer a complete framework. It's just an example how you could connect two existing frameworks (RCP and Jython) together assuming their combination offers more value than they offer separately.
The advantages
In the last post on Plone, we concluded that in order to optimize graphical user interfaces for usability, a powerful scripting language is more agile than a compiled language. You write less code to implement the same functionality. This implies you need to adjust your programming philosophy to Python's philosophy and realize the priorities are a bit different. Considering you're working on a GUI and not a back-end, you'll quickly learn this is a Good Thing.
Both Java and Python are strongly typed languages. The difference is that Python is dynamically typed where Java is statically typed. This means you save time, effort and code in the declaration of variables in Python and at the same time you can always be sure that an instantiated variable never changes from one type to another by accident. 1 + 1 = 2 and never 11 like you may have seen in other scripting languages.
Proper back-ends require less agility and more quality assurance and consistence. The compiled Java language has proven its strength guarding stability and continuity with compile-time error checking, explicit static type definitions and a wide variety of supporting development tools.
A full application ideally consists of a front-end in a scripting language connecting to a back-end in a compiled language. The Jython platform compiles Python script to native Java bytecode. For the virtual machine, there is little difference between the bytecode from Java and the bytecode from Jython. The bytecode compatibility reduces interoperability issues to a minimum. The only remaining challenge is the fact that Jython scripts are typically translated to bytecode at runtime making it more difficult to get the classpath right.
The Eclipse RCP platform offers a proven programming model for large desktop applications with very rich GUI features while remaining extensible, flexible and maintainable with a relatively easy to learn class library. It is based on the combination of SWT and JFace. SWT feels more responsive than Swing (although research does not confirm this) and is better appreciated by end users because the appearance remains consistent with the native look and feel of the platform it is running on. RCP ensures a clear separation between a widget library (SWT) and a programming model (JFace). RCP doesn't force you to use JFace if you prefer to invent your own programming model. To create a usable Swing application, you are practically forced to adhere to Swing's MVC programming model, which is overly complex for small applications. If you create a small application on the RCP platform, you can create perfect results using only SWT without JFace. As your applications grow, there is an increasing number of advantages in following the JFace programming model. In this case, the additional complexity of JFace pays for itself in the form of maintainability and standardization of your code base. The JyRCP demo app uses JFace by default. Small pure SWT applications in Jython are already available on other web sites and presentations.
On the Google Code site, you find an early release of Win32 binaries offering an Eclipse RCP application loading the Python files in the /demo directory by default. If you use this as a starting point to create your own GUI only modifying the Python files in a text editor, you'll be surprised by the complete lack of overhead of continuous recompilation and exporting of the resulting application. No Eclipse installation is required as long as you can run Java code on your machine.
Disadvantages
It may be my fault, so please correct me if I'm wrong, but I had some difficulties with RCP's classloading mechanism to locate my own resource files; and the Python sources in particular. As a result, I could either hard code the Python source directory, make it a configuration property or use a path relative to the runtime work directory - which may be error prone.
Writing SWT and JFace code in Java you have the advantage of Eclipse's code assistance, auto-completion, syntax checking and refactoring capabilities. Even though you're writing more code, the support of the IDE increases your productivity enough to compensate for the advantages of concise Python code.
On the other hand, in Python, you depend on manual code documentation and API references. When you're doing something new, this may slow you down. The advantage of the concise language only pays off after gaining experience or while doing repetitive efforts.
The current RCP code documentation and code examples assume Java as the default language. Borrowing existing code takes more time because you need to translate the code first.
In general, Jython, Java and RCP all give very descriptive and useful error messages when something fails. In my demo application however, there were some cases where the application refused to start without returning even the smallest hint of an error. Probably this is also just a flaw in my demo code and can be fixed later on. Descriptive error messages are a fundamental requirement when you're writing Python code in a simple text editor.
The current version of the demo application runs on Windows XP on my company laptop. Last week, I did some successful experiments on my Ubuntu Linux machine at home. To me, it seems like the development on both platforms is exactly the same. I know there are some differences in the underlying libraries because of native widget bindings, but that shouldn't affect the code base too much. Nevertheless, I couldn't get the Win32 code base to run on Linux without modification. I hope I can solve this issue very soon.
Definitions of extension points in the plugin.xml assume implementations in compiled Java classes. The current demo app offers default Java implementations dynamically redirecting calls to Python implementations indicated by the IDs specified in the plugin.xml. A single Java class can be bound to multiple different Python scripts when the IDs differ from each other. In order to make this work without additional configuration, Java and Jython need to agree on a naming convention similar to the launching routine. In the demo app, the ID in plugin.xml can be translated to the package and class name in Jython.
Design choices and considerations
Early in this post I mentioned that the demo app is an example of how you could connect RCP and Jython. There are many other ways to accomplish similar results.
I use a few Java classes to get the application started. The Java classes use a PythonInterpreter object to launch the Jython scripts. There are some assumptions in the Java code regarding the naming of the Jython packages and classes. You might prefer some configuration over these conventions or hard-coded dependencies.
Another alternative is to use only Jython code without a single Java class. You could choose whether you precompile the classes and describe them in the plugin.xml or whether you find a way to setup the GUI dynamically without a plugin.xml file.
The Jython scripts contain import statements directly referring packages and classes in the SWT and JFace class libraries. As a result, the scripts feel less Pythonic and more like direct translations of Java code. The import statements are only necessary when you're creating new instances of classes. After instantiations, all reference typing is done implicitly. In early experiments, I introduced Factory helper objects written in Java and injected into Python in order to get rid of all the explicit SWT-imports in Python. Inspired on the "Dependency Injection" design pattern, a simplified solution provides new class instances to the scripts. The consequence is you need to develop a large set of factories representing every part of the RCP framework including even the tiniest parts. The dependencies on factories turn out to be very intrusive on the code and the creation of classes feels unnatural to experienced RCP developers.
The demo app introduces a relatively large number of packages, each containing very few files. This may seem like overkill. Each major Python class has its own .py file with a name similar to the class name. This implies a little bit of duplication in order to simplify the search for specific classes. Additional classes in a .py file can be considered similar to private classes and inner classes in Java and should preferably not be used outside the .py file.
I'm not sure what the Python convention is for package definitions, naming and code separation. I think the current packages are intuitive to work with and prepared for larger applications. The division between several concerns in the application allows future addition of a code generation mechanism similar to the Ruby on Rails script/generate scaffolding construction. Such a script might also simplify the maintenance of dependencies in the plugin.xml file. Feedback and suggestions regarding Python packages are more than welcome though.
The initial demo application is pure application code and provides no abstractions anticipating on future reuse. Some Python implementations in the demo could have been more concise by abstracting away some details to more generic base classes. At this point however, I managed to control myself and chose not to start creating a framework (yet). For the framework to be any good, it's better to wait for real world application implementations and extract only proven parts to an abstract level. Those abstractions may become either Python script or Java code, depending on specific requirements.
Future potential of the Rich AJAX Platform
My initial motivation to connect Jython and RCP was the upcoming Rich AJAX Platform (RAP). The RAP project intends to translate most of the client side RCP platform into a server side AJAX based browser interfacing framework. With the RAP platform, many existing RCP applications can easily be modified to run through a browser interface with minimal impact. Or at least in theory they should. This asks for experimentation.
I saw a challenge in creating a single piece of code that runs on both platforms without modification. At the time of writing, the early releases of RAP are impressive proofs of concept but absolutely too premature for production usage. The exact level of maturity is also part of the research question.
In the M2 release of the RAP preview, many of the classes are similar to RCP classes, but the package names were different. I considered several different solution strategies to work around the package naming problem. After some analysis, I chose Jython as the most promising option to start with. Using the factory helper code I mentioned earlier, I succeeded in getting a single Jython code base running on both RCP and RAP despite the difference in package names between the platforms. RAP turned out to be surprisingly stable, fast and responsive for as far as it is currently implemented, but there are too many key features missing to create something meaningful right now. Within these limitations it is so convincing that I'm certain the development will lead to a competitive innovative solution framework before the end of 2007 (current planning of 1.0 final indicates the end of September, this is quite an accomplishment for a project of this size that started mid-2006).
In the same week I created the initial demo, the M3 milestone of RAP was released. Apparently many developers requested to change the package names in RAP to be the same as their RCP equivalents. A wise decision, I think, even though it seemed to render my Jython strategy useless.
It didn't take long to realize there is still a lot of added value in using Jython together with RCP and RAP. The advantages mentioned earlier with the main focus on agility. But also it turns out that there will always be a few minor differences between RCP and RAP because of the simple fact that browser interfaces and client interfaces are not the same.
In the current demo code you may recognize some hints separating current differences between the platforms. I thought about releasing a version of the code that runs on the RAP platform. For now, I think the RAP platform is evolving too fast to keep up with it maintaining the examples.
The RAP version of the demo app will follow as soon as the platform reaches an acceptable level of maturity. I'll watch the progress and report anything worth mentioning.
Before I end this section, I should mention that my earlier posts on AJAX on this weblog do not agree with the JavaScript-dependent approach of the RAP platform. I would recommend against using RAP on public open websites, if not for accessibility reasons, then performance issues will stop you. However, for internal usage in companies, there are many valid reasons to consider RAP. Especially if you are using a client side RCP application installed on your company machines and you want to make it available to employees working outside the building at clients with strict system administration policies or internet cafes with limited freedom, RAP will offer a very smooth migration path from client side to server side.
Comparing with alternative AJAX frameworks and successors
When compared to other similar AJAX frameworks, RAP sets itself apart with the proven powerful and flexible programming model taken from RCP. Almost any web/ajax framework forces developers to think in terms of request/response interactions, JavaScript and HTML document element definitions. RAP takes a different approach, it completely hides all underlying web browser details and allows the developer to think in terms of model specifications, event listener registration, UI widgets as rich as client side equivalents, and reusing existing RCP implementations.
In no more than a few days, I created a very simplistic proof of concept for a potentially powerful combination of technologies. With my initial focus on the Rich AJAX Platform, I connected the Jython language to Eclipse's more classic Rich Client Platform and found out that even without RAP, the combination can be quite powerful.
These days, software development seems to be dominated by web based solutions. Without denying the advantages of web based solutions, sometimes I miss the richness of client side software development.
I have a lot of experience with Swing and I learned to appreciate its complex MVC modeling requirements. For professional purposes I haven't used Swing since the end of 2004. Since then, RCP, SWT and JFace were on my list of things to experiment with. But all I did was web applications, introducing MVC on the web, working around limitations in web browser interfaces and fix typical web app issues. If you read earlier posts on my weblog, you might notice my focus on web technology and I must admit I even started to like it.
Although I'm convinced of the future of rich web apps, there is always this little voice inside my head that says that web technology is meant for document presentation and rich user interfaces are better off with client side GUI technology. You can abuse document presentation elements to fake a rich user interface and you can combine a large set of GUI widgets to look like a document, but you'll always keep running into practical issues because the technology wasn't meant for that purpose. Even the best solution is basically no more than a very clever workaround. To be quite honest, the Rich AJAX Platform is no exception. But the fundamentally different class modeling paradigm and the high level of abstraction are impressive enough to make up for this. On the long run, I wouldn't be surprised if the RCP framework is also ported to a platform that does not yet exist today, fixing all flaws imposed by current browser technology.
Even Microsoft acknowledged this and invented XAML as an XML-based language natively designed to accurately describe rich user interfaces. If you consider that XAML is a key part of the Silverlight platform, you should see a great potential for this technology to replace a substantial number of AJAX interfaces. When used for internal company applications in particular, XAML has a value proposition quite similar to RAP's we described earlier.
Conclusion
This article anticipates on the end of the AJAX hype for creating rich GUI web applications available internally on company intranets. New technology will provide more accurate programming models for describing rich user interfaces while remaining web based like classic web applications. With many web developers locked in to classic web programming models, it might be a big step to migrate to new programming models. Developers are encouraged to get familiar with client side GUI development again, so it is easier to pick up the new web based GUI programming models when they become available. The article covers a combination of Jython and the Rich Client Platform platform as demonstrated in my mini-project on Google Code. After discussing advantages and disadvantages, it explains how RCP relates to the upcoming Rich AJAX Platform. Microsoft's Silverlight is mentioned as an alternative.
I hope this article makes you curious to find out more about Jython, RCP and RAP. It took me time, effort and perseverance to get it up and running. But you can save some time if you use my demo as a starting point.
Any feedback, suggestions and comments are more than welcome!
Tags: RAP | RCP | Jython | Python | Java | Eclipse | AJAX | SWT