Sounds cool, doesn’t it? Yet a bit academic – I agree. So why this title? It is as precise as it gets. And it’s less 140 chars, so I can even tweet it. Yet no worries, I’ll enjoy dissecting the headline for. There are a number of important messages. To make it more readable I will split it into three parts.

• So let’s get to the topic right away (which by the way is precompilation).
• To prove it makes a real difference, I will show in part II how you can measure the effect of precompilation since quite often people fail to do so.
• Later in the cool part, part III, we look at some exciting bells and whistles for web applications (Twitter Bootstrap framework).

Precompilation

Why would you precompile your application?

Precompilation isn’t really necessary to make an application work correctly. WebLogic will compile necessary artifacts when they are needed. For example a JSP page which is not precompiled will be compiled at the time it is accessed.

Deploying an application without precompilation forces you to use lame excuses such as “It’s a bit slow right now, because it is running for the first time after deployment“. I am sure you don’t want to be remembered for lame comments. Running your applications without precompilation costs you time. And time is expensive.

What is the difference between precompilation and compilation?

Well, every Java class has to be compiled before it is executed by the JVM. The .java file is converted into a .class file. Other stuff, such as a JSP page could be deployed as is. It will then be compiled by WebLogic.

What can be precompiled?

If you don’t want to think about it, simply precompile your .war or .ear files. JSPs, web service artefacts and EJBs can be precompiled. Let’s look at the JSPs in more detail:

The JSP is converted into a servlet Java file which in turn is compiled into a .class file.

Precompilation after deployment?

You can request WebLogic to precompile your application right after deployment. To do so set the XML element <precompile>true</precompile> in the weblogic.xml deployment descriptor.

Many projects seem to use this solution, but it is certainly not the best idea. There are at least two reasons why I am not a big fan of this solution.

1.) Using the setting mentioned above precompilation happens right after deployment. This is the time when you want to show off your application. However, the application is not precompiled yet. Even worse, during precompilation system resources are used and the application is slowed down.

2.) When setting the <precompile> element, the application is precompiled after redeployment and after server restart. Do you really want your application to be precompiled after every server start?

Precompilation before deployment!

I recommend to precompile before you deploy. If building your application takes a long time, precompiling will make the process even longer. Then consider to have two different build targets: One for quickly testing your application without precompile, another one with precompile for load testing and deploying your application in an production environment.

After setting an environment suitable for running WebLogic commands from the command-line, all artifacts for an application surf.ear can be precompiled as follows:

java weblogic.appc surf.ear

Note, that the former JSP precompiler weblogic.jspc is deprecated.

Sometimes JSP fragments are included within a JSP yet these JSP fragments are not syntactically correct JSPs. Now if the fragments have a .jsp extension the precompiler will try to compile them and fail, therefore you should set the tag <precompile-continue>. Then precompilation will continue on errors.

Also there are faster compilers than javac. You can specify a different compiler with the switch -compiler.

Precompilation with Maven

If you use Maven to manage yours builds, Maven can call the application compiler appc for you when building you application. So everything in the paragraph above applies to building your application with Maven as well.

Possible Problems

If you precompile the deployment module before deploying, the classes will be added to the module and you should never see WebLogic compiling them again.

In case you are having problems with reoccurring precompilation, check the following issues:

• Verify that the JDK version used to precompile is exactly the same as the JDK used to run WebLogic.
• Make sure the time on the machine used for precompilation is synchronized with the machine where the application is deployed.

Conclusion

Precompilation isn’t a new topic, however it is often done the wrong way or it is not done at all.

Always precompile your deployments unless you manually create a quick distribution for testing during development. Don’t precompile using the <precompile> deployment descriptor after server start.

Add the precompile step into your continuous build process.

Additional Links:

WebLogic 12c deployment descriptor documentation for precompile:

http://docs.oracle.com/cd/E24329_01/web.1211/e21049/weblogic_xml.htm

Using WebLogic Maven plugin:

http://docs.oracle.com/cd/E24329_01/web.1211/e24368/maven.htm

WebLogic Maven appc goal:

http://docs.oracle.com/cd/E24329_01/web.1211/e24368/maven.htm#CHEBEHEH