Run, Forrest, Run!

So, you started developing in JDeveloper. You deployed your ADF application. You redeployed your improved application. You also waited. Waited a lot... Is it really that slow?

I have a laptop (actually I have a new laptop, since I refused to run JDeveloper on the old one), it has Windows 7 64bit, Intel i7 CPU, 16Gb RAM and two raid-0 7200rpm disks (SSD would be better, but hey...). It also has a power supply the size of my desk. My point is; the machine is by no means slow.

Quite frankly, I was stunned at the time it took to redeploy ADF applications using the integrated Weblogic server. Turns out, there was a "good" reason for this, as I ran head long into a bug (that has been there for some time I gather).

Do NOT Use the Default Connection Type
When creating a new Application Module in JDeveloper, you will have two default configurations. Both of which uses Connection Type JDBC Datasource. The datasource name will look something like this: java:comp/env/jdbc/>yourconnectionname<

Change the Connection Type to JDBC URL and you will see a world of difference when redeploying. This applies to both 11gR1 and R2. Andrejus Baranovskis has documented the work-around in this blog post.

When developing for a production application, you will most likely use a named datasource using jndi lookup, and also define it on your local Weblogic server, and this slow undeploy issue will not be a problem.

Give it What it Needs
On windows, you are by default running 32bit java on limited resources. Speed things up by switching to 64bit java and increasing the available memory for both JDeveloper and the integrated Weblogic. Spyros Doulgeridis has a detailed explanation on how to do this in this blog post.

Looks a bit difficult, especially if you are not familiar with the config files involved, but it is well worth the effort. I have not noticed any differences in behavior using 64bit java as opposed to the default jdk, but it is worth keeping your eyes open to this.

I like to keep my laptops JAVA_HOME separate from any server software installed, so I did not update JAVA_HOME according to the blog post. As a result I encountered  "Could not reserve enough space for object heap" on wls startup. This was due to the fact that the integrated wls still used the original 32bit java. Changing this line in setDomainEnv.cmd from:
set JAVA_HOME=%JAVA_HOME%
to:
set JAVA_HOME=C:\Software\Java\jdk1.6.0_25
solved the issue.

To Refresh, or Not Refresh
But do you really have to redeploy all the time? At least in 11.1.2 there are a number of changes you can do to an application without the need for redeploy. A simple refresh of the browser will suffice.

There is a trick to this (of course), Jobinesh has written about it in this blog post. You have to rebuild your projects for the changes  to propagate. I find this to be true. Sometimes. In my experience issues with refresh are especially evident when dealing with sessions and security. Some changes will work fine, others will not. Take notes as to when you have to redeploy, and when a simple rebuild/refresh will suffice. (As you can see from my lacking elaboration, I clearly did not take notes...)

It Leaks
Incidentally, you do not want to deploy too often. Repeated redeployments will eventually lead to health critical and danger of OutOfMemoryError messages from your integrated weblogic server. It will also become very unresponsive to deal with. A restart of the integrated wls will solve the problem.

It is the little things that is not written on the label that really gets to you. Well, now you know :-)

To be continued...