 | Level: Introductory Joe Winchester (winchest@uk.ibm.com), WebSphere tools developer, IBM Hursley Lab, United Kingdom, IBM
22 May 2002 Are you a VisualAge for Java developer looking to move to WebSphere Studio Application Developer? This article continues the comparison of the Java editing capabilities of Application Developer and VisualAge for Java, discussing the Scrapbook, source code management, and debugging functionality.
Introduction
My previous article,
Comparing WebSphere® Studio Application Developer and VisualAge® for Java™-- Part 1
, discussed the basics of Java programming with WebSphere Studio Application Developer (hereafter called Application Developer), the strategic replacement for VisualAge for Java. The article compared programming tasks in the two products, such as how to specify the JDK level, how code is stored in folder structures on the file system, and how to write, compile, and execute a Java program. This article covers additional topics, including:
- Running ad-hoc Java code with the Scrapbook
- Tracking modification history
- Debugging code:
- Setting breakpoints
- Debugging remotely
- Stepping through code
- Exceptions
- Suspending running programs
- Inspecting and displaying variables
For each task, the functions of VisualAge for Java and Application Developer are compared. (Distributed debugging is not possible with VisualAge for Java, but can be performed using the IBM®Distributed Debugger that is included as a separate install on the VisualAge for Java CD.)
Running ad-hoc Java code
There are times when you want to test pieces of code without the overhead of creating a class with a
main(String[])
method, compiling it, running it, and so on. Running ad-hoc code is especially useful if you are not familiar with an API or if you want to play around with some classes and test an idea before formalizing it in application code.
VisualAge for Java
VisualAge for Java lets you create and run
ad-hoc code fragments with its Scrapbook pages.
Execution results can be displayed directly in the
Scrapbook page or viewed with an Inspector, and
Scrapbook pages can be saved to the file system for
later use. To control the scope of execution of the
code on the Scrapbook page, VisualAge for Java lets you
select a class to run the page in. When a page is run
in a class, it is as if the page were written as a
static method on the class -- the import statements and
static variables in the class are available to the code
in the page. Each time you run a Scrapbook page, a
virtual machine is created to execute the code, and
this virtual machine is not automatically terminated.
Therefore, if your Scrapbook page is run in a class and
it updates a static variable, next time any code in the
page is run, that static variable will have the value
from the first execution. To terminate the virtual
machine behind the page, use the Restart option. The
persistence of the virtual machine between subsequent
executions of code in the page means that you can
create an environment such as a database connection
once, then use it multiple times or create a scenario
and iterate several times with the same context.
Application Developer
Scrapbook pages exist in Application Developer, but they work differently than they do in VisualAge for Java. In VisualAge for Java, when you write code in a Scrapbook page and run it the code is turned into a static method called
Doit
on the Java class that you have selected for the page to run in. The code is compiled and any errors are shown on the page. The creation of the method is hidden, so it doesn't appear in the list of methods on the class, and does not create a footprint in the repository.
In Application Developer, on the other hand, you define different build paths for each project. The build path can be thought of as the classpath that the javac command uses to compile code, and it is also used as the classpath for running and debugging code. Different projects can even have different JDK levels, which is not possible in VisualAge for Java. Therefore Scrapbook pages are not pointed to a given class to run in, but are just created as artifacts within a project. This is unlike VisualAge for Java, where the pages are created at the workspace level. To create a Scrapbook page, select
Java Scrapbook Page
from the
New
toolbar item, as shown in Figure 1 below, or else use the toolbar button with the same icon.
Figure 1. Creating Scrapbook pages from the new pull-down toolbar item
The Scrapbook page wizard asks for a folder and a name. If a Java project has already been selected in the packages list, then it will be filled in, otherwise one needs to be selected. The name is arbitrary -- for our example we will create a Frame with the title
Hello World
and show it so the page is called
HelloWorldTestPage
.
Figure 2. Scrapbook page wizard asking for the folder and the project
Once the Scrapbook page has been created, it is opened in the Editor pane. The page exists as a file in the target folder for the project and has the file extension
.jpage
. You write code in the Scrapbook page as though it were a Java file editor, and you can use Code Assist, Format, and other Java editing functions. After you have written your code, you must select the fragment of it you wish to run. To select the entire page, use
Edit => Select All
or type
Ctrl-A
.
Figure 3. Code written in the Scrapbook page is selected before being executed
To run the selected code, use the toolbar button with the running man on top of the Scrapbook page image (
), or type Ctrl-E. Any compilation errors are shown in the page at the point that they occur. This is similar to VisualAge for Java, but different from Java classes written in Application Developer, where errors are shown in the Tasks list. When the error appears in the source, it should be selected so that you can just press the delete key to remove the error message from the source.
Please use care when deleting the message to preserve the original java code in the line, although the undo action from the Edit menu will correctly remove all error messages inserted in the scrapbook source.
When you click Run, a .class file is created and a JVM is started using this .class file with a classpath from the entries in the project's build path. To end the JVM that has been created, click the square toolbar button (
) . You can also end the Scrapbook page's JVM by switching to the Debug Perspective to view a list of all running process, and end it from there. For more information, see the Debugging section.
The .class file that is created is called CodeSnippit.class and will exist in the directory structure in the file system beneath where the project is stored. When the class is created, it must be given a package, which by default is org.eclipse.jdt.internal.eval.target. This results in a package being created, if one is not already there, in your project with this name. This package will appear in the packages list in the Workbench, and a directory will be created in the target file system. For example, in Figure 3 below, Application Developer is installed in C:\WSAD-R10 and the temporary Scrapbook .class file is stored in C:\WSAD-R10\eclipse\workspace\My Test Project\org\eclipse\jdt\internal\eval\target\CodeSnippit.class. This can look odd in both the Navigator and the file system, and I prefer to just use the default package to compile Scrapbook pages into. You can change the package using this button (
) which brings up a list of packages.
The package for the running code is where the .class file will be stored. All packages are shown in the Packages list, regardless of which project they are in, as shown in Figure 4 below.
Figure 4. All packages in all projects are available to run Scrapbook code in
Sometimes you may not want to use the default package, such as when you want to avoid excessive use of import statements, and let your Scrapbook code have access to package projected classes, methods, and fields. For example, if you had a package called
com.mycompany.myobjects
with a lot of your domain objects such as Customer and Department, and you were writing Scrapbook code to test these classes, then rather than having to fully quality each class name, you could run the Scrapbook code in the
com.mycompany.myobjects
package and leave the classes unqualified with their package names. The project in which the Scrapbook page is stored and run does not have to be the same one in which the package resides inside the Workbench. There can be problems with Java security, however, such as for the Scrapbook page shown in Figure 3 above. This page references
java.awt.Frame
, so it would be nice to run the page inside the
java.awt
package and not have to fully qualify the Frame class wherever it appears. Although this can be done and the page compiles, it cannot run because the default Java security manager does not allow classes in packages starting with java or javax to be introduced into a JVM through its classpath. To introduce classes in packages starting with java or javax, you must use the bootclasspath, and there is no mechanism in the Application Developer Scrapbook pages to enable this.
In addition to running Scrapbook code and
terminating the process, you can run Scrapbook code
and inspect or display the result by selecting a
code fragment and using the toolbar button (
). The
result is shown in the Scrapbook page and is the
return value from the last executed method in the
code. If there is no return value, the message
"No explicit return value" is
displayed. The code in Figure 3 above has the
method frame.setVisible(true); as its last method
and the setVisible method is void. Therefore, if
you select the code and click the display button,
the code is executed and the frame displayed as
though the Scrapbook Run code button were pressed,
except that the message "No explicit
return value" is shown. To see the value
of a field, just enter it on a statement as the
last line. For example, to see the toString()
method of the frame, add the line frame; to the end
of the Scrapbook code. When you click Display, the
frame is shown:
java.awt.Frame frame = new java.awt.Frame();
frame.setTitle("Hello World");
frame.setVisible(true);
frame(java.awt.Frame) java.awt.Frame[frame0,0,0,112x27,
layout=java.awt.BorderLayout,resizable,title=Hello World]
|
You can also inspect a value as well as display it. In the above code fragment with the frame variable on the last line, clicking the (
)button runs the Scrapbook code fragment and then opens an Inspector on the last evaluated expression, namely the frame. The Inspector opens as a new viewer on the right side of the perspective. See Figure 5 below
Figure 5. The Inspector is opened to the right of the editor pane
The Inspector shows the internal state of the object being inspected. Blue Triangles represent protected fields (
), red squares private fields ( ), and green circles public fields (
) . Each entry in the Inspector shows the name of the field together with its current value. If a field has fields within it, a "+" is shown, which you can use to drill down through the fields. One difference from the VisualAge for Java Inspector is that you see the type of a field's contents together with the hashcode of the object, but you do not see the toString() method. For example, the foreground color of the frame is shown as the line foreground color=Color (id=51). This does not let you know which color object it is, something that the toString() method often includes for objects and was a nice feature in VisualAge for Java that is missing in Application Developer.
The toolbar of the Inspector lets you control how much detail is shown on each line, as well as which items are included in the list. The Toggle button (
)lets you toggle on or off whether the names of the field types should be shown before the field name. If Toggle is on, then the line active=true becomes boolean active=true. The Next button (
) toggles whether type names are qualified or not. If the type name is set on, then the line foreground color=Color (id=51) becomes foreground color=java.awt.Color (id=51). If the Show Field Types were pressed as well, it would show java.awt.Color foreground color=java.awt.Color (id=51).
The other two useful toolbar buttons are (
) which toggle whether or not static fields and final fields are shown. With the two buttons depressed as shown, then static fields and final fields are not shown. When the buttons not selected, these field are shown. If a field is private, it is normally shown with a red square, and if the field is private and static a red S is shown in the corner (
). Likewise, for a final field, a blue F is shown ( ), and for a field that is both static and final, the S and F are combined ( ). In some cases, you can change the value of a variable using the Change Variable Value pop-up menu option -- for more information, see the Debugging section.
The Scrapbook is a useful feature in Application Developer that lets you run ad-hoc code fragments without having to create and manage lots of test classes. Because VisualAge for Java had its own proprietary JVM, it let you specify which class your code ran on, and an extra method was created on the class and lasted only as long as the Scrapbook JVM did. This would be hard to do in Application Developer because there is no API in the JDK, and if you recompiled the
.class
file of the target class itself, this would affect your target run-time environment in an obtrusive way. Therefore, Application Developer lets you specify the package in which you want the class to be compiled and run. This removes the need for one import statement, but does not give you the same power as specifying a particular class that could include multiple import statements and be visible to class members that are not visible to the Scrapbook code. Even with this restriction, the Scrapbook is a powerful feature of Application Developer and a very effective "code sandbox."
In summary, having a proprietary JVM in VisualAge for Java caused several limitations such as not being able to use new versions of the JDK, build against the same JDK in or out of the VisualAge for Java environment, or requiring the server environment to be imported and running in the VisualAge for Java JVM. The proprietary JVM design did however enable easier execution of ad-hoc code snippets. In contract Application Developer is completely configurable to the JDK the users wants to use, but even with this design, the scrapbook is a powerful feature of Application Developer that can be used as a code sandbox.
Tracking modification history
VisualAge for Java
One of the most popular VisualAge for Java features is its built-in repository known as Envy. Envy keeps track of source code changes, so that if you ever need to go back to a previous version of your work, all you need to do is load a previous edition of a class or method. Envy operated at the method level, so that even if you change a class many times while it is an open edition, every change to a method is stored, enabling you to track almost every modification through the history of the method editions.
The disadvantage of Envy is that in order to achieve
this high level of version history, it stores code in a
proprietary VisualAge repository. Moving the code
outside the repository into the file system or into JAR
files requires exporting the code. In the early days of
VisualAge, this was not a big problem because most
development was done with the code inside Envy and
export was only required for deployment. Java, however,
expects source and object code to be stored in the file
system, either in folders or JAR files, which are made
available to class loaders through the classpath of the
compiler or java command. When developing server code
with VisualAge for Java, you need to either import the
server environment and run it inside of VisualAge for
Java's proprietary JVM, or else export the code after
each modification to test it in the server, which
requires lots of turnaround time to see the effect of
changes. IBM therefore decided to go from using Envy to
using a standard, file-based code repository.
Application Developer
As you develop source code in Application Developer, it is held directly in the file system. The default location of a project's source code is in a file system subdirectory under where Application Developer is running, although you can change this using the New Project wizard when you create a project. For example, the Scrapbook page created earlier in this article is stored in
C:\WSAD-R10\eclipse\workspace\Hello World Test Page.jpage
, where
C:\WSAD-R10
is the install location of Application Developer.
A source code management (SCM) system lets you manage source files in a team environment using a central repository, so that multiple developers can synchronize their changes and resolve any code conflicts. For a full description of how to install and configure an SCM system such as CVS with Application Developer, see
Team Development with WebSphere Studio Application Developer 4.0 -- Part 2: Installing and Configuring CVS as an SCM
.
Even without a full-blown SCM, Application Developer has a powerful feature called Local History. One of the things developers like about Envy is its ability to always let you go back to the previous version of a method or class without requiring you to explicitly create a version or baseline. This is like having unlimited source level "undo," so that if you have a bad afternoon of programming you can wind a class all the way back to the code you had before lunch and restart from there. Application Developer's Local History feature keeps track of all changes to source and gives you almost the same level of convenience as Envy does. I use Application Developer daily to write Java code and I find that Local History is one of its most powerful features. Each time you save a file, changes from the previous version are stored. To compare a file against a previous version, right-click on it and select
Compare with => Local history
.
Figure 6. Local History lets you compare files with recently saved copies
The Local History browser shows you the currently loaded version in the Workbench pane on the left. A list of previous versions is shown, and when you select one its contents are displayed in Local History pane on the right. Versions are listed by date, so if you want a version you saved on a particular date, you can easily navigate to it. The Compare Browser tries to find the differences between the lines and renders these to show you the insertions, deletions, and changes. The first change is selected and the Down and Up arrows let you cycle through the changes. Figure 7 below shows that the line
was changed to the two lines
frame.setVisible(true) frame. |
Figure 7. The Compare Browser shows you a history of recent changes
In addition to comparing changes, you can use the menu option
Replace with => Local history
. It opens the same Compare Browser, expect that there is a button labeled Replace. If you find a version you want to revert to, select it in the list, click
Replace
, and it will be loaded in the workspace.
In order to keep track of changes, Application Developer stores change data in a cache, and you can control its parameters by opening the Preferences page and selecting
Workbench => Local history
.
Figure 8. Controlling the parameters of the Local History cache
The Local History preferences let you control how long you want old files to be kept, the number of entries per file, and the maximum file size. If you have plenty of disk space you can increase the number of days from 7 to 31 and always have the ability to roll back files to anytime within the previous month. Entries per file are the number of changes in a file you want to record a change for. Local History keeps track of the changes between files rather than storing the entire old and new files. This saves space -- the delta between two files is smaller than the two files themselves. You can see the local history files at
.../workspace/.metadata/.plugins/org.eclipse.core.resources/.history
although they are stored in an internal format
to save space. With the entries per file set at 50, you
can change a file 50 times, save it, do a compare, and
page through all 50 changes. If you made more than 50
separate changes, they are all rolled into one change.
I recommend decreasing the number to 20, because it is
time consuming to page through 50 changes to see what
has changed between one version of a file and another.
If many changes were made, you usually want to go back
to the previous version altogether instead of
piecemeal. A change us defined as an addition,
deletion, or modification of code. If you paste a file
into another file it is logged as one change, but if
you make changes in one part of a file and then in
another part it is considered two changes. When you
save the file, the old and new copies are compared
line-by-line and heuristics are applied to determine
the number of changes. Maximum size of a local history
file is 1 MB, which is the space allocated to storing
the delta. This should be plenty for all but the
largest source files, but if you make more than 1 MB of
changes per save, you can increase the size of a local
history file as long as you have enough disk space.
When IBM first announced that Envy was being replaced with a file system storage mechanism, there was some concern expressed on newsgroups from users that had grown to rely on Envy as a crutch for having version history always available. However, the local history mechanism in Application Developer does offer a high level of functionality that comes close, and will more often than not help, when you have made a terrible change and just need to rollback to a previous day's code. For true team development a repository such as CVS should be used.
Debugging code
VisualAge for Java
Another VisualAge for Java strong point is its integrated debugger. It lets you debug code, inspect variables, step through code line-by-line, and change source code and variable contents while the program is running. Some of this technology relies on the custom JVM used by VisualAge for Java ,which is not a part of Application Developer. Application Developer lets you use any JVM to run code, and the previous article in this series,
Comparing VisualAge for Java and WebSphere Studio Application Developer -- Part 1
, shows you how to add additional JVMs and configure them to be the one used when code is executed. Although it lacks the custom JVM of VisualAge for Java, the Debugger in Application Developer is very powerful. The main missing feature is the ability to modify source code, drop the stack to a selected frame, and rerun code all inside an executing program. If you find a bug or want to change code, you must stop and start the program being debugged to see the effect of the changes.
In addition to the VisualAge for Java Integrated Debugger, the IBM Distributed Debugger was included as part of the VisualAge for Java install. It lets you debug any JVM, so it has the advantage of working with JVMs outside VisualAge for Java, non-IBM JVMs at different version levels, and JVMs inside applications such as WebSphere Application Server (for more information, see
Debugging Java code running inside WebSphere Application Server
).
Application Developer
A major objective of Application Developer is to move away from the proprietary techniques in VisualAge for Java towards open, industry standard ways of doing things. The Application Developer Debugger is therefore similar to the IBM Distributed Debugger instead of the VisualAge for Java Debugger. But by running inside Application Developer instead of standalone as with VisualAge for Java, the Distributed Debugger can be closely integrated with the source code and resources such as running servers or programs. This article focuses on debugging standalone programs, either launched by Application Developer or launched externally and debugged remotely, which involves functions such as inspecting variables and evaluating expressions inside the JVM being debugged. To learn more about using the Application Developer Debugger and attaching to the JVM running inside WebSphere Application Server see
Debugging WebSphere Applications using the WebSphere Studio Application Developer Debugger -- Part 2
.
To use the Debugger, you need to be in the Debug perspective, which contains the views with the list of processes, the stack frame, and so on. To switch to the Debug perspective you must first have one opened, which you can do by selecting Perspective => Open => Debug. If a Debug perspective is already open the icon (
) will appear in the left side toolbar and you can just click it . To switch back to the Java perspective, click the left side toolbar icon (
). Application Developer can also switch to the Debug perspective automatically. You run a program in Application Developer by clicking the toolbar Run button (
), which starts an external JVM using the classpath of the project's build path and the JRE java command. By default, Application Developer switches you to the Debug perspective each time a program is run, although you can configure this with the Preferences page.
Figure 9. Preferences for Debug let you specify when the Debug perspective is opened
Because the Console is available in the Java perspective, I usually disable the option to show the Debug perspective in Run mode, but select the option to show it in Debug mode. This way, when you are coding in the Java perspective, you can run and test you code, check the results, and continue coding, without switching back from Debug to Java perspective repeatedly.
To run a program in Debug mode, use the toolbar icon (
). The drop-down arrow brings down a list of known launchers, and Java Application is used to run a program that has a public static void main(String[] args) method. For more information on launching, including how to configure a default launcher, see the previous article in this series, Comparing VisualAge for Java and WebSphere Studio Application Developer -- Part 1. When the debug button is used, the external JVM is started with the -Xdebug option. Application developer then attaches to the JVM and acts as a remote debugger. To demonstrate the Debugger, you can debug the HelloWorld class from the previous article.
public class HelloWorld {
public static void main(String[] args){
System.out.println("Hello World");
}
} |
After compiling the class, select it in the Navigator and use the option to debug it as a Java application. This will start a JVM in Debug mode, the result will be written to the Console, and the JVM will terminate. To debug the program, it must either reach a breakpoint, or else not terminate, whereupon you can select the thread and suspend it. In either Debug or Run mode, you can specify the program and JVM arguments on the Properties of the class, available from its pop-up menu.
Setting breakpoints
VisualAge for Java
VisualAge for Java lets you add breakpoints by double-clicking in the left margin of the source code. When the breakpoint is reached, the program stops and you can inspect the stack and then continue stepping through the code. The feature that VisualAge for Java has and Application Developer doesn't have is the ability to disable breakpoints or make them conditional. Disabling is useful if you don't want a breakpoint to stop the program, but you want to leave it there for later use. A conditional breakpoint is useful if a statement is being executed many times and you want to stop on it at a specific iteration. You can write a condition as an ad-hoc Java expression that executes each time the breakpoint is reached, and the Debugger stops only when the expression is true.
Application Developer
Other than not having optional and conditional breakpoints, Application Developer's breakpoints are similar to VisualAge for Java.
Breakpoints are added in the Java Editor by double clicking in the margin of a source statement. The breakpoint is shown as a blue dot, as shown in Figure 10 below. To remove a breakpoint, double-click again on the line or use the pop-up menu in the margin.
Figure 10. Breakpoints are added and removed in the margin and shown as a blue dot.
When a program is run in Debug mode and a breakpoint is encountered, the stack frame is shown. Figure 11 below shows the result of running the
HelloWorld.java
class (shown in Figure 10 above) in debug mode.
Figure 11. The stack frame shows the list of threads and the stack frame for suspended threads
The Debug perspective is shown in Figure 11 above. The Debug viewer shows two processes -- the first has <> brackets around it and is the earlier Hello World that was executed in debug mode. To remove a terminated process, use the (
) toolbar button on the Debug viewer. The Hello World process without the < > around it is still executing. It contains four threads, and you can see the stack frame of the HelloWorld class together with the stopped line highlighted in the Editor pane, with the stopped breakpoint shown in green. One nice feature is that you can select a process that has terminated and use the Relaunch option on its pop-up menu to relaunch the program using the same options as when it was previously launched.
The Debug viewer in the top left of the workbench
in Figure 11 shows processes that are being
debugged. These processes have the debug icon next
to them ( ). Selecting the viewer tab Processes
opens a list that shows all processes including
those that have not been started in Debug mode.
These processes have the running man icon ( )
next to them. Each process represents a
separate JVM, and can be ended by selecting it and
clicking the Stop button ( ). If you select a
running process, you can see the type of JVM being
debugged in the tree beneath it. If a class is run
using Run => Java Application then this is a
locally started JVM and will have a running man
with computer icon ( ). The pop-up menu on this
item will let you see the full command-line used
run the program. This shows that Application
Developer is just using an external JRE that is
loading its classes directly from the file system
with no need for the internal JVM that VisualAge
for Java used. Looking at the full set of arguments
to the java command from the pop-up menu of the
running Java Application is a useful way to know
which classes are required by your program so you
can create a deployment set of files.
 |
Debugging remotely
VisualAge for Java -- IBM Distributed Debugger
Remote debugging is not possible with the VisualAge for Java Debugger, which only works against programs running inside its own internal JVM. The IBM Distributed Debugger can debug programs remotely by letting you open an attach dialog and enter the machine name and port number of the JVM to be debugged. The API for remote debugging used by the IBM Distributed Debugger is JPDA, which enables a debuggee to be started in debug mode and specifies how it expects a debugger to attach to it -- the protocol and any additional parameters such as a port number. The Debugger can then be on a separate machine and can locate the debuggee and control its execution.
Application Developer
One of the things that I find hard to remember when using the IBM Distributed Debugger for remote debugging is the command-line arguments required to start a JVM as a debuggee. When you run a program in debug mode with Application Developer, it launches the JVM locally in Debug mode and then attaches the Debugger to it. The process used to start the local JVM in Debug mode and to attach the Debugger are the exact same ones you would use for remote debugging, except that it has been done behind the scenes. This is useful because it means you can see and copy the arguments for starting the process in Debug mode. When a program is started in Debug mode, you must use the Debug viewer (not the Processes viewer) to see the list of threads, as shown in Figure 11 above. A nice trick to see the command-line of the debuggee is to select the tree item with the set of cogs (
) beneath the process being debugged. The pop-up menu will also show you the complete command line.
Figure 12. The command line shows the arguments to the java command for the HelloWorld class
The command line shows that HelloWorld was run in debug mode (
-Xdebug
) using JPDA debugging (
-Xnoagent
) and that the JVM was started as a debuggee listening for a Debugger to attach on socket 10279. Application Developer starts the program that you selected with the debug button as a debuggee, and then acts as a remote debugger and attaches to the JVM through the socket. This is sort of like throwing a fish into the water with your hook already attached to it and then reeling it back in. In addition to having Application Developer both launch the JVM and attach to it, to perform remote debugging, Application Developer can also attach to an already running JVM. To do this you will need the socket number that the debuggee JVM is listening to, and then instead of selecting Java Application as the launcher from the debug toolbar pull-down, select
Remote Java Application
. This brings up the dialog shown in Figure 13 below, and you can enter the host name of the machine with the JVM to debug as well as the port number.
Figure 13. Remote Java Application Launcher lets you use Application Developer as a remote debugger
To illustrate remote debugging, launch HelloWorld from a command line, and then attach Application Developer to it. Open a command prompt, change to the directory that contains the project, and enter the command line shown as the properties to the program when it was launched locally, as shown in Figure 14 below. Quotation marks have been added around the classpath keyword value because it contains spaces. The port number for the address keyword value can be any available port -- I used 3003. If the port is not available you'll get an error message and you can try a different number. If you get an error message about not being able to initialize the port, add the keyword
server=y
to the line.
Figure 14. A program can be started as a debuggee from a command line
Once the program has been started, use the Debug pull-down toolbar menu and select Remote Java Application. On the dialog shown in Figure 16 below enter the port number of 3003 and the machine name (normally localhost, but if you started the program in Figure 17 on a different machine from Application Developer, it's the numeric or named IP address of the debuggee JVM). The Debug perspective then shows the process being debugged, from which you can add breakpoints and step through code just as though the program were launched locally. When you are using Application Developer as a remote debugger, you can disconnect it from the JVM being debugged with the toolbar button of a scissors cutting a process (
). After you attach the debugger to the JVM being debugged, you can suspend the debuggee with the Suspend toolbar icon ( ), which lets you inspect the stack frame of any stopped threads.
You can use the Application Developer Debugger as a remote debugger to any JVM that has been started as a debuggee, including the JVM inside WebSphere Application Server itself. For more information, see
Debugging WebSphere Applications using the WebSphere Studio Application Developer Debugger -- Part 2
.
Stepping through code
VisualAge for Java
VisualAge for Java lets you step through code, step into code, run to the cursor, and run to the end of a statement. You can do all of these things in Application Developer, although there are some subtle differences in how they work. For example, step over in VisualAge for Java steps over the statements on a line, whereas in Application Developer step over goes to the next executable line. Run to return in VisualAge for Java requires you to use step over to exit the method, whereas in Application Developer run to return goes to the end of the method and exits it. These differences are for the most part based on the differences between the proprietary JVM that VisualAge for Java uses and the standard JPDA API that Application Developer uses. If you are familiar with the IBM Distributed Debugger, you'll find that Application Developer's step functions are similar.
Application Developer
From the Debug viewer you can step over to the next statement (
), step into the next statement ( ), or run to return ( ) . Step over takes you to the next source statement, which is slightly different from VisualAge for Java, in which each block of code is executed separately by the custom JVM, and step over takes you to the next block of code, even if it is on the same line. The API for debugging used by Application Developer is the one provided by the JRE specification, and only lets you step over code line by line. Therefore, if you are debugging a line of code with multiple expressions, you may need to break it into several lines to give you more debugging control.
Step into takes you to the next statement to be run. In Figure 14 above it would step into the out method on the
System
class.
Run to return runs the current method through to its end and drops the stack frame. Because step over goes over the whole line, it is very useful to do repeated step into's and then run to return until the method you are interested in debugging is about to execute. Then you can step into it and continue debugging. To continue the program, click the Run button (
), which continues execution until the next breakpoint or uncaught exception.
The Breakpoints Viewer displays a list of breakpoints, and on the pop-up menu for each breakpoint you can enter a Hit Count number, which is the number of iterations that you want the breakpoint to pass through before the Debugger suspends the program. This is similar to a conditional breakpoint, but whereas in VisualAge for Java you can enter a complete expression to be evaluated, in Application Developer you can only enter the number of loops that you want to pass through.
When you step into code, Application Developer tries locate the source. The JRE that ships with Application Developer does not include any source, and you may be prompted to enter the location of the source when you step into base code. It is possible to obtain the source separately and tell Application Developer how to locate it, but if you do this you need the exact level of JRE source that ships with Application Developer, and it is easier to just obtain a full JDK that includes source and use this to run and debug your programs instead of the default detected one. The previous article in this series,
Comparing VisualAge for Java and WebSphere Studio Application Developer -- Part 1
, shows you how to obtain and switch the JDK for a project that is used to run and debug its classes.
Handling exceptions
VisualAge for Java
In VisualAge for Java, if an uncaught exception is thrown the Debugger stops. You can also specify which exceptions you want the Debugger to stop on even if they are caught. This feature is also available with the IBM Distributed Debugger.
Application Developer
Application Developer does not have the ability to stop on certain exceptions, although uncaught exceptions send red text (
System.err.println
) to the console instead of blue text (
System.out.println
). To have the Debugger stop on an exception, you must open the class of the exception and add a breakpoint in its constructor. For example, to get the Debugger to stop when a NullPointer is thrown, open the class
java.lang.NullPointerException
and put a breakpoint in the first line. Application Developer does not let you add breakpoints on classes that have no source, and this is another reason why it's a good idea to get a JDK with full source and use this instead of using the default JRE that ships with Application Developer. For details on how to switch the JDK level of Application Developer, see the previous article in this series,
Comparing VisualAge for Java and WebSphere Studio Application Developer -- Part 1
.
Suspending running programs
VisualAge for Java
Both VisualAge for Java and the IBM Distributed Debugger let you suspend a running program. This is useful if the program is not at a breakpoint, but you want to break into it to inspect the threads.
Application Developer
In Application Developer, if a program is running and has not reached a breakpoint, you can select it in the list of process, select a thread, and suspend it using the ( ) toolbar button. This suspends the thread and shows the stack frame, from which you can select a method and continue the program using the step functions. Unlike VisualAge for Java, which lets you do many tasks to a debuggee JVM that is still running, in Application Developer you often must suspend the JVM to enable certain debugging functions, perform the tasks, and then resume execution.
Inspecting and displaying variables
VisualAge for Java
Another one of the crown jewels of VisualAge for Java is the ability to evaluate ad-hoc code directly inside the Debugger so you can look at and modify the state of a running program. A lot of this relied on the API provided by the proprietary JVM inside VisualAge for Java. Because Application Developer has to work with the JPDA API, you might expect that none of this functionality is available, but remarkably, Application Developer has an almost equal level of functionality for letting you examine and modify a program being debugged.
Application Developer
On the same notebook as the Inspector in the top right corner of the Debug perspective are three other views: Variables, Display, and Inspector. To show these, rather than using the code that Hello World displays on the console, change the HelloWorld class so that it create a frame and displays it. Add a breakpoint on the line that makes the frame visible, as shown below. Launch the program in Debug mode and let it stop at the breakpoint.
import java.awt.*;
public class HelloWorld {
public static void main(String[] args){
Frame frame = new Frame();
frame.setTitle("Hello World");
frame.setVisible(true);
}
} |
The Variables display shows the list of variables, including local method variables as well as instance variables. Use of this is very similar to the Inspector viewer used by the Scrapbook page described above. In addition to showing the contents of fields, under some circumstances, you can change them by right-clicking on a variable and selecting
Change Variable Value
. You can only change certain base types of variables, including the primitive types,
java.lang.String
, and a few other simple objects. If the menu option is grayed out then you cannot changed it. After selecting Change Variable Value, a text box opens in which you can enter a new value. If the value is incorrect, the text box will remain and no error message is shown.
Figure 15. Variables can have their values changed
If you change the contents of a variable, be aware that this is a direct change that bypasses any code that might exist in a set method. For example, if you change the title of a Frame as shown in Figure 15 above, this does not necessarily change the Frame's title as none of the code inside the
setTitle(String)
method has been executed.
The Display tab brings up a window in which you can enter ad-hoc code fragments. This is like the Scrapbook, but it has the advantage that the code is executed inside the running JVM directly against the selected object in the stack frame. To run code, type in the expression to evaluate, which will be shown in black, highlight it, and click the Display toolbar icon (
)or use the pop-up menu. After the code is executed, it will appear blue with the result shown next to the line.
Figure 16. Running ad-hoc code inside an executing process with the Display viewer
Figure 16 above shows that the code fragment 1 + 1 was entered, with the result that an int type of 2 was displayed. The display is run inside a method that has frame as a method variable, so the line
frame.getTitle()
actually executes against the context of the object selected in the stack frame. The code that is executed to see the result can call set methods and assign variables. For example, you can enter an expression that calls the
setTitle(String)
method to change the title, and then call the get method to see the result. Unlike the variables view, where changing a field's contents obviously bypasses the set method, the
setTitle(String)
method changes the actual title of the frame itself.
frame.setTitle("Hello England");: (No explicit return value)
frame.getTitle();: (java.lang.String) Hello England |
The expressions entered can be complex and many lines long, including loops. The full Java compiler is used to compile and evaluate the expression, rather than a parser that only accesses a simplified subset of the language, and the Display view is a very useful way to view, change, and understand the dynamics of a running program. In addition to using the Display option, you can use the Inspect toolbar icon ( ) , which opens an Inspector on the result by switching to the Inspector tab that shows the result of the expression.
A powerful feature that VisualAge for Java has, that is missing in Application Developer, is the ability to change source in the VisualAge for Java's proprietary JVM, and see this loaded directly into the running program. This "hot code replace" feature offers a productivity increase to developers who would get more iterations of of "code - run - fix - code" without having to stop and start the JVM. This functionality is planned for a future release of Application Developer.
Conclusion
This previous article in this series,
Comparing VisualAge for Java and WebSphere Studio Application Developer -- Part 1
, introduced Java programming in Application Developer
and showed you how to create, compile and run classes,
how to specify the use of any additional resources, and
how to change the JRE level. This article showed you
how to use the Scrapbook to run ad-hoc code fragments,
how to use the Local History to view the modification
history of a file and revert to a previous version, and
how to use the Debugger. The WebSphere Studio
Application Developer development team is the same team
that produced VisualAge for Java, and they have tried
hard to retain the best VisualAge for Java features
while at the same time adding new features and moving
to more open procedures for storing and managing files,
and running and debugging code. Application Developer
has other built-in productivity aids such as the
Profiler, and close interoperability with WebSphere
Application Server for coding, deploying, and testing
servlets, JSPs, and Java beans. In a future article I
hope to cover these topics and I welcome all feedback.
Top of page
About the author | | | Joe Winchester is a member of the WebSphere Tools Development team working on the Visual Editor for Java for the Software Solutions group in Hursley, United Kingdom. |
Rate this page
| |
