JHeadstart Blog

One of the new features in JDeveloper 10.1.3 that I will be using a lot, is the built-in Java code formatter. In JDeveloper 10.1.2 I used the Jalopy extension, but in 10.1.3 it's a lot easier.

In the Preferences you can specify your favorite code style. By default it is set to "Java Code Conventions".



If you prefer the classic style, you can simply switch to "JDeveloper Classic":



To apply the Code Style to your Java code, right-click in the Source editor and choose Reformat.

Didier's post conn, ife, sop & try inspired me to work out an idea I had for some time: create a code template for declaring a log4j member variable in a class. Log4j is pre-configured in every JHeadstart generated application, and is quite easy to use. The only cumbersome thing is having to add a log member variable to each class where you want to log something.

You have to add something like this:

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
...
  // used for logging on 6 levels: trace, debug, info, warn, error, fatal
private static Log log = LogFactory.getLog(MyClass.class);

It is ideal for turning into a JDeveloper code template! A code template can add both imports and code (already available in JDeveloper 10.1.2), and even replace certain variables like class name (new in JDeveloper 10.1.3).

Step by step, analogous to Frank Nimphius's (no longer online) post "JDeveloper: How to automatically add the class name and creation date to a Java file"

1. Tools --> Preferences
2. Code Editor --> Code Templates
3. Press the Add button to create a new template
4. Name it log
5. Under the Code tab, put (non-indented):
   // used for logging on 6 levels: trace, debug, info, warn, error, fatal
   private static Log log = LogFactory.getLog($class$.class);
   
6. Under the Imports tab, put (without import keywords and semicolons):
   org.apache.commons.logging.Log
   org.apache.commons.logging.LogFactory
   
7. Under the Variables tab, change the Type of the class variable to curClass and uncheck the Editable checkbox (if you leave the variable editable, you must confirm the variable using Tab or Enter each time you use the template, otherwise the template won't work in a second file).
   In JDeveloper 10.1.2, instead of putting a variable in the code, leave the cursor at the position of the variable when you save the code template.
   
8. Confirm and close the preference dialog

In the code editor of the opened file type

log and press ctrl+enter

This will have the following effect (possibly after restarting JDeveloper):

"YourOwnClassName" was automatically filled in. If you have unchecked Editable (recommended) when defining the Code Template, then the value is not highlighted and you don't have to confirm the value using Tab or Enter.

The next step of course is to create a code template for the code that actually produces a log message. We might as well incorporate a best practice for the performance of log4j: don't do any expensive construction of a log message unless you know the relevant log level is enabled.

if (log.isDebugEnabled())
{
   log.debug(... expensive calculation of result...);
}

So let's create a code template called debug, that adds the following code (no imports or variable properties):

if (log.isDebugEnabled())
{
   log.debug($myMessage$);
}

Of course, this time the $myMessage$ variable must be editable. In the code editor if you type debug and press ctrl+enter, the if-statement is added to your class and "myMessage" is highlighted, ready for typing over. Confirm the new message value using Tab or Enter. In a similar way you can define code templates called trace, info, warn, error and fatal!

Alberto wrote in to tell us that he downloaded the JHeadstart 10.1.2 evaluation copy from the JHeadstart Product Center, and asked where to download JDeveloper 10.1.2 for which JHeadstart 10.1.2 is certified. The answer is: from the JDeveloper Archives.

I'm working on a large development project where we are building a web application of over 100 JSF / ADF Faces pages, hundreds of ADF Business Components, and many accompanying Java files, Faces Config files, etc. We have organised it into one Model and one ViewController project, and find that using Working Sets in JDeveloper 10.1.3 to organize the subsystems of the application is a great help.

A working set allows you to define a set of files (a subset of project source path contents) that you want to work with. For large projects, you may want to work with a small subset of the source files (for example, all the files in a given package, plus a few others). Typically, you would perform the following actions scoped to the working set:

• Make
• Build/rebuild
• Search
• Find usages
  

When you have defined some useful working sets, of course you want to exchange them with your fellow development team members. Here's how to do that:

1. Open [JDevHome]/jdev/system/oracle.ide.10.1.3.36.73/projects/index.xml and finding the entry for the JDeveloper project on which you defined the working sets.
2. The entry in index.xml references a working set definition file in the [JDevHome]/jdev/system/oracle.ide.10.1.3.36.73/projects folder.
3. Possibly rename this (project-specific) working set definition file to a more meaningful name.
4. Share this working set definition file with your team, and tell everyone to change the project entry in their own [JDevHome]/jdev/system/oracle.ide.10.1.3.36.73/projects/index.xml to let it point to the new file. (And don't forget to do that yourself as well, if you changed the name ;-)
   

In this post I have collected various hints and tips to improve the speed of JDeveloper 10.1.3.x, especially when using multiple faces-config.xml files in JSF (like JHeadstart does).

Some great tips about improving the JDeveloper performance can be found in Shay Shmeltzer's blog post Is your JDeveloper Slow? - It shouldn't be!.

• Shay's tip #1 is get a better machine. My recommendation is: at least 2 GB internal memory.
  
• Shay's tip #4 mentions Gerard Davison's KeepResident. It's worth noting that this JDeveloper extension (for Windows only) can be installed in JDeveloper using Help - Check For Updates - Partners and Open Source Extensions Update Center.
• Shay's tip #6 mentions that you can disable JDeveloper extensions you don't need. Brian Duff's post Seriously customizing JDeveloper he explains how you can even disable extensions that are not visible in the JDeveloper preferences, but are visible in Help - About.
• In the comments of Shay's post, Jon Wetherbee reports: Another way to avoid delays when switching back to JDev from another
  app is to turn off the automatic file scan that is enabled by default. To do this, go to: Tools | Preferences | Environment and de-select: 'Automatically Reload Externally Modified Files' and/or: 'Verify Project Contents Automatically on Restart'.
  
• To add a tip of my own: configure the JDeveloper Preferences to open files in the Source editor
  by default (Tools | Preferences | File Types, tab Default Editors). The benefit is that you save the time of opening the Design editor if you
  are not going to need it for that particular file. Not only for the
  jspx files, but also for the faces-config files. If a faces-config file
  does not contain any navigation rules but only managed beans, the visual design is not useful anyway.

To check if your efforts were successful in minimizing the memory usage of JDeveloper, you can turn on the memory monitor in JDeveloper, as described in Brian Duff's post "Useful power preferences for JDeveloper and SQL Developer". Unfortunately this post is not online anymore, but the instructions are: find the ide.properties file in your JDeveloper user directory (system10.1.3.xxx), in that file find the MemoryMonitor property, and change false to true. I often found that when the memory monitor displays a high value, restarting JDeveloper helps... The widget is displayed in the lower right corner of JDeveloper, and looks like this:


Speeding up JDeveloper when using multiple JSF faces-config files

In his blog post Using multiple faces-config.xml files in JSF, Chris Muir explains how you can split up a large faces-config.xml file into multiple smaller files, that together act as a large faces-config file. This technique is used extensively by JHeadstart: for each group (data collection) in your application definition you get a separate faces-config file with the managed beans for that group. The original faces-config.xml is only used for navigation cases and some application level JSF settings. This has big advantages like keeping each configuration file small, allowing easier Version Control, etc.

However, it also has a disadvantage: it considerably slows down the time needed for opening the ViewController project (and if that project is opened by default, the start-up time of JDeveloper). This has been logged as JDeveloper bug 5706124 (see MetaLink for details about the bug, and see this JHeadstart forum thread for a discussion about it).

Luckily, there is a workaround:

1. Temporarily remove the javax.faces.CONFIG_FILES parameter from your web.xml file (that is where all the faces-config file names are listed, see section 11.2.3 of the ADF Developer's Guide),
   
2. Start up JDeveloper and open your ViewController project,
   
3. Put back the CONFIG_FILES parameter.
   

After that JDeveloper runs just as fast as with only one faces-config file.

While this is good news, it is a nuisance to have to change web.xml every time you start JDeveloper (and if you forget you have this extremely slow startup), and to change it back afterwards (otherwise your application won't run correctly). So I was very happy when my colleague Marcel came up with a way to automate this:

1. Create a batch script that backs up web.xml, replaces it by a dummy web.xml, starts JDeveloper, and after the ViewController project is opened puts the original web.xml back. On Windows, such a script could look like this (I'm sure that on Linux something similar is possible):
   @echo off
   rem ### Backup web.xml ###
   copy /y viewcontroller\webcontent\WEB-INF\web.xml backup_web.xml
   copy /y dummy_web.xml viewcontroller\webcontent\WEB-INF\web.xml
   rem ### Start JDeveloper ###
   if not defined JDEV_HOME set JDEV_HOME=C:\jdev1013
   start /min /d%JDEV_HOME% %JDEV_HOME%\jdev\bin\jdev.exe
   rem ### Restore web.xml ###
   @echo on
   pause Continue when JDeveloper has opened the ViewController project
   copy /y backup_web.xml viewcontroller\webcontent\WEB-INF\web.xml
   del backup_web.xml
   
2. If necessary, change the directory paths in the script to reflect your situation.
   
3. Put this script in the root folder of your project, together with a file dummy_web.xml in which the parameter javax.faces.CONFIG_FILES is removed.
4. Make sure that the shortcut to start JDeveloper points to this batch file instead of to the JDeveloper executable.

Then, when you start JDeveloper, you wil see this:

Keep the DOS box open until your ViewController project is opened, then go back to the DOS box and press Enter to get the original web.xml back.

That solved my JDeveloper speed problems!

In JDeveloper 11g, the Working Sets feature has improved: instead of having to choose a Working Set for each project, you can now do it for the whole Application (and get a subset of each project in the application). And even better, you can do it in the Application Navigator as opposed to only in the System Navigator (the System Navigator does not exist anymore in 11g).

A working set allows you to define a set of files (a subset of project source path contents) that you want to work with. For large projects, you may want to work with a small subset of the source files (for example, all the files in a given package, plus a few others). Typically, you would perform the following actions scoped to the working set:

• Navigate
• Make
• Build/rebuild
• Search
• Find usages
• Search in Files

When you have defined some useful working sets, you may want to exchange them with your fellow development team members. 2 years ago I blogged about how to share JDeveloper 10.1.3 Working Sets with your team, and here is how to do that in JDeveloper 11.

• Open [JDevWLSHome]/jdeveloper/system/system11.1.1.0.31.51.56/o.ide/projects folder and find the .jws file starting with the name of your JDeveloper Application, for example Base08345889adfc01e0ffd7dd7bfa1c6234.jws for an application called Base.
• Open this file, and you will see XML code starting with <hash n="working-sets"> that specifies your working sets.

Now you can either copy this piece of xml code, e-mail it to your colleagues and they can paste it in their application working sets file, or you can make sure that you all use the same application working sets file that is available from a common source. The latter is explained below.

• Copy (and possibly rename) this application working sets file to a location where it can be maintained centrally, but everyone has a local copy (for example in your Subversion repository).
• Tell everyone to change the relevant entry in their own [JDevWLSHome]/jdeveloper/system/system11.1.1.0.31.51.56/o.ide/projects/index2.xml to let it point to the new file. (And don't forget to do that yourself as well ;-)

Everyone will only have to make a change to point to the shared file, and if one person updates the working sets all others will be able to get the changes, if they have JDeveloper closed while updating their local copy.

Today I ran into a problem where I got a NullPointerException in one of the EL-expressions called when processing an ADF Model page definition. The stack trace did not tell me which EL-expression caused the problem, and it could be one of the many expressions used in the page definition itself, or in one of the many JSF managed beans referenced from the page definition. I could set a breakpoint in the ADF source code where the expression was evaluated, but that breakpoint fired about a hundred times for that single page.

The solution I found can be applied to any situation where you cannot easily influence the source code but still want to write some logging about the values of Java variables and method arguments. You can apply it to frameworks for which you have read-only access to the source code, like ADF and JHeadstart.

I didn't realize at first that JDeveloper 10.1.3 and JDeveloper 11 have an interesting debug feature called BreakPoint Actions. You can set breakpoints and configure them in such a way that they don't halt execution, but only write something to the log. That something can be the value of a Java variable or some other Java expression. So I let it write to the log which EL-expressions it was parsing, and then I could easily check which expression was written just before the NullPointerException.

Here is how you can add your own debug message (with values of class variables) to a (framework) class without having to modify any Java code:

• You go to the source code of the class you want to add a debug message to. In case of ADF, you can get the source code by logging a Metalink Service Request for the Oracle JDeveloper product, see this forum discussion. How to install it is described in the ADF Developer's Guide, section 24.5. In case of JHeadstart, the source code is automatically installed as soon as you have applied JHeadstart in your project.
• In your JDeveloper project, go to that source code using for example the menu option Navigate to Java Class, keyboard shortcut Ctrl+Minus.
• Set a breakpoint on a certain line by clicking the line gutter, which causes a red bullet to appear. For example, I chose the topmost line in my NPE stack trace of which I had the source.
  
• Then right-click the red bullet and choose Edit Breakpoint.
  
• In the Edit Breakpoint dialog, click on the Actions tab, uncheck "Halt Execution" and fill in the desired variable name in Expression. In my example, by coincidence the variable I wanted to display was called expression, so in the screen shot you see Expression: expression.
  
• Then run your project in Debug mode, and reproduce the problem. In my case the log showed this:
  
  

It turned out I had made a stupid typing error ... but at least now I knew which one.