Who still runs Java EE and JSF
Java EE, the enterprise edition of Java, powers large internal systems: claims processing, student information systems, case management, supply chain portals, regulatory reporting. JavaServer Faces was its standard web layer, usually combined with EJBs, JPA and a database such as Oracle or DB2. BuiltWith trends for the top 1M sites (October 2026) show Java EE on about 41,700 sites and JavaServer Faces on about 1,400.
These applications are big, important and expensive to touch, which is why they get left alone.
What goes wrong when nobody is looking after it
- The application server is old. WebLogic, WebSphere or JBoss versions several releases behind, with configuration that nobody documented.
- The Java standard moved. Java EE became Jakarta EE, and from Jakarta EE 9 package names changed from
javaxtojakarta, so an upgrade touches the source. - UI component libraries aged out. Libraries such as RichFaces reached end of life, and screens depend on them.
- Heavy server-side state. JSF keeps view state on the server, which causes memory pressure and slow sessions as usage grows.
- The build and deployment are unclear. A WAR or EAR is deployed through a console, with data sources and JMS queues configured by hand.
- Skills have narrowed. Few people want to read EJB 2 deployment descriptors and XML configuration.
Support and takeover options
Java EE and JSF is Tier B, taken on by arrangement with a Java specialist. The Takeover Assessment is read-only: obtain the source and the deployed EAR or WAR, document the application server, data sources, queues and security realm, check the build and run an inventory of libraries and their versions.
Next steps:
- Make it reproducible and safe. Source in version control, a working build, exported server configuration, backups and monitoring. Ongoing Support is arranged case by case.
- Upgrade. Move to a supported JDK, application server and Jakarta release, replace retired libraries and fix breaking changes. Fixes and Upgrades.
- Migrate in stages. Extract services, move to Spring or a lighter runtime, or rebuild the front end, one module at a time. Modernization and AI.
If the application is down, Emergency Recovery is the first call. It covers outages from errors, crashes and neglect.
The javax to jakarta step
This is the change that surprises people. Code and dependencies referring to javax.* must become jakarta.* to run on a current server, and every third-party library must have a matching version. Tools help with the mechanical rename, but the dependency chain is where problems appear. We list every library and check for a Jakarta-compatible release before promising a timeline.
Component libraries and screens
JSF screens depend heavily on a component suite. We count the components used, group screens by how complex they are and decide which to convert first. Often a handful of screens carry most of the daily use. Retired libraries are replaced in place where possible, and screens that need a rethink are marked for later.
How we work
Tier B and C stacks are by arrangement with a stack specialist. We scope each in writing and tell you plainly when we are not the right fit. Every engagement starts read-only. Write access is set out in a signed agreement first, and a person reviews every change before it reaches a live system. Work is AI-assisted and human-reviewed, and we explain how at the start.
Related stacks
See Java, Struts and Spring, ASP.NET Web Forms and Ajax and Oracle Forms and Reports.
Request a quote for your Java EE application and tell us the server, the Java version if you know it, and who maintains it.