I have this friend....

I have this friend who works on a java ee application (j2ee) application started in the early 2000's. Currently they add a feature here and there, but have a large codebase. Over the years the team has shrunk by 70%.

[Yes, the "i have this friend is". It's me, attempting to humorously inject teenage high-school counselor shame into the mix]

Java, Vintage 2002

The application uses EJB 2.1, struts 1.x, DAO's etc with straight jdbc calls (mixture of stored procedures and prepared statements). No ORM. For caching they use a mixture of OpenSymphony OSCache and a home-grown cache layer.

Over the last few years, they have spent effort to modernize the UI using ajax techniques and libraries. This largely involves javascript libaries (jquery, yui, etc).

Client Side

On the client side, the lack of upgrade path from struts1 to struts2 discouraged them from migrating to struts2. Other web frameworks became popular (wicket, spring , jsf). Struts2 was not the "clear winner". Migrating all the existing UI from Struts1 to Struts2/wicket/etc did not seem to present much marginal benefit at a very high cost. They did not want to have a patchwork of technologies-du-jour (subsystem X in Struts2, subsystem Y in Wicket, etc.) so developer write new features using Struts 1.

Server Side

On the server side, they looked into moving to ejb 3, but never had a big impetus. The developers are all comfortable with ejb-jar.xml, EJBHome, EJBRemote, that "ejb 2.1 as is" represented the path of least resistance.

One big complaint about the ejb environment: programmers still pretend "ejb server runs in separate jvm than servlet engine". No app server (jboss/weblogic) has ever enforced this separation. The team has never deployed the ejb server on a separate box then the app server.

The ear file contains multiple copies of the same jar file; one for the 'web layer' (foo.war/WEB-INF/lib) and one for the server side (foo.ear/). The app server only loads one jar. The duplications makes for ambiguity.

Caching

As for caching, they use several cache implementations: OpenSymphony cache and a homegrown cache. Jgroups provides clustering support

Now What?

The question: The team currently has spare cycles to to invest in modernizing the application? Where would the smart investor spend them?

The main criteria:

1) productivity gains. Specifically reducing the time to develope new subsystems features and reduced maintenance. 2) performance/scalability.

They do not care about fashion or techno-du-jour street cred.

What do you all recommend?

On the persistence side Switch everything (or new development only) to JPA/JPA2?
Straight hibernate? Wait for Java EE 6?

On the client/web-framework side: Migrate (some or all) to struts2? wicket? jsf/jsf2?

As for caching: terracotta? ehcache? coherence? stick with what they have? how best to take advantage of the huge heap sizes that the 64-bit jvms offer?

Thanks in advance.