print Printer View e-mail E-mail this page Bookmark Bookmark
Oracle9i JDeveloper - Hands on Labs (IDE)

Exploring the Oracle9i JDeveloper Integrated Development Environment

This lesson introduces the JDeveloper IDE. This session covers the following tasks:

  • Check out the application files for this lesson from CVS into your project
  • Run the application from JDeveloper
  • Profile the application to identify tuning opportunities
  • Run CodeCoach on the application to identify and fix inefficient code
  • Run the debugger and learn how to control execution of code
  • Use the debugger to find and fix a memory leak
  • Refactor the code
  • Check the application files back into CVS from JDeveloper

Prerequisites

Please read the prerequisites and ensure that you have the proper environment to complete this lab.

The first step is to select the project used in this exercise.

To set the project context:

  1. Expand the Workspaces node in the System Navigator.
  2. Expand the performance.jws workspace in the System Navigator.
  3. Select the palindrome.jpr project in the System Navigator.

Checking Out Application Files From CVS

This first section guides you through the process of setting up Oracle9i JDeveloper to use the source code control tool CVS (Concurrent Versions System), then checking out the files required for this lesson. This involves:

  • enabling the chosen source code control in JDeveloper
  • creating a connection from JDeveloper to that tool
  • importing files into the tool to put them under source control

This is because JDeveloper supports not only CVS, but also seamlessly integrates with Oracle9i Software Configuration Manager (SCM) and contains built in support for ClearCase. You can also build your own custom support for any other source code control tool using the published SCM Framework API extension delivered with JDeveloper.

Note: SCM is available with JDeveloper for download from OTN (Oracle Technology Network) at . For more information on licensing, availability and a demonstration on the many benefits of using JDeveloper with SCM, please visit the SCM stand in the DEMOgrounds, located next to the JDeveloper stands.

In this lesson, we have already created the CVS connection and module in the CVS repository for you to use, so you just need to enable support for CVS in JDeveloper, then check out the files that make up our sample application. You can then complete the remaining sections below.

Enabling Support For CVS in JDeveloper

The first step is to enable (or 'switch on') support for using CVS in JDeveloper. In JDeveloper you can switch between different source code control tools as necessary, e.g. when migrating from a legacy tool to a new one such as Oracle9i SCM. Once you create a new connection to a source code control tool, JDeveloper remembers that connection, even if you disable then re-enable support for that tool later. You only lose your connection if you manually delete it.

  1. In the JDeveloper IDE, select Tools -> Preferences.
  2. Select Source Control.
  3. Select the Active System as Concurrent Versions System (CVS). Take all other defaults.
  4. Expand Source Control.
  5. Select CVS and review the global CVS options available. Take the defaults.



    Figure 1: Enabling support for using CVS in JDeveloper
  6. Click OK.

Checking Out a CVS Module

To check out the files that make up our sample application, you check out the actual CVS module that contains the files. We have already created a module called Explore_IDE which contains these files.

  1. Select the palindrome.jpr project in the System Navigator
  2. Select File -> Source Control -> Check Out Module... .
    This opens the CVS Check Out Wizard.
    • Step 1: Take the default CVS Connection Name and enter the Module Name as Explore_IDE

      Figure 2: Entering details of the module to check out

    • Step 2: Take all defaults
    • Step 3: Take all defaults

      Figure 3: Reviewing and setting Common Options as appropriate

    • Step 4: Take all defaults
  3. Finish the Wizard.
    If you have the Log Window open, select the CVS Client tab to see the progress of the check out. JDeveloper asks if you want to use your active project to open the checked out files in the Navigator, create a new project or to not open the files at this time. Take the default option, Open checked-out files in the active project.

    Figure 4: Opening the checked out files in the project you created earlier

In the JDeveloper System Navigator, the files that make up our sample application now display in your project in the System Navigator. They have an orange spot overlay icon to show they are up to date. Now complete the sections below.

Optimizing Java Applications with Oracle9i JDeveloper

The following section guides you through the process of profiling and CodeCoaching a Java application with Oracle9i JDeveloper. The Profilers allow you to monitor Java applications as they execute. CodeCoach scans your code and finds ways to improve its performance.

Running the Application

The application that you checked out in the previous section performs a basic test to check if a sentence is a palindrome (a palindrome is a sentence that can be read forwards or backwards). Once the project finishes running, the results will be displayed in the "Results" text item. The results will be used as a benchmark during the normal and profiling application runs. Keep in mind that whenever you profile, CodeCoach, debug, or run any process to observe the application, there is an overhead on execution time to make the observations. Therefore, it is important to compare benchmarks in the same context. In this case we will compare 2 different regular application benchmarks.

  1. Run the application (Run -> Run palindrome.jpr)
  2. Select benchmark.java as the default run target and click OK.
  3. In the running application press the Start button once.
    The application will execute for about two seconds and return a number to the Results field. Write down this number. This is your benchmark result. The number represents the time that it took to execute the code; a lower the number represents more performant code. The image below shows what you may see when running the palidrome application.

    Figure 5: Running the palidrome application

  4. Click on the close botton of the application or terminate the application (Run -> Terminate -> palidrome.jpr)

Profiling the application to identify tuning opportunities

This section focuses on tuning the application with the Execution Profiler. The execution profiler takes samples in fixed time intervals to see what classes and methods are being called. Data is recorded on the most active thread in the last interval. The results are computed and displayed in the summary window of the profiler.

  1. Run the Execution Profiler on palindrome.jpr (Run -> Execution Profile -> palidrome.jpr)

    2. Your application should now be running. To isolate the code executed when you click on the button, follow these steps:

  2. Click the Pause button in the profiler toolbar.
  3. Click the Clear button in the profiler toolbar.
  4. Click the Resume button in the profiler toolbar.
  5. Click on the application's Start button.
  6. Once the application returns a result, press the Snapshot button on the execution profiler toolbar to get a sample of the the application.

    Figure 6: Using the Snapshot button and sorting by Hit%

  7. In the background you can see the execution profiler window. Resize the window and the middle split for easy viewing.
  8. You can sort the results based on any column. Sort them based on the Hit% column. Figure 6 above shows where you can find the Hit% column.
  9. You can look at the methods that were executed. Double clicking on a method will take you to its source. The image below shows the full view of the Execution Profiler.
    The execution profiler shows the percent of time a method was active. The checkPalindrom method was the most active; therefore we should focus on optimizing this method. A small improvement in a frequently accessed method can result in big performance improvement.

    Figure 7: Full view of the Execution Profiler.

Running CodeCoach on the application to identify inefficient code

CodeCoach scans your code while you execute it and advises you on code inefficiencies and how to fix and improve the code. It is like having a Java guru helping you improve your code.

  1. Click on the close button of the Execution Profiler or terminate the profiler session (Run -> Terminate -> palidrom.jpr).
  2. Run CodeCoach on palindrome.jpr. (Run ->CodeCoach palindrome.jpr)
  3. Press the Start button on the application.
  4. Once the benchmark results are displayed in the application, close the application.
  5. Switch to the CodeCoach result window in the Log window.
    CodeCoach found a few things we can fix in the code as displayed in the image below.

    Figure 8: CodeCoach Results in the Log window.

Fixing the code and running the application again

  1. Double Click on the second recommendation "Method boolean checkPalindrom should be static".
    CodeCoach will jump to the line of code in the code editor.
  2. From the first advice in the Log window, let us apply an automatic fix if available.
    Context menu: Apply Fix to Source. The code is automatically fixed for you.
  3. Lets move to the second recommendation, "Too many expansions in class StringBuffer, content 29…"
  4. Now double click the second recommendation, "Too many expansions in class StringBuffer, content 29…".
    This line cannot be fixed automatically for us although it offers some advice on the initial size. But the fixed code is commented above it.
  5. Comment the current line.
  6. Uncomment the 2 lines above it.
  7. Repeat steps 4-6 for the next recommendation. Your code should look like the image below.

    8. Figure 9: Frame1.java after fixing code using CodeCoach

Setting CodeCoach Preferences

  1. Click on palindrome.jpr in the System Navigator
  2. Invoke Project Settings
    Context menu: Project Settings
  3. In the tree choose the CodeCoach node.
  4. You can define what types and level of advice you would like to receive.
  5. Press the Cancel button. The image below shows the CodeCoach Project Settings.

    Figure 10: CodeCoach Project Settings

Running The Tuned Project

  1. Run the application (Run -> Run palindrome.jpr)
  2. In the running application press the Start button once.
    Look at the results of the benchmark and compare them to the benchmark you had in the beginning of this section. You should have an improvement (around 10-20% faster) in your code execution.
  3. Close the application before proceeding to the next section.

Debugging and Fixing Memory Leaks with Oracle9i JDeveloper

The following section guides you through using the integrated Debugger in controlling the flow of executing code and finding and fixing a memory leak.

Controlling the Execution of code and Changing Variables

To control the flow of execution flow in a debug session, you must first set a break point. When you debug, the debugger will halt execution of the code when the breakpoint is encountered.

Starting a Debug Session

  1. Double-click on Frame1.java class in the System Navigator to open it in the Code Editor.
  2. Set the break point on line 42 by clicking in the margin area of the Code Editor with the mouse. See the image below.

    3. Figure 11: Setting a break point on JButton1_actionPerformed (line 40)

  3. Run the Debugger (Debug --> Debug palnindrome.jpr)
  4. Press the Start button on the application.
  5. After pressing the Start button, you should see execution halt at the break point. This is represented by a red arrow next to the break point as shown below.

    6. Figure 12: Execution halting at the break point

Control Code Execution

Control the flow of code execution by using the the buttons on the toolbar or through the Debug menu. The image below shows the various debug functions available to you on the toolbar.

Figure 13: Debugging toolbar and functions. From left to right: Debug, Set Start Debugging, Step Over, Step Into, Step Out, Step to End of Method, Pause, Terminate, and Garbage Collection

  1. Press Step Into button to enter into jButton1_actionPerformed method
  2. Once into method call, press Step Over a couple of times.
    This causes the debugger to execute the current line of code, but not step into the method call
  3. As a productive alternative, you can direct the debugger to run to a specific line. Place your cursor towards the end of the jButton1_actionPerformed method such as on line 77.
    Context Menu: Run to cursor
  4. While executing lines of code with 'step over' or 'run to cursor', you can view and modify the values of variables in the Smart Data window while the code is paused. Expand the this and jButton1 objects, respectively, in the Smart Data window by clicking on the nodes. Select the text object as shown in the image below.

    5. Figure 14: Drilling down the tree heirarchy of an object to see the types and values.

  5. Double-click on text object in the expanded node of JButton1. In the window that pops up, type in a New Value of "Get". Note that you can modify values of primitive types, addresses of existing objects, as well as change the address or string value of Strings. See the image below.

    6. Figure 15: Modifying the value of a String through the Smart Data Window.

  6. Press the OK button.
  7. Press the Resume debug button that allows the code to run until a breakpoint is reached or the pause button is pressed. Switch to the Palindrome application window and note that the button name has changed to "Get".
  8. To stop debugging, press the Terminate button.

Using the Debugger to Find and Fix Memory leaks

In this section we use the Integrated Debugger and introduce the Classes and Heap windows to help find and fix potential memory leaks.

Finding a Memory Leak

  1. Start the a debug session (Debug -> Debug palindrome.jpr)
  2. When the Watches window comes up in JDeveloper, place the mouse over window control and right-click to check and display the Classes window. The window control may be on the left side by default or as show below if you undock the window.
    Context Menu: Classes

    3. Figure 16: Invoking the Classes window during debugging

  3. Perform the same step above to check and display Heap window
    Context Menu: Heap

    4. Figure 17: Invoking the Heap window during debugging

  4. Switch to the running application and press Start.
    The execution of code should halt at the breakpoint.
  5. Step Into jButton1_actionPerformed with the Debug toolbar or the Debug menu as you practiced earlier.
  6. Step Over a couple of lines of code with the Debug toolbar or the Debug menu as you practiced earlier.
    Note that you should see class instances organized by package in the Classes window.
  7. Right-click in the Classes window.
    Context Menu: Settings
    The Preferences dialogue should appear with the Classes node selected.
  8. Click the check box of Count and Memory.
    The Count and Memory taken on instances are important metrics when debugging memory leaks.
    The image below shows the Preferences dialogue as it should look.

    9. Figure 18: Customizing the Classes window to show Count and Memory.

  9. Press OK.
  10. Back in the Classes window, look for checkPalidrom class. You may need to Step Over a couple lines of code to ensure that the instance was created.
  11. With the mouse click and drag checkPalidrom from the Classes window into the Heap window.
    This displays more information about the class instance. From the Heap window you can find the memory addresses of instances and see what other objects are holding a reference to that instance.
  12. Click on the checkPalidrom 1 file heap node to expand addresses referenced.
    The Heap window should look as the image below.

    13. Figure 19: The Heap window showing class instances and address of checkPalidrom.

  13. Right click on class instance in the Heap window. The class instance is the named item labelled with an address and of type checkPalindrom
    Context Menu: Show Reference Paths
    You will now see a new node in the Heap window that shows references to this instance from other objects. You can drill down into the references objects.
  14. Click on Step to End of Method button on the toolbar or from the Debug menu.
    This will bring you to the end of jButton1_actionPerformed method.
  15. Run the code again by clicking on Resume button on the toolbar or from the Debug menu.
  16. Click on the Start button in the Application
  17. Step Into jButton1_actionPerformed with the toolbar or from the Debug menu.
  18. Step Over a couple of lines of code with the toolbar or from the Debug menu.
    You will now see a second reference of checkPalidrom. If the references stay on the heap after jButton1_actionPerformed method is complete and garbage collection has occurred, then you may have a memory leak. The image below demonstrates what you may see.

    19. Figure 20: The Heap Window showing class instances and addresses of checkPalidrom.

  19. Step Out of jButton1_actionPerformed with the toolbar or from the Debug menu.
  20. Force garbage collection by clicking on the Garbage Collection button on the toolbar or from the Debug menu.
    Garbage collection removes from the heap any objects which are no longer being referenced. Now that method is complete, perhaps all references to checkPalidrom are gone.
  21. Note that one reference to the checkPalidrom instance remain and the Heap window still looks like the figure 19 above. While this does not indicate a definite memory leak, it does show a potential problem. Because checkPalidrom button is only being used in jButton1_actionPerformed method, there is no reason to keep creating new object instances during the program.
  22. Terminate debugging with the toolbar or from the Debug menu.

Fixing and Verifying the Memory Leak

  1. Go to the code editor and comment code at line 67
  2. Uncomment the line of code at line 69. The code no longer creates a new instance of checkPalindrom as a class instance and instead creates an instance with local scope to the JButton1_actionPerformed method.
    Your code should look as the image below.

    3. Figure 21: The code editor with corrected code.

  3. Use the code editor scroll bar to scroll up to the beginning of Frame1.java.
  4. Comment the checkPalindrom checkPalindrome = null code.

  5. Figure 22: The code editor with corrected code.

  6. Start the a debug session (Debug -> Debug palindrome.jpr).
  7. Click on the Start button on the application.
  8. Step Into jButton1_actionPerformed with the toolbar or from the Debug menu.
  9. Step Over a couple of lines of code with the toolbar or from the Debug menu.
    You should see one reference of checkPalidrom in the Heap window.
    We need to ensure that the reference does not remain after executing the jButton1_actionPerformed class and forcing garbage collection.
  10. Step Out of jButton1_actionPerformed with the toolbar or from the Debug menu.
  11. Force garbage collection by clicking on the Garbage Collection button on the toolbar or from the Debug menu.
  12. You should see that any reference of checkPalidrom in the Heap window has been removed.
    You have fixed and verified a potential memory leak that could have caused a problem later!
  13. To stop debugging, press the Terminate button.

Refactoring Code

Refactoring is the process of restructuring or reorganizing existing code for better maintenance, performance, or reusability. For example, with JDeveloper, you can easily rename a class or move a class to a new package without breaking code that depends on that class. This lab will guide you through selecting a block of code and moving it to a method call. This refactoring is called "Extract Method."

  1. If it's not already on top, go to the Code Editor for Frame1.java.
  2. In the Structure window, double-click on jButton1_actionPerformed(ActionEvent) to navigate to that method in the Code editor.
  3. Select the region of text starting with the line  for(int k = 0; k<11 ; k++) through to and including the_time=the_time/10;
  4. Your Code editor selection should look like the following:

    ImageG.jpg (37378 bytes)

    Figure 23: Selection of code in the Code editor

  5. Select Tools > Refactor > Extract Method from the main menu.
  6. In the Extract Method dialog, enter calcTime as the name for the new method.
  7. Click OK.

In place of the selected code, you will now see a call to your calcTime method. The calcTime method itself contains the code that you had selected. Note that any required variables are passed as arguments to the new method.

Comparing Code Before and After Refactoring

You can use CVS to compare your refactored code to its previous version, which gives you an opportunity to see a summary of the changes made during refactoring. You can compare a file with its previous version or another version of that as appropriate. You do not have to check your code back into CVS first, as CVS uses the latest copy saved in your local directory (specified when you checked out the files at the start of this lesson).

  1. Select the node for Frame1.java in the System Navigator.
  2. Context Menu: Source Control -> Compare with Previous Version.
    JDeveloper displays a window that summarises the differences between the two files. The original values in the previous version display first, marked with <. The differences are separated by ---. The new values in the current version display below ---, marked with >. Your screen will look close to but may vary from the image below.

    ImageE.jpg (71807 bytes)

    Figure 24: Comparing files with CVS to see changes made through refactoring

  3. Close the Compare Results Window, ready to check your files back into the CVS repository.

Check Application Files Back Into CVS

To complete this lesson, check your finished files that make up our sample application back into CVS to ensure your work is back under source control and your changes are not lost. In CVS, checking files in is referred to as committing your changes back to the CVS repository.

Note: Any changes you make are to local copies of your files, so these changes are only updated to the CVS repository when you commit them. This also means that, for example, when you create a new file and add it to CVS, the file is not yet under source control. Only committing that file updates the CVS repository.

  1. Select your project files in the System Navigator.
  2. Context Menu: Source Control -> Commit.
  3. Select Force Commit on the Commit Changes tab to create a new version of the file even if you have not changed it.
  4. Click OK to commit your changes.

    When the commit is complete, the overlay icons that display for the files in the System Navigator change back to an 'orange spot' to show they are up to date.

Figure 25: Checking your finished files back into CVS

Congratulations! You've finished this lesson on exploring the Oracle9i JDeveloper Integrated Development Environment.
Now why not try one of the other lessons available?
E-mail this page
Printer View Printer View
Oracle Is The Information Company About Oracle | Oracle RSS Feeds | Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Privacy