Why Is the JDT Important to iSeries Developers?

Well, there's the obvious issue that Java may well become an important part of your company's future development plans. If that's indeed the case, then you (or someone in your company) will be using the JDT more and more. But even if you don't plan to use the JDT for Java development, the JDT is the model upon which the other editors are built. They don't exactly follow every nuance of the JDT, but there are enough similarities that when a conceptual feature is added to the JDT, you can reasonably expect that the same feature will make its way into the iSeries editors as well.

Tell Me Again: Why Do I Care About Java?

This question still comes up, though it's less often these days and primarily among the smaller SMBs who are trying to figure out where to spend their precious development budgets. Some companies may not care about Java at all. If your company has no need for Internet access, no need to communicate with business partners, and no need for alternate input devices like handhelds and cell phones, then you may never use Java, and you can just go on to the next section.

But if you need alternate access methods like those mentioned above, then you'll probably use the Web, and for that you'll need a Web application architecture. When it comes to such an architecture, there are only two choices for most iSeries shops: JSP Model II and RPG CGI. I've spent a lot of time recently discussing the relative merits of these two architectures. I'm highly biased toward JSP, and I sell a JSP-based product. Of course, I think you'd expect that. An ISV needs to choose one of two basic paths: Select the best of breed in architecture and build your tools on that or else try to be all things to all people and provide tools that work with every architecture. I spent nearly a decade working for a company that then went bankrupt trying to move from the first approach to the second, so I tend to stick with the first. And if I have to choose one, then I think JSP Model II is the most powerful architecture available for creating Web applications. The biggest negative is that JSP requires a small amount of Java knowledge, but if you can leap that particular hurdle, the advantages far outweigh the difficulties.

Java? Not in My Lifetime, Joe.

You may be a die-hard RPG fan. I'm a Cubs fan, so I can relate. And I love RPG, so I can understand if you don't feel you have the time or need to add yet another language to your repertoire. If you have no intention of ever, ever moving to Java, then of course the JDT holds a lot less interest for you. But even so, you should at least take a look at the JDT, especially at the new features available in Version 3.0 of Eclipse. Some of the major additions (tear-away windows? folding editors?) may be applicable to non-Java editing as well. In fact, you may want to look at the new version and drop the Toronto folks a note to make sure that your favorite features make their way into the iSeries editors.

That's not to say that the iSeries editors are exact clones of the JDT editor. In fact, the iSeries editors have significant features beyond (or at least different from) those of the vanilla JDT editor. For example, in addition to standard drag-and-drop editing that most Java programmers are used to, the iSeries editors also support standard SEU line-oriented commands like M (for move) and MM (for block move). They also support prompting, which is really only useful on fixed-position syntaxes or on CL. The point is that there are differences as well as similarities, so the JDT isn't always a perfect predictor of things to come in the iSeries editors, but it's a good place to look. For example, if the JDT editor ever allows multiple edit views of the same source file, you can bet that that feature will be in the next release of WDSc.

On to the Editor

Let's look at some of the features currently available in the JDT in WDSc Version 5.1.2.4 and see how they relate to similar features in the iSeries editors, and then we'll sneak a peek at what's coming in Version 6 of WDSc. We'll do this by looking at Eclipse 3.0. Author's Note: There is a new update available for version 5.1.2.4; I downloaded it while I was writing this article.

Today's WDSc

The Java tooling in today's WDSc is already rich with features inherited from Eclipse. Eclipse was built by the same folks who built VisualAge for Java (VAJ), which was arguably the best pure-Java IDE ever designed. I liked the fact that it was not just a warmed-over C or C++ IDE; VAJ was specifically designed around the Java language, and it showed. In everything from the method-focused editors to the ability to set breakpoints on Java exceptions, VAJ was a true Java IDE. When I saw that it was going to be replaced by Eclipse, you can bet that I was very skeptical. Remember, I'd been through the WebSphere 3.5-to-4.0 rewrite, and I wasn't particularly impressed.

But I was pleasantly surprised by Eclipse. Although the early versions (prior to 2.0) weren't exactly something to write home about, they were built on what looked to be a very solid framework, and many of the features were so familiar that even those of us who were VAJ bigots were comfortable. One in particular was the "running man" icon for launching a program, which has since been replaced by the "universal" but oh-so-boring VCR Play button symbol. These little touches allowed those of us with VAJ experience to jump into Eclipse fairly quickly and to ignore the little quirks that made life annoying. And there were annoyances, to be sure: The package wasn't yet particularly stable and often dumped to the desktop, it was slow to run and even slower to load, and there were some annoying bugs, many due to the radical plan of dumping Java's Swing UI for the Standard Widget Toolkit (SWT), a home-grown, platform-dependent substitute.

But then Version 2.0 came out, with 2.1 following not long after, and suddenly we had a full-fledged development tool on our hands. Whatever beginner's jitters had been in place during the early releases was gone. The SWT was firmly in place, and the interface looked great on multiple platforms. Third parties were building plug-ins at an unhoped-for rate, and the package was blossoming.

Features of WDSc 5.1.2.4 (Eclipse 2.1)

Let's look at some of the goodies in WDSc 5.1.2.4 that it inherited from Eclipse 2.1. First is the concept of the Java project and the fact that it supports many different project options. You can include outside JAR files and classes in your projects, you can even include other projects in your project. This is an especially cool trait. This allows me to easily share common code among multiple projects and be able to debug the common code rather than just including it as a JAR file. You can also easily create projects following standard conventions, such as creating separate /src and /bin folders.

WDSc carries the concept even further. The WebSphere Studio components (now called Rational) add a lot of project-specific intelligence that makes it very easy for you to create J2EE-compliant projects without any extra work. The standard WEB-INF folder is created with the appropriate class folders under the /bin folder, and the source is kept separate. Author's Note: It's important to remember that Eclipse itself has no knowledge of J2EE; it is just a Java IDE. To get J2EE support, you have to either get an open-source plug-in like Lomboz or a commercial tool like WDSc.

The JDT's Java editor supports a number of great features. Syntax highlighting, in which Java keywords are displayed in different colors and fonts, is so common these days as to be required for Java editors, and the JDT is no exception. We also see this carried forward into the iSeries editors. As much as possible, the editors try to highlight things like opcodes and built-in functions (BIFs). This is particularly useful in free-form RPG.

The outline view is a great boon to large classes. It displays a small, succinct version of the class, listing only the instance variables and methods, allowing you to quickly navigate through the source. The outline view is also available for iSeries editors, and it's often quite useful. Note that the outline view must be refreshed in order to use other capabilities of the editor, including code assist.

Code assist is quite powerful. Because of its Java knowledge, the JDT can easily provide you with suggestions as to what to type next. For example, you can begin typing the name of a variable, and code assist can guess which variable you mean to use or display a lit of options for you to choose from. This same feature is available when you want to select a method for an object. And code assist helps with iSeries languages as well. In RPG, for example, code assist helps you find variable names and select BIFs.

Another great capability of the JDT is the debugger. Few debuggers have this level of sophistication. The debugger is thread-savvy, allowing you to set breakpoints for specific threads (this can be crucial in servlet development), as well as very Java-specific, with the ability to set breakpoints on specific exceptions. This is significant; sometimes you encounter an exception, such as a null pointer that gets bubbled up through the stack, and you're not sure where it was generated. With the Java debugger, you can set a breakpoint to stop you wherever in the code a null pointer is encountered, thereby saving hours of debugging. And while there is no direct analog to the exception in RPG, breakpoints can be set, and variables can be inspected and changed.

Another nicety is the template, which is used to create common bits of code. There are actually two sets of templates: One set relates to commenting code and creating a common look and feel for things like methods and types, while the other is specifically for creating new code. You can set up your preferences for how to create a for loop; in fact, you can have several preferences, and by using code assist, when you type "for", you can then select from the various options you have set up. And as you may have guessed, a version of the templates concept is available for other languages, although for some reason it's only for free-format languages like COBOL and free-format RPG. There are also a few wizards for doing things like creating procedure definitions and Java method calls in RPG.

Refactoring is crucial to Java development, and the JDT does it better than any other tool. The selection of refactoring actions is quite extensive, from simple renames to push-up, pull-down, extraction, and inlining. I'd go into this in detail, but if you're not going to use Java, then don't worry too much about it, especially since most of these currently are not available for other iSeries editors. I think, though, that a topic for another column might be "why are these available in Java and not in RPG?" For example, the ability to rename a field in RPG and have that change reflected throughout the program would be an awfully nice feature.

Future Vision

Now that I've given you an idea of why the JDT is such a great Java editor and how its features tend to translate over into the iSeries editors, it's time to take a glance at the new features coming soon to an editor near you. I don't have room to do them all justice; another column will be needed to go through them in detail. But I can at least give you a quick overview.

The number of changes in Version 3.0 is extensive and fundamental. Even the most basic things have changed, such as how the tabs work in windows. And this isn't a simple look and feel issue; many usability features have been added to the new UI. If you don't like tabs, you can have only a single tab in your editor view; this allows you to do all your navigation using the keyboard.

One of the primary changes is that of tear-away (or detachable) views. You can drag a view away from the primary workbench and have it stand on its own. With a dual monitor setup, you can even drag the window to another monitor. With this capability, I can have debugging information on one monitor and the actual application running on another monitor. This is the most productive debugging environment, and this capability may be the one that pushes me to dual monitors. If you're interested in this, drop a line in the forum or in email, and I'll be sure to update you if I move forward with the idea.

There are shutdown and startup enhancements. For example, you can set a preference that tells the workbench to close all open editors on shutdown. This means they won't need to be opened when the workbench is started again (often a real problem when starting WDSc!). Not only that, but you can identify editors that should not be automatically closed by "pinning" them open.
There are usability enhancements as well. Long-running jobs are now relegated to a background thread. Instead of locking up the workbench, you instead can keep working, with a little status window to tell you how the task is proceeding. (These little status windows are another good reason for dual monitors.)

All of the improvements above will be available for WDSc and the iSeries editors; they're not specific to Java, so you should see them immediately. Now, I'll list a couple of new features that may or may not be available for iSeries developers.

First is the concept of the "Quick Diff." This is a really cool idea: As you're modifying a source file, the editor keeps track of the differences between it and a "base version." Any differences are continually highlighted in the text, and if you hover your cursor over the change, you can see the original text. While I don't think it's a feature I would need all the time, I think it would be very useful when I did need it.

The other option that I think might be a great boon for today's software developer is the source "fold" option. As implemented in Eclipse 3.0, the fold feature is primarily used for folding either comments or methods in Java classes. The editor recognizes a comment block or a procedure and presents a small arrow in the left margin that allows you to "fold" (collapse) that block of code. Once collapsed, the indicator changes appearance and can then be clicked again to unfold the source. It's rather hard-coded; you can't identify your own blocks of code, for instance, and it doesn't recognize a set of contiguous single-line comments as a block. But the idea is great, because it allows a programmer to add lots of comments and then fold them out of the way, which removes one of the primary objections to comments (they "get in the way" of reading or working with the code). As syntaxes get more complex (even for RPG!), I think comments are more and more critical, and anything to make it easier to get programmers to comment is a good thing.

So Why Should You Be Happy?

A couple of things revealed in this article should put a smile on your face; which is most important to you depends on your relationship with WDSc.

If you use WDSc as a Java development tool, then it's clear that the new additions to the JDT will help you and make your life a lot easier. Not only that, but it's just as clear that IBM and the Eclipse development team are hardly sitting on their laurels; they're actively adding lots of great features to the product. This is a good sign for the long-term health and strength of the package.

But even if you're only going to use WDSc as an SEU replacement, you can still see that the editors are a primary focus of all three development teams: the Eclipse team, the WebSphere Studio (a.k.a. Rational) tools developers, and the WDSc team. Each of these groups will continue to add functionality that will make it into the iSeries editors and thus will make your life easier.

I can't wait to get my hands on the new version of WDSc!

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. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSc: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..