1. What is Eclipse?
2. What is Eclipse good for?
3. What happened to VisualAge for Java?
4. What's the relationship between Eclipse and WebSphere?

What Is Eclipse?

There are two aspects of the Eclipse IDE: technical and, shall we say, political. The technical aspect has to do with the architecture and capabilities of Eclipse as a tool, while the political aspect is more about IBM and its relationships with its own users, its competitors, and the open-source community.

Technically Speaking

In the words of the Eclipse developers themselves, Eclipse is an IDE for anything and for nothing in particular. That is, the Eclipse IDE by itself actually has no support for any language. Instead, it's a framework designed to allow the addition of tools for any language. Think of WRKxxxPDM, but without any of the options enabled. Everything comes up in SEU text mode (or perhaps, more appropriately, in EDTF) because the tool has no innate knowledge of any source types. Nothing can be compiled, saved, moved, or anything, because everything is treated completely generically. This is what the base Eclipse IDE is like. Figure 1 shows the Eclipse workbench as it looks without any plug-ins at all. Basically, it allows you to create projects, inside of which are folders, inside of which are generic files. The only thing the workbench can do is open the default system editor for whichever file types you choose to include in your project. You can also assign tasks, and that's pretty much it.

Figure 1: This is the basic Eclipse workbench, as described in the Eclipse manual.

So what's the point of having what is in essence a big, fat replacement for Windows Explorer? The idea is that developers will add their own options, sort of like the user-defined options in the WRKxxxPDM commands. In Eclipse terminology, these options are called "plug-ins," and there are already quite a few. In fact, I'll review one in particular, the Java Development Tooling (JDT), which comes as part of the base Eclipse package. Actually, it comes as part of the Eclipse SDK, or Software Development Kit, which is the piece that tool designers use to create new plug-ins for Eclipse. The JDT is sort of the reference implementation for Eclipse plug-ins. I'll discuss the JDT in more detail a little later in the column.

Politically Incorrect

There's another side to Eclipse--dare I say it?--a dark side. This dark side is rarely mentioned by the IBM troops but is consistently held up by foes (particularly the fine folks at Sun, as in one issue of their lighthearted, silly, occasionally on-point Webzine, bigbluesmoke.com). The fact is that Eclipse has some disturbingly non-open implications. The very tool itself is built on IBM's proprietary widget technology, known as SWT, the Standard Widget Toolkit. Because of this, Eclipse, though ostensibly an open technology, will run only on those platforms for which IBM has written a version of the SWT. Today, that's only Windows and Linux, so you can understand that the Sun folks are a bit miffed (not to mention the poor Apple folks, who get ignored by nearly everyone while consistently putting out wonderful software and hardware products).

IBM insists that SWT and its companion technology, JFace, are simply addressing a long-standing problem with Java's Swing technology. Swing has long been considered slow and sometimes not pretty. Because the entire UI is emulated, Swing applications simply don't "feel" like native applications, especially in Windows environments. While space prevents me from going into much detail on the Great Java UI Debate, SWT looks more like a native application, but only because IBM wrote a proprietary layer between the Java application and the operating system. You'll need one of these for each operating system you want to support, and only IBM knows what's in that package, so only IBM can decide which platforms will be supported.

Therefore, since Eclipse requires SWT, it is, at least in part, a completely proprietary IBM tool and will only be able to move to other platforms at IBM's sole discretion. Is this a bad thing? Well, it is if you're developing Eclipse plug-ins and you want to target platforms other than those IBM supports. It's also a bad thing if you want to use Eclipse on anything other than the IBM-supported platforms. Is reliance on IBM worth the added speed and ease-of-use of Eclipse? Well, speaking strictly for myself, I was willing to make that compromise a long time ago when I decided to adopt VisualAge for Java (VAJ) as my development platform, so I guess the point is moot for me. It's a business decision, but at least you now have the information you need to make that decision.

What Is Eclipse Good For?

Okay, time to get past the rhetoric and look at the product. Since I'm quoting lyrics lately, I'll use the opening lines of Edwin Starr's seminal 1970 protest song, "War":

"War. Huh! Yeah! What is it good for? Absolutely nothing."

That describes what Eclipse is good for without any plug-ins. Okay, not absolutely nothing, but pretty darned close. Unless you're doing something relatively trivial like putting together a list of quotes or an article outline, the base features of Eclipse aren't much use. Figure 2 shows a project in Eclipse without any plug-ins.

Figure 2: This Eclipse screen displays the default Resource Perspective with no plug-ins.

Note that Eclipse has no idea what the different file types mean, and if you try to open a Java class file, you get the binary byte codes opened in a text editor. But with the JDT installed, you instantly get a lot more functionality, as shown in Figure 3.

Figure 3: Here, you can see how the JDT plug-ins automatically invoke the editor for a Java class.

This is virtually the same project, but this one uses Eclipse with the JDT plug-ins installed. Now, when I select a Java source file, a Java-aware editor comes up. Not only that, but when I select a Java class file, the IDE is smart enough to know that I really want to look at the associated source. Keywords are highlighted, comments are colored, and even errors are indicated. Not only that, but in this perspective you can set breakpoints and then run the class! This is the beauty of the Eclipse framework: The plug-in programmer can add whatever features are necessary. And this is only one of many features made possible by the adaptive nature of Eclipse. Another is the concept of "perspectives." Eclipse allows you to define the various panels in the display to create a comprehensive view of your project. Each view is called a "perspective," and there can be as many perspectives as you want.

Figure 4: This panel shows the same project, using the Java Perspective.

For example, in the Java Perspective, the navigation pane on the left allows the source to be expanded to show the various elements of the Java source, including the class, the instance variables, and the methods. An additional Outline pane appears in the upper right that allows me to view the contents of the selected source member. The Tasks pane on the bottom automatically shows any errors in the current member.

What Happened to VAJ?

VAJ is dead; long live VAJ. Eclipse has actually proven itself, in my opinion, to be a viable successor to VAJ. And this is coming from me, a long-time, die-hard VAJ bigot. I absolutely love VAJ and still use it for the bulk of my Java development. No other tool has ever approached its true Java-centric nature. Most Java IDEs available today started life as C (or Pascal!) editors. Because of this, they tend to act more like C editors, with no real emphasis on the object-oriented nature of the Java language. A real Java IDE has to be able to do things like automatically generate stubs for inherited abstract methods and create getters and setters for instance variables. Changes to a method signature should automatically be reflected throughout the repository. These features are absolutely required for my particular development style, and VAJ handled every one. I'll admit that some of the menus were a little confusing; having to go into the Reorganize submenu in order to find the Move option took some getting used to. But for true industrial-strength Java development, VAJ was the most complete IDE I'd ever used.

So when Eclipse came along bearing the news of the demise of VAJ, I was definitely poised to shoot the messenger. IBM had switched gears on me yet again, and I was in a nasty mood. I couldn't understand how IBM could even consider tossing VAJ on the scrap heap. That is, until I saw Eclipse. I've been using Eclipse 2.0 with the JDT for a little while now, and though I don't yet use it in production, I'm very pleased with the way most of the critical features of VAJ made it into Eclipse, with the added benefit of some more intuitive keystrokes. I shouldn't have been so surprised. The folks behind Eclipse, Object Technology International, are the same folks who designed VAJ. And it shows. Some other day, I'd like to do a point-by-point comparison of the two tools. If you're interested, please send some feedback. Either use the discussion forum associated with this article or email me directly.

What's the Relationship Between Eclipse, WebSphere, and the iSeries?

This is a little bit complex, and I'll go into it in more detail in another column. However, you should know that WebSphere Site Developer Advanced (WSSDa) is based on Eclipse 2.0. The workstation tools that will be used for iSeries development are collectively called the WebSphere Development Studio Client (WDSc) and are based on WSSDa. Therefore, IBM's entire application development suite for the iSeries is moving toward Eclipse.

The WDSc tools (which are actually plug-ins for Eclipse) are intended to eventually completely replace the older set of programs that made up the WebSphere Development Tools (WDT), such as CODE/400 and VisualAge for RPG. Already they have replaced VAJ, WebSphere Studio, and WebFacing. There's also WebSphere Studio Application Developer (WSAD), which adds EJB support, but that's just a different set of plug-ins.

PDM, SEU, SDA, and all the compilers still live on in OS/400, but don't expect a lot of additional work in any of the green-screen development tools (other than the compilers). WDT was the first step toward moving these tools to the workstation, and Eclipse is the grand unification of these separate tools into one cohesive IDE. Good or bad, if you want to develop multi-language applications, chances are that you'll want to move to Eclipse (and WDSc) sometime soon.

Conclusions

IBM has put all their eggs into the Eclipse basket. After many years of hit-and-miss workstation tool development, they have locked in on a technology that looks like a very viable design. I'm impressed with how they've managed to coalesce many separate development efforts into the single Eclipse line; I have to imagine there were some rather interesting internal debates as that decision was made. But, having made the decision, IBM has definitely forged ahead, and what I see so far I like.

The concept of being able to stay in the IDE and seamlessly edit everything from RPG code to Cascaded Style Sheets holds a lot of promise. If IBM manages to integrate the debugging of these applications as tightly as they have the editing, we may be on the verge of a whole new level of productivity.

I'm waiting with much anticipation for the new WDSc code. As I write this, WDSc isn't even in public beta yet, and I won't be able to give you any detail on it for a little while, but from all indications, it's going to be a very important step toward true integration of all the various iSeries languages.

One More Thing...

I wanted to add a little extra addendum to this edition of Weaving WebSphere. While not particularly specific to WebSphere, I think it's germane to the entire concept of the iSeries as a server platform. The issue is one of support.

In recent years, I think it's fair to say that iSeries customers have gotten the idea that they may be the forgotten stepchildren of the IBM marketing and support behemoth. It was becoming more and more difficult to get any kind of support for iSeries questions, and the introduction of the cross-platform movement within IBM exemplified by the eServer consolidation and the WebSphere software platform only exacerbated the situation. More than once, I needed support or guidance on a WebSphere issue only to find myself talking to someone who had no idea what an iSeries (or AS/400, for that matter) was.

Well, that seems to be changing. Recently, I had the misfortune of attempting to pay my hardware maintenance with a credit card. Although I'd done this in the past, I was told, after a couple of rounds of phone tag, that credit card payments were no longer accepted. And here's the rub: rather than actually raise the issue with IBM, I had become so inured to this sort of thing that I simply accepted it. All I did was make a comment in one of the mailing lists I frequent, MIDRANGE-L.

Lo and behold, I got an email from someone at IBM! A gentleman by the name of Jim Rubish contacted me and assured me that he sympathized with my plight and would address the issue. He even entered a customer complaint for me into the IBM database. Not long after that, a wonderful lady named Ellie Mahoney contacted me, and after getting the particulars of my situation, she began researching it. From that point on, she kept me apprised on the progress of the issue nearly daily, until ultimately it was resolved. The issue was simply one of procedures not being completely communicated between divisions in the giant corporate structure that makes up IBM, and once the procedures were properly identified, I was walked through the process, and my problem was solved.

It's not so much that the issue was resolved as the fact that IBM so aggressively pursued it. I didn't have to badger people with calls and emails. Instead, IBM personnel took responsibility for the issue and definitely gave me the impression that they considered it their job to make sure I was satisfied as a customer. As I said to someone in an email, my general feeling is that, for the first time in a long time, there really is a sense of urgency at IBM to rekindle the customer relationship. This bodes well for the future.


Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. You can reach Joe at joepluta@plutabrothers.com.