Application Client Container: The Java EE Runtime on Your Desktop

The application client container is a piece of the Jakarta EE platform, the enterprise Java standard that used to be called Java EE. Most of that platform lives on a server. This one part does not. It runs on the user’s own desktop computer, and it hosts a special kind of program called an application client: an ordinary Java program, usually with a desktop window, that can reach straight into the business logic and data of a company server.

Why give a desktop program a container of its own? Because a plain Java program starts with nothing. It has no managed way to find server components, no standard sign-in, and no help with the network plumbing between the desk and the data center. The container supplies all of that before the program’s own code even starts. The Jakarta EE Platform specification still defines exactly what this runtime must do, and this guide walks through it in plain words: what an application client is, what the container does for it, how it reached a desktop, and why you rarely meet one in a new project today.

What an application client is

The specification describes application clients as Java programs that typically put a graphical user interface on a desktop computer and feel like native applications. Underneath, they behave like ordinary Java SE programs: each one runs in its own Java virtual machine, starts at a main method, and keeps running until that virtual machine shuts down. The difference sits in what the program can reach. An application client has access to the whole middle tier of the platform, the enterprise beans, databases and message queues that live on the server. The specification counts application clients among the platform’s three component types, alongside web components and enterprise beans.

Imagine the desk of a claims handler at an insurance company in the platform’s heyday. The window on the screen is a Java program installed on that one computer. It looks local, and it is local, but every button press can call an enterprise bean on the server, which applies the company’s rules and reads the central database. The handler never sees a browser and never waits for a page to load. This is client server application software in its classic form: a rich client doing the talking, a server doing the deciding.

That design answers the oldest question in software architecture: which parts of a system run where. A web application puts almost everything on the server and sends the user a thin page. An application client moves the whole user interface, and sometimes real computing work, onto the desktop, and keeps only the shared logic and data on the server. Neither answer is wrong. They trade installation effort against richness, and for years the rich desktop answer won inside large companies. The missing piece was a standard way to run that desktop side, and that is the gap the application client container was designed to fill.

What the container does for the client

The first thing to understand is who starts. When a user launches an application client, the first code that runs belongs to the container, not to the program. The specification says container code typically executes first, to prepare the environment and initialize the naming service client library, the phone book the client will use to find things on the server. Only then does the container load the client’s main class and call its main method. The program begins life with its world already arranged.

The container’s most useful trick is dependency injection. A developer marks static fields in the main class with annotations such as @EJB or @Resource. Static means the fields belong to the class itself, which matters because the container never creates an object from the main class; it just loads the class and calls main. Before main runs, the container fills those fields with live handles. A field that looks like a local object is really a line to an enterprise bean on the server, and calling a method on it sends the work across the network. The client code reads as if everything were in the same machine.

The same machinery answers lookups. Through the naming service, called JNDI, the client asks for enterprise beans, database connections, message queues and mail sessions by name, inside the standard java: namespace, instead of hardcoding server addresses. In GlassFish, the container even carries its own client ORB, the component that speaks the RMI-IIOP protocol to the server, so the program never touches the wire protocol itself. The specification also sets an honest limit: it does not require the container to hand the client a transaction object of its own. Transactions stay where they belong, inside the enterprise beans the client calls. Think of the container as a broker between one program and everything underneath it, the same job an operating system kernel does between programs and hardware, but brokering enterprise services instead of devices.

The last service is security. The application client container provides the authentication service for its programs. It can ask the user for a name and password when the program starts, or it can wait and authenticate lazily, the first time the client touches something protected. It can also plug into the computer’s own sign-in, so one login covers both. If the application wants to collect credentials its own way, it can name a callback handler class in its deployment descriptor, and the container will use that class for every sign-in conversation. GlassFish, the reference server from the Eclipse Foundation, keeps the default simple: a small dialog box that asks for the user name and password.

One container of four: the classic Java EE map

The application client container makes most sense next to its siblings. In this platform, a container is the runtime layer between a component and the platform’s services. Components never talk to each other directly. They go through their containers, which inject the services each component needs and apply security checks, resource pooling and state management around it. Oracle’s Java EE Tutorial lists four container types, and the four-way split shaped a generation of enterprise systems.

Read the current specification and the map has already changed. Jakarta EE 11 lists three containers for its three component types: application client, web and enterprise bean. The applet container is gone, because the browser plug-in it rested on is gone. Oracle removed the Java deployment stack, including the plug-in and Java Web Start, from JDK 11, after deprecating it in JDK 9.

The split still explains how the systems of that era fit together, and it still echoes through enterprise application integration work today. Every tier reached the others only through a container, with naming, security and transactions handled the same way on each hop. Modern stacks make different choices, but anyone who maintains a system from that period reads this map first.

How an application client got to a desktop

Deployment started with packaging. Developers packed an application client into a JAR file. Inside sat the client classes, a manifest whose Main-Class entry named the class where execution starts, and usually a deployment descriptor called META-INF/application-client.xml, which declared the enterprise beans and other resources the client referenced. Annotations on the main class could do the same job and replace the descriptor. The finished client JAR then traveled inside the application’s EAR file, the single bundle that also carried the web and EJB modules to the server.

Deploying that EAR on the server generated the client stubs, the support code the client needs to talk across the network. The GlassFish guide to developing Java clients spells out the flow: an administrator retrieves the generated client JAR, which carries a name of the form app-nameClient.jar, using the deploy command’s retrieve option or the get-client-stubs command. The container itself reaches remote desktops as a package of classes and libraries, assembled by the package-appclient tool. A user then launches everything with the appclient command. Notably, the specification refuses to dictate any of this installation machinery. It defines the package format and the runtime duties, and leaves delivery to each product.

In the GlassFish era, the friendliest delivery route was Java Web Start. GlassFish even switched the feature on for every application client by default. The server offered the client behind a link, and Web Start downloaded it to the desktop, kept it updated on every launch, and started it like a local program. For a while that made a heavyweight desktop client feel almost as easy to hand out as a web page. The road closed in 2018, when JDK 11 removed Web Start along with the rest of the deployment stack. The container survived the loss. Its delivery van did not.

Its standing in 2026: a legacy pattern

Nothing in this guide describes new technology, and it is better to say so plainly. The application client container is a legacy pattern. Yet it is a legacy the standard still carries on purpose. Jakarta EE 11, released in 2025, gives application clients a full chapter, and a product that claims the full platform must support the container, even though the platform’s slimmer profiles may leave it out. Eclipse GlassFish, the reference implementation, still ships the appclient launcher and the tools around it, and still expects fresh client stubs when a system upgrades. The container is not deleted. It is just rarely chosen for anything new.

The reasons are practical. A browser application needs no installation on a thousand desktops and updates itself the moment the server changes. Where a team does want a real app on the device, it now builds one with cross platform mobile programming tools or a desktop framework, and lets it talk to the server over REST APIs and JSON, a far simpler conversation than RMI-IIOP, the protocol the old container managed. The two delivery tricks that once made Java clients painless, the browser plug-in and Java Web Start, left the JDK years ago, and nothing standard replaced them.

You still meet the pattern where old systems earn their keep: the fat client on a back office desk that has quietly worked for years, wired into enterprise beans nobody wants to rewrite. If you inherit one, the map in this article is the map of your job: a client JAR, a descriptor, a container that injects and signs in, and a server doing the real work. And if you are designing something new, treat the pattern as history that explains the present. Today’s API clients, SDKs and desktop shells solve the same problem, putting a friendly face on remote services, with much lighter tools.

Conclusion

The application client container is the part of Jakarta EE that lived on the user’s computer. It prepared the ground, injected the server’s beans and resources into a desktop Java program, handled the sign-in, and only then called main. Its siblings on the server won the future, and browsers plus REST APIs took over its job. But the specification still carries it, long-lived systems still run on it, and anyone who maintains enterprise Java will meet it sooner or later.