RAD7 appears to be a great improvement over RAD6 in terms of feature and stability. The latter is of special importance. RAD6 was plagued with many problems and lacked the stability and performance of WSAD 5.1.2. RAD7 seems to have reclaimed the glory days of the platform.

Here, we will discuss the improvements in RAD7 that the developers will have reason to be excited about. The observations were made after a brief review. There may be more improvements available from the product that we don’t list here.


RAD7 requires 10 CDs. If you are downloading the evaluation version, all 10 parts are required. Rational Agent Controller (RAC), required for code profiling, is another CD. Total size of all files is about 5.5GB. This appears to be an overwhelming amount of software. However, the actual installation seemed to go quicker than RAD6. We did not bench mark this, so, we can not be absolutely sure.

For RAD7, product files are installed in two separate locations:

  1. C:Program FilesIBMSDP70Shared – Contains files shared by various other Rational products, such as Rational Function Tester.
  2. C:Program FilesIBMSDP70 – Contains the RAD7 files.

The total size of all files in these two folders is about 1.5GB space. It is a fairly lightweight installation by today’s standard.

Important: By default Struts tooling is not installed. You must select Struts support in the Summary page of the installation program to get Struts tooling in RAD7.


In my machine, on average, RAD7 took 6.3 seconds to startup. Eclipse 3.2.1 with WTP took about the same time (6.3 seconds). In both cases an empty workspace with no projects was used.

We can safely say that this is the first version of a WebSphere IDE that started as fast as the base Eclipse tool. It is more difficult to explain why. Both are using J2SE 5. Although, RAD7 is using IBM’s JDK and Eclipse is using Sun’s.


When you started the test server in RAD6, for the first time after starting the tool, you probably got a publication error message. This problem is gone in RAD7.

When the server begins to boot, the startup messages are shown immediately in the Console view. In RAD6, there was a significant delay.

No exceptions or error messages were seen when the server started up. In RAD6, often mysterious exceptions were visible in the server startup log.

When you delete an Enterprise Application project that is deployed to the server, RAD7 automatically undeploys it before deleting the project files. RAD6 did not do so which caused the WebSphere configuration to become invalid.

Now, changes made to the application files are published every 5 seconds. In RAD6, this was done every 1 seconds. In RAD7, when you change a JSP file for example, wait for a few seconds before testing it. You can always change the publishing interval from the server’s property page.


When a Servlet is created, system opens the Java class file immediately. RAD6 did not do that and you had to manually locate and open the class file.

The parameters to the doGet or doPost methods are now request and response. In RAD6, they used to be arg0 and arg1.

You can start using all the Java SE 5 language features such as generics out of the box. RAD7 compiler, project settings and WebSphere v6.1 runtime are all configured to use Java SE 5.

To use the JSTL tags, you still need to explicitly add JSTL support to the web project. This makes little sense since JSTL is a part of core J2EE 1.4.


In RAD6, web service creation wizards failed to create a bottom up web service. This problem was later fixed through a fixpack. RAD7 has no such problem. I could create a bottom up web service from a Java class without any trouble.

When a web service implementation is created, only one extra Java file artifact is created. This is for the Service Endpoint Interface (SEI). In RAD6, a number of Java files (serializer, deserializer etc.) were created that cluttered up the project.

For bottom up web service, for methods that return void, you can design them as one-way or two way operations. For one-way operation, no SOAP response document is sent (reply body is 0 bytes). For a two-way operation a SOAP document is returned with a response element within the <Body> tag. I think, one-way operation for a void return type is WS-I compliant. In any case, RAD7 gives you a choice.


By far the most important improvement in RAD7 is perhaps the changes made to the JSF tooling. RAD7 is now a useful tool for rapid JSF development.

When creating a web project, you must choose Basic Faces Support and JSTL to enable JSF tooling. When a JSP file is created in such a project, it automatically contains the <f:view> tag. In RAD6, one had to explicitly create a Faces JSP.

Note: Many of the JSF tooling improvements mentioned here can also be found in RAD 6.0.1 (but not in the base RAD 6.0).

Now, you can disable automatic creation of managed bean for every JSF JSP page. In Preferences dialog, choose Web Tools->Faces. Check Suppress Page Code file generation. RAD6 created a managed bean for every JSF JSP page. This was completely unnecessary and cluttered up a large project. RAD 6.0.1 added the option to disable managed bean creation.

Now, JSF tooling parses the faces-config.xml file and finds all the managed beans defined there. You can directly start using these beans from a page. You can use any number of managed beans from a JSP page.

There is still no wizard that will create the JavaBean for a managed bean and automatically register it in faces-config.xml. You need to create the JavaBean manually. Then either register it by hand or create the managed bean definition using JSF tooling. To do the latter, open a JSP page, in the Page Data view, right click on Faces Managed Bean and choose New->Faces Managed Bean. In RAD 6.0.1, this was most confusingly labeled as New->JavaBean.

Fig 1. All managed beans defined in faces-config.xml are automatically shown in the Page Data view.

Once a managed bean definition is created in faces-config.xml, you can open any JSP file and associate a bean’s property with a component. You can also drag a managed bean’s property and drop it on a component in the page editor.


Fig 2. To associate a managed bean’s property with a component, simply drag and drop the property on the component.

System uses the JSF default component for the submit button. RAD6 used a IBM proprietary component. Also, system does not use any script collector component. Essentially, a JSF application created using RAD7 can run on Tomcat or any other platform.

There is no way to set the action handler for a command button from its properties page. But, you can drag and drop a managed bean’s method on the button to set it.

The tool palette for the JSP editor is mysteriously lacking a button for the <h:commandLink> component. Command links need to be manually created. The Link button in the palette is for <h:outputLink>.

Overall, JSF development has become much easier and more standard compliant.


RAD7 appears to be more stable and higher performing than RAD6. JSF tooling is significantly improved. Many annoying defects with RAD6 have been resolved. Even if you are not migrating to WebSphere v6.1 from 6.0, it may be worthwhile to consider migrating to RAD7 from RAD6.