Speeding Up JDeveloper 10.1.3

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:
JDeveloper Memory Monitor widget:

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:
JDeveloper Startup Batch Window:
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!


Thank you for the tips. great job.

Posted by Webmaster on July 13, 2008 at 07:42 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Java EE Consultants - JHeadstart, ADF, JSF


« July 2016