System iNetwork

December 2006

December 18, 2006 8:32 PM

Hands on -- Getting started with Eclipse RCP.

Now it is time to try Eclipse RCP by working through a tutorial to create and package an example Eclipse RCP application.

The pre-requisites are that you have some Java experience and are somewhat familiar with either Eclipse IDE or WDSc. The example applications in this tutorial will later be modified to use System i resources.

We will use Ed Burnette's "Rich Client Tutorial" as a common ground to discuss development of Eclipse RCP applications for the System i. The tutorial starts here:

http://www.eclipse.org/articles/Article-RCP-1/tutorial1.html

In later blog entries I will work through modifications connecting the rich client developed in the tutorial, or a variation of it, to a System i. Mr. Burnette's work is not being "jacked". I am simply not re-inventing the wheel here (re-use and all that ) and I could not do as well as Ed if I did write a tutorial for this blog.

If you want to try Eclipse RCP work, through this tutorial, at least parts 1 and 2. If you have problems, please check the newsgroups and other resources at eclipse.org and eclipsezone.org. We can also help each other on this blog. As time permits I'll answer the questions I can and hope other readers pitch in.

The "Getting Started" section of the tutorial assumes you are familiar with Eclipse. If you are familiar with WDSc but do not have Eclipse, this is what you need to do.

1. You will need Java 1.4.2 or 1.5.0. If you use WDSc 6.01 only the most recent upgraded IBM JVM meets this requirement. If yours does then use that, otherwise get the Java SDK from Sun.

If an older version of Java is installed on your desktop (or no version of Java at all!) but you want to try this, you are not out in the cold! WDSc is installed with its own private JVM. You can set up Eclipse this way as well. If you need help e-mail me b_blalock@comcast.net and I’ll send my notes on this.

2. Download the Eclipse SDK from http://www.eclipse.org/downloads. The SDK is what you need, not the Eclipse Distro. The current release is 3.2.1. WDSc is not appropriate for Eclipse RCP because the latest release is based on Eclipse 3.0.

3. Decide how you want to install Eclipse on your desktop. If the package is unzipped to C:\ then Eclipse will be installed in C:\eclipse\*. Consider unzipping it to something like C:\eclipse_ide, you end up with C:\eclipse_ide\eclipse\. Afterwards rename the folder to C:\eclipse_ide\eclipse_321\.

4. Run eclipse.exe. It will ask you where to create the workspace and suggest a folder in the home directory, C:\Documents and Setting\yada\workspace. Consider changing that to something like C:\eclipse_workspaces\learnRCP. Any path will work, I like to be able to easily find the workspace easily.

You will be happy to know that Eclipse won't "install" itself into Windows or your desktop. You will control where it goes. Uninstall Eclipse by deleting the installation folder -- that is it. No changes were made to the registry, nothing added or changed in the desktop OS. If you have ever done a manual uninstall of WDSc you will really appreciate this.

Now you are ready to work through the tutorial.

Future blog entries will create client / System i rich applications based on, or as variations of, this tutorial. The example "projects" will be available on a CVS (concurrent versioning system), you can "checkout" the projects.

Version control and software project management provided by CVSDude. See http://www.cvsdude.org

Posted by Bill Blalock on December 18, 2006 at 8:32 PM | Comments (0)

December 14, 2006 6:07 AM

Do not be deafened by the fanfare..

In all the fanfare Eclipse RCP has received there are a few things to bear in mind that aren't obvious until you have worked with Eclipse RCP up close and personally.

First, doing things Eclipse’s way is in the best interest of the developer. Figure out how to frame the application design in terms which are compatible with Eclipse. If the design works with the patterns of Eclipse then Eclipse provides a lot of help, development moves right along. If the design works against those patterns then Eclipse can get in the way. The moral is “every rich client application is not a candidate for Eclipse RCP.�

In terms of program maintenance and enhancement the patterns and structures imposed by Eclipse RCP works to the developer’s advantage. An Eclipse RCP application is governed by structures following life-cycle. Plug-ins are loaded under known situations in a specified order. There is lots of structure. Certain Eclipse classes have to be implemented. A developer coming in to maintain or extend an application developed with Eclipse RCP has a roadmap of how it was put together. Consider a purely Java application, all you can say for sure going into it is that the class executed by java.exe must have a main() method.

Second, Eclipse RCP still shows its heritage as an IDE tool. The good news is that it gets better each release. Some examples:

- the “current directory� starts out as .metadata, you have a .metadata folder whether you want one or not
- the fonts of the menu and pull downs are fixed
- the Eclipse RCP is going to revert to logging events in .metadata/.log, those names are hard coded.

Some would argue that a third “downside� to keep in mind is Eclipse RCP UI is based on the Eclipse SWT and not JFC (Swing). SWT, Standard Widgit Toolkit, is the UI presentation layer IBM developed for Eclipse then donated. There has been much controversy and Swing vs SWT discussions. I won’t get into that UI toolkit battle here except to say I am on the Eclipse SWT side.

The concern is the developer has to learn a second UI toolkit. In the last two years Eclipse has made it easier to bridge this divide. The class SWT_AWT has been available since Eclipse 3.0. SWT_AWT supports embedding Swing/AWT widgets inside SWT widgets.

Eclipse RCP gives you tools to produce high quality rich client applications but it does place constraints on the developer. I think that those constraints are more than compensated by what Eclipse RCP provides.

What do you think?

Posted by Bill Blalock on December 14, 2006 at 6:07 AM | Comments (0)

December 10, 2006 11:25 AM

Options for creating Rich Client applications

The term "rich client" does not imply a particular technology. "Rich client" only implies a modern desktop application development technology which can produce a client with a "rich" graphical user interface. Consider the choice before you when exploring "rich client options."

Java is not the only language for developing "Rich clients." Microsoft dot Net, C++ and Delphi are other options. But Java is a very appealing choice when you consider:

• complexity


• tools (IDEs and other development support software)


• open source and commercial resources (libraries)


• industry acceptance


• integration with the System i

"Rich clients" can be developed with just Java and Swing (Java user interface foundation class) or SWT (Eclipse standard widget toolkit). The problem is that the developer is responsible for everything! That is a lot of work to do it right. Hey, maybe that is why browser based applications so quickly overtook "fat" client -- server applications?

IBM is developing the "IBM Workplace Managed Client" under the Websphere umbrella to provide "rich" client – server applications. Interestingly enough, it is also based upon the Eclipse toolkit. See

http://www-128.ibm.com/developerworks/lotus/library/wmc-toolkit/

Then there is the topic of this blog, Eclipse RCP … Rich Client Platform. Look at either Eclipse or WDSc. Did you ever think "that would be a cool framework for my application X if it didn’t have all the IDE stuff?" Many of the early Eclipse adopted thought just that. By the time Eclipse 2.1 was released developers of the future Eclipse Foundation were reengineering Eclipse to separate the user interface and IDE parts. I believe this was in the 2nd half of 2004. In Eclipse 3.1 the separation was (mostly) made.

Eclipse RCP is the set of plug-ins which are necessary for the workbench and user interface. The developer creates plug-ins for application logic which make use of the RCP plug-ins for the user interface. The functionality of menus, status lines, editors, views and much more are provided. The developer focuses on the application specific code.

Anyway, enough said. For more information see:

http://www.eclipse.org/home/categories/rcp.php

Posted by Bill Blalock on December 10, 2006 at 11:25 AM | Comments (1)

December 4, 2006 4:53 PM

Welcome to the Exploring Eclipse RCP Blog

I started on the AS/400 in 1988 and have worked continuously on the platform. The bulk of my experience is with RPG and System i integration. I started working with Java on the System i in 2001. I missed Visual Java and used CODE as my IDE. I started using Eclipse 2.0 for Java development in early 2003.

I am not claiming to be an expert on Java, Eclipse, or Eclipse RCP. Each time I have a new application, I find myself on the Sun and Eclipse forums along with my visits to System iNetwork. Frankly, at age 54, I find learning and applying Java quite a challenge. But I have spent time in the trenches and deployed Java applications.

My BS is in accounting, University of Kentucky, 1976. My MBA is from the University of Dayton, 1985 (not that either make much difference after all this time). I currently work for a System i company in the financial services sector. This blog represents my views and not necessarily those of my employer.

As I humm the tune "Everything old is new again," I'd like to begin with a question:

Do "Rich Clients," aka "Fat Clients," have a place in the tools available to the System i shop to extend selected functionality to the desktop?

Obviously I think so or I wouldn't be putting time into this blog. Or has the browser triumphed? Are "Fat Clients" that access functionality of the System i relics of the past? Am I wasting my time and yours as you read this blog?

Please notice that the initial question is "extend selected functionality of the System i to the desktop?" It took a while to compose that sentence.

"Selected functionality" is not "provide a GUI interface to a 5250 display." Certainly there are better tools than a desktop client to GUI-ize a 5250 display, and most of them are browser based.

Consider two tool sets that provide us the means to create System i programs: PDM and WDSc. PDM is 5250 based. The processing, member updating, syntax checking, compiling etc. takes place on the iSeries. If a GUI presentation of the PDM 5250 displays were required then a browser-based solution would be just the ticket. The browser on the desktop handles the user interface, replacing the 5250 display. The rest remains as it is.

WDSc is a completely different approach to a similar task. In addition to moving the user interface from 5250 displays WDSc moves much of the function from the System i to the desktop. WDSc is a "fat client." A client which "extends selected functionality" of the System i to the desktop."

Most GUI interfacing tasks for System i applications are done well, perhaps even best done, with some type of browser based technology.

But I argue that a "Rich Client" should be considered when an application is to be developed which can make good use of desktop capabilities for the benefit of the user or business. The "desktop capabilities" I refer to are
- functionality of the OS and desktop
- the processing power and memory of the desktop platform
A browser-based approach does not make use of the power of the desktop platform and provides only some of the functionality of the OS and desktop, but not all or even most. Again, consider WDSc. Imagine what it would look like, and perform like, if it were browser based?

Browser based applications certainly have many advantages of a desktop client. These advantages are overwhelming when the application is to give 5250 displays a GUI interface or simply to provide a GUI front end to a System i application. Still "Rich Client" applications have these advantages over browser-based applications:
- "Richer" functionality, browser-based applications are limited by HTML standards and components.
- More components to choose from (tables, calendars, dialogs, built-in editors and even operating specific capabilities such as Active-X controls)
- Better usability: menus, hover help, icons, multiple buttons and control styles
- Can have multiple GUI tasks are going on at the same time, or be multi-threaded from the end-user perspective
- Browser-based applications generally require server applications and some infrastructure on the System i which may not be a cost effective solution if only a limited set of System i functionality needs a GUI presentation.

These advantages give "Rich Clients" a place in the System i tools.

In this blog, I want to explore with you using Eclipse RCP for making "Rich Clients." I want to have a place where that small group of us who both develop Java client and System i applications can meet and share our experiences with the Eclipse tools. I invite your active participation!

Posted by Bill Blalock on December 4, 2006 at 4:53 PM | Comments (5)