No doubt there’s countless tweaks to correct and improve the responsiveness of applications deployed on all the application servers on the market. To make matters worse, the tweaks are frequently vendor specific. It seems as software approaches feature richness, so does the complexity it’s configuration. My recent experiences with the Weblogic application server certainly suggest this to be the case.

Occasionally, interacting with the application I’m currently developing, I’d notice the application server blow up with an unusual stack trace originating deep within the internals of struts. The cause - a ClassCastException. Upon investigation of the source (via IntelliJ’s JAD plug-in), it was blantently obvious the cause was totally out of my programming control. The back of my mind hinted that the cause was a configuration issue – a hunch I should have followed through with immediately.

For a full day I dismissed the hunch and followed logic - all other developers on the project, some 15 or so, rarely experienced this problem at best, and if it did occur a quick fix was a re-start away. So it must be some inconsistency in my environment, right? Wrong!
What followed was pure frustration….a Weblogic re-install, 3 JDK changes, at least 10 JVM memory tweaks, numerous tempory folder deletions, approximately 40 re-starts and environment variable and classpath double-checks.

I even cried for help, only for a monalogue to ensue.

So I ended up following that hunch and stumbled across the solution (see link above).

In the tried and true world of MVC Type 2 application development, with a single, unchanging, Controlling Servlet, does it make sense to reload Servlets by default? If you think it has anything to do with JSP reloading, think again, there’s a seperate configuation option for this too.

On the off chance that you still think it’s not a bad idea to reload a Controlling Servlet, consider that reloading the Servlet, such as the struts ActionServlet, can cause all the resources it relies on to be reloaded. In the land of struts these resources include all it’s property files (config, validation, tiles, etc.) - a considerable performance hit.

Perhaps just like the Matrix trilogy, serlvet reloading is better left out?

For Mike and in memory of good times at ThoughtWorks.

An interface cannot completely dictate an implementation. It’s impossible to stipulate an interface to the point where there is no ambiguity and consequently no opportunity for implementors to produce different somewhat different behaviours. For instance, an interface cannot declare that methods should not accept or return null values.

The set of contractural interfaces that is the JVM specification is certainly no exception.

In recent times I’ve witness nigh-on baffling differences in vendor implementations of the JVM specification.

For example, be cautious with final instance variables. Some implemenations may not make them as final as you’d like.

I was recently involved in a project that employed the persistence services of Hibernate. Originally the team believed we needed domain objects to comply with the bean specification in order for them to be persisted through Hibernate. The consequences were invasive, domain objects that were once clear in purpose, were being polluted by getters, setters and no-arg constructors. Method explosion and confusion reigned.

Then an enlightened team member shed light on the issue – ‘….why not configure hibernate to use direct field access….’. Great! We story carded it and eventually started re-configuring Hibernate and rolling back those invasive domain changes. The changes were completed, tested, and checked in. Shortly there-after cruise control complained – a test stack trace showed evidence of code attempting to modify a final variable.

How could it be?

Once rightfully final instance variables were now being modified post object creation by Hibernate – on developer builds the JVM implementation happened to support modifying final instance variables through reflection, whereas the cruise control JVM did not. Amazing!

In very recent times I’ve also witnessed JVM implementations yield, somewhat less surprisingly, unpredictable behaviour when out of memory. It seems some implemenations don’t always complain about being out of memory, rather they continually throw ClassCastExceptions – suggesting some area of memory has been corrupted.

I’ve also witnessed very different class loading behaviour in JVM’s within application server containers, some being completely unable to locate classes that others are quite capable of loading.

The lesson learned: be clear on the JVM implementation used in production and develop and test against the same instance, or in the absence of a sole concrete instance, test against a variety of candidate implemenations.