Introduction

WebSphere® Studio Application Developer is a significant new software product for IBM ®. It is the strategic replacement for both VisualAge® for Java^TM and WebSphere Studio. VisualAge for Java was first built before concepts such as J2EE existed, and was conceived at a time when Java was focused on applets and the traditional client server. WebSphere Studio was created when the Internet was serving up HTML pages with CGI scripts. Since then, Java has adapted and grown into many areas that are part of Web application server-side development, for example, servlets, EJBs, JSPs^TM and J2EE. More and more, Web page authoring tools have to deal with not only the authoring of HTML tags, but with authoring of JSP content, which requires coding, coloring and validation of Java syntax inside scriptlets. Java beans, originally created to provide a client-side component model similar to Active-X, are now used inside JSPs through <jsp:usebean> tags to encapsulate server-side business logic.

As the uses of Java change, so must the development tools. With WebSphere Studio Application Developer, IBM has built an entirely new code base that is designed to be easily extended by IBM and other companies. At its foundation is the IBM open source tools platform called Eclipse.

For VisualAge for Java developers, I have written this article to compare and contrast the Java editing capability within WebSphere Studio Application Developer with that of VisualAge for Java, so that those using VisualAge for Java can have a better idea of what the new Application Developer tools now provide. This article also shows how to write a standalone HelloWorld class to illustrate how to control compilation, reporting of errors and other Java settings. A follow-on article will cover more topics, including debugging code, profiling code, running ad-hoc code snippets, as well as more WebSphere class types such as servlets, JSPs and EJBs.

Back to top

Overview

The most noticeable difference between VisualAge for Java and Application Developer is how code elements are stored, and how code is compiled and executed.

Class source

VisualAge for Java

Source code is stored in a proprietary repository known as Envy. This provides source configuration management (SCM) and keeps track of code changes down to method-level editions. Extraction of source for deployment or execution outside of VisualAge for Java is done by exporting to the file system, and inclusion of external source is done by importing into the repository which copies all of the source into the repository.

Application Developer

Source code is stored in .java source files in a file system. Having a separate tool such as CVS installed provides support for source configuration management. The granularity of the SCM is the file level, so method editions are not supported, although there is a local client change cache. Because the source is stored in the file system, there is no separate export process necessary to get the file out of the repository. Application Developer can also work with external folders or external JAR files simply by pointing to them without having to do an import.

The advantage of this approach with Application Developer is that it is more open than Envy, it lets the user use the SCM tool of their choice, and it is closer to a native Java environment that expects files to exist in the file system. The disadvantage is that it loses some of the built-in features that Envy provides, such as ownership of classes and tracking of changes.

Class bytecodes

VisualAge for Java

Bytecodes are created using an internal compiler and exist in the workspace inside the .icx file. VisualAge can only execute them using its customized virtual machine (VM). The set of classes against which the source is compiled is the set of loaded classes inside the workspace. The Java Development Kit (JDK) inside the workspace is provided by IBM with VisualAge for Java and cannot be changed by the user. The virtual machine that is used to run and debug code inside VisualAge for Java is called the Universal Virtual Machine (UVM) and is a proprietary virtual machine written by IBM.

Application Developer

Compilation is still done with an internal compiler, but the set of classes that the source is compiled against is defined in the build path for the project. The user has complete control over the build path, which can include other projects inside Application Developer or external JAR files on the file system. The JRE in the build path can be set by the user to any JRE level ranging from 1.1.7 to 1.4, including custom VMs, such as IBM's J9 VM for embedded devices. The use of the internal compiler, instead of the JDK ones, is required to support features like incremental compilation. When a class is executed from within Application Developer using the Run button or the Debug button, it is executed using a native JRE.

The advantage of Application Developer using a native external JRE is that it allows switching of JRE levels easily. It also means that you can test and debug in an environment that is closer to the end-user environment. When you use the Run or Debug button on a class with a main(String[]) method, it is executed using a native JRE that you specify. Another advantage of using a native JRE is that the user can switch JRE levels without waiting for IBM to upgrade its UVM and bring out a new release of VisualAge for Java.

The disadvantage of having a native JRE, rather than the UVM, is that some features of the UVM are lost. The most noticeable one is "hot swap," the ability to make changes to code and have the UVM load the changes without having to exit the program. This is a huge productivity aid in VisualAge for Java because while you are debugging a program, you can make changes and then test them immediately. You can also rewind the stack frame inside a running program, make changes to variables or run ad-hoc code inside the program, and then resume the program. This feature is proprietary to VisualAge for Java's UVM, although it is included in JDK 1.4. Application Developer was developed while the JDK was still in beta version, so although JDK 1.4 is supported as a run-time environment, the Application Developer debugger does not support hot swap.

Back to top

Getting started with Application Developer: Writing the Hello World application

Let's get started using Application Developer by writing the proverbial Hello World application. We will cover the following topics:

• The organization of source and code
• How to compile Java programs, and find and fix errors
• How to execute Java programs
• How to add new a new Java run-time environment (JRE) to Application Developer and change JDK levels
• How to run scrapbook ad-hoc Java code

Where do I start?

VisualAge for Java has many different browsers, such as the projects browser or the class browser. Application Developer is built on a generic code base that lets many different tools be written in the same workbench and has a concept known as perspectives. Each perspective has its own set of views, toolbar options, and menu options that are geared towards the scenario that the user is working to solve. There is a perspective for J2EE development, one for profiling, one for XML, and one for Java development.

In Application Developer, switch to the Java perspective by selecting Perspective => Open => Java. This brings up the set of views that lets you perform Java programming.

Projects

Before you create a class, you must create a project for the package to exist in. To create a Java project, switch to the Java perspective, and select File => New => Java Project. When you select the option to create a Java project, a wizard will launch, the first page of which is shown in Figure 1 below.

The Application Developer project is similar to a VisualAge for Java project in that it is used to group packages together. Other than simply being organization units, Application Developer projects define the following:

• Location of files, including the Java source files, the .class binary files and the resources.
• The build path which is specified on a per-project basis and specifies which other Application Developer projects or external JAR files containing code will be used for compiling code.
• The JDK or JRE level that is used when classes are tested or debugged.

I will now discuss each of the above.

Location of files within the project

VisualAge for Java stores its source in a repository known as Envy. This has many useful features, such as the ability to hold multiple versions of source code and support for team programming. The disadvantage of Envy is that it was proprietary and when you wanted to get the code to run outside of VisualAge for Java, you had to export your code. This is not the case with Application Developer, since source files are stored in the file system.

In Application Developer, each project can contain folders or files, and a folder can contain files. This structure maps directly to a file system, with a project being a root of a directory tree, and folders being directories. Application Developer projects have natures associated with them, and a project that is created as a Java project has a Java nature. If you create a project and don't specify it to be a Java project, you cannot later change it to be a Java project. When you create a package in a Java project, it is stored in the file system as a set of directories. For example, the package com.ibm.foo is stored as the directory tree /com/ibm/foo beneath the project.

Figure 1 above shows the project location path for My Test Project, which is the directory C:\WSA_135\eclipse\workspace\My Test Project. All package folders in the project will be located in this directory. If you do not use the default location, but instead choose to place the project's contents in another directory, this folder can contain already existing files. This is useful if you wish to have a directory that already contains some Java and class files that you wish to simply begin editing within Application Developer. All you need to do is create a project that has the location of the parent of the package root, and the code is automatically available to work with inside Application Developer. This is not the same as an import which traditionally takes a copy of the files being imported, because as you make modifications within Application Developer, the changes are reflected directly in the file system.

Build path for the project

In VisualAge for Java, when you write a class, it is built against the entire contents of the workspace. When code assist is used or the class is compiled, its external references are validated against every other class in the workspace. This means that you can write classes quickly without having to worry about which other classes are required, but it only delays this to later in the development process. You can execute the class inside VisualAge for Java by pressing the Run or Debug button. At this time, a virtual machine is created and only the classes in the same project as the class being run are loaded. This often leads to a java.lang.ClassNotFound exception. To fix this, you must open the properties against the class and specify the other projects that will be loaded by the VM when the class is run or debugged. To help with this, you can click the Compute Now button; this will analyze the referenced classes and create the list of required projects.

Unlike VisualAge for Java, where the project path is specified on a per-class basis, Application Developer specifies this on a per-project basis. Each project has a build path that contains a list of required projects and external JAR files. The build path is used for code assist and compilation, which will only work with the list of classes in the build path. When you press the Run or Debug button, the VM that is started by Application Developer to execute your class has its classpath set to the build path of the project. The advantage of the Application Developer approach is that it is closer to a real Java environment, where you concern yourself with class paths at compile and run time.

In the New - Java Project pane, click Next to get to a pane that lets you configure the build path (see Figure 2 below). The purpose of the build path is to define which classes and resources you want to be available to classes in your project. If these classes are in other projects inside Application Developer, click the Projects tab and select the required projects. Figure 2 below shows that the Utilities project has been selected for inclusion in the build path and the Archiver project has not.

Select the Libraries tab to add any external JAR files to the build path without having to explicitly import them into the workbench. Select the Order tab to define the order of the elements in the build path: the required projects and external JAR files. Reordering these can be thought of as changing the order of the -classpath arguments to a javac or Java command. After a Java project has been created, the build path can be changed at any time using the properties dialog.

Once you have created a project, it appears in the packages pane as a folder icon with a small J in the top right corner to indicate that it is a Java project. Any referenced JAR files, such as rt.jar that comes from the JRE, appear beneath the project "Test Project" in the packages pane. To hide these and only show packages and files that are actually in the project, click the down arrow button on the packages pane, and select Show Referenced Libraries. See Figure 3 below.

The JDK or JRE level of the project

With Application Developer, to switch the JRE level, you must first obtain and install another JRE on your machine from either IBM, Sun, or whomever else is your JRE provider. The Preferences dialog lets you make Application Developer aware of the available JREs. Figure 4 below shows the Installed JREs that by default includes the VM that Application Developer itself was launched with.

Click the New button to add a new JRE. A JRE contains the files required to execute and debug Java in a run-time environment, whereas a JDK contains other items such as a compiler, a command line debugger, and often the Java source files for the JRE classes. You can use a JDK as a JRE for Application Developer, which affects the list of classes to be compiled and run against, but it does not change the compiler that is used; that is always the internal compiler that is part of Application Developer. In addition, the JRE is used to test and debug Java class that are launched through their main(String[]) method, but not those launched through the WebSphere Test Environment; this uses the JRE that ships with WebSphere and cannot be easily changed.

I obtained a JDK from Sun and installed it on my machine in the C:\Sun jdk 1.3.1 directory. To add this, its home directory is entered in the Add JRE dialog. See Figure 5 below.

When the home directory is entered, the dialog will check that this is a valid JRE. It will also look for the rt.jar and src.jar files. JREs include the run-time code as class files in the rt.jar file, and JDKs may include the source code as Java files in the src.jar file. Figure 5 above shows that src.jar has been detected and is shown as the JRE source file. The standard detected VM that is included with Application Developer does not include a src.jar. If you want to, you can obtain a JDK src.jar file and edit the detected VM to point it to another src.jar file. However, you will need to be very careful to obtain the src.jar file with the matching code; otherwise, when you debug the code, the line numbers in the classes and the source will not match. Because of this, if you intend to do much debugging and stepping into JRE classes, I strongly suggest obtaining a JDK that has source, from either IBM or Sun, and use this to run your Application Developer code.

When there are multiple JREs, you can choose one of them to be the default. You can do this by selecting the check box in column one of the installed JREs. See Figure 6 below, where I have made Sun's JDK 1.3.1 the default JRE.

When Test Project was created, we let it use the default JRE level. When the default JDK is changed, as was done above, all projects that are using the default JRE level will change to use the new default and their classes will be recompiled. If you open the project properties as shown in Figure 7 below, you can see that Test Project will always use the default JRE level. If you want to override this, you can specify a custom JRE and select one from the list.

Creating the Hello World class

After creating the project, click the New Package button to launch a wizard that lets you create a package. Alternatively, you can click the New Class button to bring up the dialog shown in Figure 8 below. If the package name entered on the New - Java Class wizard does not already exist, it will be created for you. The New - Java Class wizard lets you specify the superclass, any interfaces that you want the class to extend, and which default methods you want to be created for you. For the HelloWorld class, we want it to have a main method that we can use to execute it.

In VisualAge for Java, the mode of working is that there was a single source pane that responds to the selection of one or more trees or list panes for its input. For example, you can click on a class and see its source, and then click on another class and see its source in the same text pane. Application Developer has a very different way of working where each file to be edited is individually opened with separate editors that are stacked as a series of notebook pages. Figure 9 below shows the HelloWorld class opened with its editor being the first notebook page.

Unlike VisualAge for Java, if other files are selected in the packages list, they will not cause the source page to change the contents of the class it is working with. You must open each source file separately by double-clicking it, or clicking Open on its pop-up menu. As more files are opened, new editors are created as notebook pages, and when more notebook pages are created, left and right arrows appear so that you can scroll across the pages. This is shown in Figure 10 below. HelloWorld.java is the current editor and is shown with a gradient blue toolbar page label. Other open editors are shown next to this, and clicking these will change the active editor. The * shown on the title of a file's editor page, such as *MyProperties.properties in Figure 10, indicates that the editor's contents are "dirty" -- the source displayed in the editor is different from the saved source.

Compiling and fixing errors

When a Java source file is saved, it is compiled. Like VisualAge for Java, the compilation is incremental, so all affected classes are also recompiled. This includes subclasses or classes that reference the changed class. Having automatic incremental compilation is very useful, but there are times when it gets in the way. For example, you are about to perform a large re-factoring exercise such as renaming methods or moving classes. You know ahead of time that many classes will be broken so you would rather just perform the refactoring of all of the affected classes and then do a compilation. This eliminates time spent on compilations that you know will not work, and also reduces a lot of "noise" as red Xs start appearing prematurely. To do this, you can switch off the option to perform automatic compilation using the Preferences dialog in the Workbench menu. This is shown in Figure 11 below.

Selecting the check box Perform build automatically on resource modification lets you control whether compilation should occur when Java source files are changed or not. The reason it is called "build" rather than "compile" is because Application Developer has build steps other than just Java compilation; for example, reporting broken links for an HTML file. If you deselect the option to build automatically, it affects all of Application Developer and not just Java compilation.

If you do decide to not have the build be automatic, you must still be able to invoke it when you are finished refactoring. This is done by choosing the Build menu option on the project. Application Developer remembers the files you have changed, so it only compiles the changed resources. If for any reason you wish to recompile everything, select the RebuildAll menu option.

All errors in a Java file are reported in the Tasks View at the bottom of the Java perspective. Figure 12 below shows that a mistake was made in HelloWorld.java where the println method was entered as printlx.

The HelloWorld.java file is flagged as having an error. This error causes a red X to appear in the class in the Packages pane. Any package containing classes also have a red X against them; the project itself also has a red X, enabling you at a glance to see which projects or packages contain classes with errors. The tasks list also shows errors, along with details about the error, and the line number. When you double-click on an entry in the tasks list, it will open the appropriate editor and for the Java source editor, select the code in error. Warning errors such as calls to deprecated methods are shown with a yellow triangle rather than a red X.

The tasks list, showing all errors, is similar to the All Problems page in VisualAge for Java. Besides seeing all problems for the workbench, there are times when you want to see only the errors for a given file, and you can do this using the Filter Tasks dialog. Launch this dialog by clicking the button on the title pane of the Tasks list.

The Filter Tasks dialog lets you choose what type of entries you want in the tasks list with a check box tree of items. You can specify whether you want to see Problems or Tasks, and for Problems, these are further categorized into problem types. The reason for this is that the tasks list does not only show compilation errors, but also shows markers held against the file. Different markers are created and can be purely informational, such as Tasks or Bookmarks that have run-time significance, such as breakpoints, or that are used by the Application Developer builders, such as problems. To create Tasks or Bookmarks, select the Add option from the pop-up menu in the Java source editor that brings up a sub-menu with breakpoint, bookmark and task. Bookmarks are useful for inserting comments in the code, such as "Fix this later" or "This needs optimizing."

One very useful option that the Filter Tasks dialog lets you do is show the tasks for a selected resource, rather than on just any resource. When this is done and you select a Java source file in the packages viewer or select its editor page, you will see only its errors. This helps reduce noise when you are only interested in fixing a file at a time. Showing tasks for all resources lets you see all the errors at once.

As well as showing the error with a nice little red X in the margin, Figure 12 above shows a hashed ruler around the main method which is also selected in the outline view. If you select an entry in the outline view, the source page will show the ruler against the selected entry. If the source file is large and the entry is for something that is off the screen, it will automatically scroll the source into view. This is very useful to navigate to a method: the outline sorts methods by name and you can scroll to the method you want and select it and have it brought into view. VisualAge for Java has two modes for working with Java source: a full screen view and a restricted view where the source was only for the selected item. Application Developer provides the same option through the toolbar button . When you click this button, the source page will show only the code for the selected outline entry.

To correct our error of printlx being spelt incorrectly, we can change the code to be println and press save to recompile. VisualAge for Java has a nice feature where errors are prompted upon save, together with possible corrections, but this does not exist in Application Developer. If there are multiple errors in a Java class, you can scrolled through them using the buttons on the toolbar.

Running Java code

When you run Java code, Application Developer by default will switch you into its Debug perspective. The Debug perspective has a different set of views. The Debug perspective is of course useful if you want to debug some code, but for simply running and testing code, the Java perspective is sufficient. To change Application Developer so that it does not switch you into the Debug perspective, you can use the Preferences dialog. Launch this dialog by selecting Window => Preferences.

Figure 14 above shows the set of options available in the Debug preferences. Deselect the check box Show Debug Perspective when a program is launched in run mode to remain in the Java perspective.

There are a number of ways that you can launch a program in Application Developer. A future article will cover these in more depth, but the one that we want to use for a standalone Java application, such as Hello World through it static void main(String[]) method, is selecting Run => Java Application. Click the down arrow next to the Run button (the picture of the running person) and you will get a menu with various options, as shown in Figure 15 below. Selecting Java Application will run the static main(String[]) method of the selected class.

If you didn't change the workbench preference (see Figure 14 above), Application Developer will switch you to the Debug perspective; otherwise, it will remain in the Java perspective. The tasks view at the bottom of the window, that previously showed the compilation error, is made up of three notebook tabs, one of which is the console. After running a program, it is switched to the console view and the string "Hello World" that was output to the console is displayed (see Figure 16 below).

You can click the eraser button in the top right corner of the console view to clear the console output. Having run a program, can you always re-launch the last program you ran by simply pressing the F10 button on your keyboard. F10 is the shortcut key for the menu option Debug => Relaunch Last.

Instead of having to specify each time you run a class that you want to run it as a standalone Java application through its main(String[]) method, you can make this the default launching method for your project. To do this, open the properties for the project by selecting the Properties pop-up menu option on the Test Project in the Packages pane. In the Properties dialog, select Launcher from the list. The drop-down menu displays the types of launchers that Application Developer provides; select the one that you want to become the default launcher for the project. Figure 17 below shows that the default launcher for Test Project has been set to Java Application, so that you do not have to re-specify it each time the Run button is pressed.

When you press the Run button, the HelloWorld.class is run. This was done with the JRE level specified for the project (which is the default one shipped with Application Developer). Unlike VisualAge for Java, which had its own proprietary VM and built-in JDK, this is a pure JRE implementation. The code that was run were the class files that were built; they are located in the directory, C:\WSAD-Beta\Workbench\Test Project\com\IBM\wsad\testjava. No export was required to get code out of Envy and the workbench to run with the JRE; it is already compiled into the file system and executed with a standard JRE.

Back to top

Conclusion

The next article in this series will cover some additional topics, including:

• Debugging Java programs
• Using the Scrapbook pages to write ad-hoc code snippets
• Version control, team programming and file synchronization
• Profiling and tracing code for performance analysis

Top of page

Resources

• This article has introduced you to the basics of Java programming using WebSphere Studio Application Developer and drawn parallels with VisualAge for Java. For more details on Java programming using Application Developer, read the following articles by Sheldon Wosnick:
  • Developing and Testing a Complete J2EE Application with WebSphere Studio Application Developer, Part 1
  • Developing and Testing a Complete J2EE Application with WebSphere Studio Application Developer, Part 2: Running on WebSphere Application Server 4.0
  
  
  

About the author

Joe Winchester is a member of the WebSphere Tools Development team working for the Software Solutions group in Research Triangle Park, North Carolina. He has worked on the development of two VisualAge persistence features: Object Extender for Smalltalk and Persistence Builder for Java.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Overview
• Getting started with Application Developer: Writing the Hello World application
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers