684 WebSphere Studio Application Developer Version 5 Programming Guide Object references The Object References view shows patterns of references in varying detail, both to and from a set of objects (if such references exist). To display information, this view requires profiling data that contains object reference information. You can use this view to locate objects that still have references to them, study data structures, and find memory leaks. An example of an Object References view is shown in Figure 20-28. Figure 20-28 Object References view This view displays the following information: Base set of objects—Appears in the gray area on the left. Each new object resides in this area once, but its instances also reside elsewhere. The view shows references to and from this base set of objects. You can select the base set of objects from the Display field. Objects—Represented by squares, each colored uniquely by class. Squares come in two forms: – A single square denotes a single instance – Twin squares represent multiple instances Class objects—Represented by diamonds. Note: To interpret this view, you need to have a good understanding of how objects are allocated and referenced in your application and how Java handles object referencing. Chapter 20. Profiling applications 685 References between instances—Denoted by black arrows between the instances. An arrow points to the objects being referenced. Arrows point right to left. Repetition of an object—Represented by a blue, upward-pointing arrow. Click this arrow to display a long, blue arrow that leads to another place where the same object is displayed. Old objects—Denoted by a red font color for the number of objects and the class name, both of which appear to the right of each instance. New-generation objects—Denoted by a black font color for the number of objects and the class name, both of which appear to the right of each instance. Some things to be aware of Here are some further considerations: Because communications with the IBM Agent Controller is done via TCP/IP sockets, firewalls may block the communication. Views have to be refreshed to show the latest data by using Refresh Views from the context menu in any profiling view, or by clicking in the Profile Monitor view. You cannot use profiling and debugging at the same time. Summary In this chapter, we covered the profiling tools of Application Developer and included examples of the different statistics that are accumulated. Note: Old objects are those created prior to a certain point during the profiling session. You can specify that point as you create a dump of the object references using the Collect Object References icon in the toolbar. Objects that are created after that point in time are referred to as New-generation objects. 686 WebSphere Studio Application Developer Version 5 Programming Guide © Copyright IBM Corp. 2003. All rights reserved. 687 Part 5 Team programming Part 5 covers how to use Application Developer in a team development environment. We cover team development with both Common Versions System (CVS) and Rational ClearCase LT. Part 5 688 WebSphere Studio Application Developer Version 5 Programming Guide © Copyright IBM Corp. 2003. All rights reserved. 689 Chapter 21. Version control Application Developer is a file based integrated development environment (IDE). It operates on a workspace where all of the data relative to the environment options and to the loaded projects is stored. This workspace has a root directory and is composed of regular files. You may have as many workspaces as you want, but you can only work with one at a time per each IDE instance. A local history of resource changes is maintained within the workspace. This allows developers to compare and replace resources with earlier editions. In most cases, though, developers do not work alone, but rather as part of a team. Application Developer’s open architecture allows software configuration management (SCM) systems to be plugged-in to support such kinds of development effort. This chapter includes the following topics: Workspace activities in standalone development Team development and terminology SCM integration with Application Developer 21 690 WebSphere Studio Application Developer Version 5 Programming Guide Local history In Application Developer, a local history of changes is maintained when you create or modify and save a file. This allows you to compare the current file edition to a previous one, replace the file with a previous edition, or even restore a deleted file. Each edition in the local history is identified by the date and time the file was saved. Comparing files To compare the current edition of a file with a different one, choose Compare With -> Local History from the file’s context menu. You can select different local editions and compare them against the currently loaded edition (Figure 21-1). Figure 21-1 Comparing the TransRecordBean class with its local history There are three panels in the Compare with Local History window: The top left panel lists all the available editions in the local history for the selected file. These editions are grouped by the save date. Note: Only files have local histories. Projects and folders do not. The local history is independent of the team development environment and the shared team repository. Chapter 21. Version control 691 The top right panel lets you select what Java structure you want to compare. The default is to compare the whole file, but if you had more than one class in the compilation unit, you could want to limit the comparison to just on class by selecting it in the list. The bottom panel shows the current edition on the left and the selected edition on the right. Graphical cues indicate where the code has changed and what kind of change occurred. You can see in Figure 21-1, for instance, that the setAccount method that exists in the current edition did not exist in the previous edition. There are also two arrow buttons that let you scroll through the individual changes. Replacing files A similar dialog (Figure 21-2) lets you replace the loaded edition of a file for another one. To do that, select Replace With -> Local History from the file’s context menu. Figure 21-2 Replacing the loaded edition with another one from the local history This time around, the dialog presents you with just two panels. It would make little sense to show the Java Structure panel because a replace would affect the whole compilation unit. 692 WebSphere Studio Application Developer Version 5 Programming Guide Restoring deleted files To restore a deleted file, select the container where the file used to be (like a folder or a Java package) and select Restore From Local History from its context menu. The dialog in Figure 21-3 is displayed: Figure 21-3 Restoring a deleted file from the local history Preferences Finally, you can set how Application Developer manages the local history by selecting Window -> Preferences and then selecting Workbench -> Local History (Figure 21-4). Figure 21-4 Setting the local history preferences Chapter 21. Version control 693 Team development The Eclipse platform is based on the concept of letting users create and edit resources that are stored in the file system. Unfortunately, network file systems do not offer the necessary flexibility and set of services to support team development. If you project calls for more than just one person, chances are that you are going to need a software configuration management (SCM) system, or at least a subset of it. The U.S Department of Defense, in its standard on software development (DOD-STD-2167A), defines SCM as follows: Software Configuration Management is the discipline of identifying the configuration of software systems at discrete points in time for the purpose of controlling changes and maintaining traceability of changes throughout the software life cycle. These tools must support a set of related and sometimes overlapping functional areas, among which are: Version control—This is the ability to store and retrieve snapshots of the state of components at any given point in time. The mechanism usually employed to store these versions is called forward-delta versioning, that enables version branching with a minimum of storage wasted. Problem tracking—Problem tracking usually works through two mechanisms: defects and features. Defects track the life cycle of a problem with any of the software components from identification all the way through to final resolution. Features are additional requirements that must be implemented in the system. Change management—It is the process of identifying, tracking, and controlling changes to software components. Change management commonly provides an audit track that identifies which files have gone through what changes, when these changes occurred, who modified the files, and why. A defect or feature may result in the modification of hundreds of files across more than one product, including documentation and test cases. Change management, through the mechanism of tracks, should produce and keep records of each file modified in each separate product as related to the particular defect or feature. When you are ready to include the changes for the defect in the release and build the release, you should only need to specify the track number and all the changes would be committed to the repository and included in the release. Build and deployment management—Gives you the ability to build and deploy your software product in a repeatable manner. . objects. 686 WebSphere Studio Application Developer Version 5 Programming Guide © Copyright IBM Corp. 2003. All rights reserved. 687 Part 5 Team programming Part 5 covers how to use Application Developer. terminology SCM integration with Application Developer 21 690 WebSphere Studio Application Developer Version 5 Programming Guide Local history In Application Developer, a local history of changes. team development with both Common Versions System (CVS) and Rational ClearCase LT. Part 5 688 WebSphere Studio Application Developer Version 5 Programming Guide © Copyright IBM Corp. 2003. All