Speeding Up JDeveloper 10.1.3
By Sandra Muller on Nov 12, 2007
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.
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:
- 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),
- Start up JDeveloper and open your ViewController project,
- Put back the CONFIG_FILES parameter.
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:
- 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):
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 ###
pause Continue when JDeveloper has opened the ViewController project
copy /y backup_web.xml viewcontroller\webcontent\WEB-INF\web.xml
- If necessary, change the directory paths in the script to reflect your situation.
- 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.
- Make sure that the shortcut to start JDeveloper points to this batch file instead of to the JDeveloper executable.
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!