When developers hear the word container, technologies like Docker or Kubernetes often come to mind. An Application Client Container (ACC) is something different. It is a runtime environment designed to support Java EE and Jakarta EE application clients that communicate with enterprise services.
Instead of running inside the application server, an application client executes in its own Java Virtual Machine (JVM). The ACC provides the managed environment around that client, handling services such as security, deployment support, resource access, and communication with server-side enterprise components.
Understanding the Application Client Container is especially useful when working with Jakarta EE architecture, GlassFish, Enterprise Beans, JNDI, or existing enterprise Java applications. This guide explains what an ACC is, how it works, the services it provides, and how it differs from other types of containers.
What Is an Application Client Container?
An Application Client Container, commonly shortened to ACC, is the client-side container that provides runtime support for a Java EE or Jakarta EE application client.
A Jakarta EE application client is a Java program that runs in its own JVM and typically starts through a standard main method. Unlike an ordinary standalone Java application, however, it can depend on its container for access to services provided by the enterprise environment.
In simple terms, the architecture looks like this:
User → Application Client → Application Client Container → Jakarta EE Server → Enterprise Services
The application handles functionality on the client side, while the ACC creates the managed environment needed to communicate with resources and components provided by the Jakarta EE platform.
Depending on the application and implementation, the client environment can provide access to technologies and resources such as:
- Enterprise Beans
- JNDI resources
- Jakarta Messaging
- Persistence and database resources
- Web services
- Authentication and security mechanisms
- Other configured enterprise resources
This is what separates an application client running through an ACC from a basic standalone Java program. The client can rely on services supplied by its enterprise runtime instead of managing every part of the environment itself.
Why Does an Application Client Need a Container?
Enterprise applications often depend on more than local application code. A client may need to authenticate a user, locate an Enterprise Bean, access a messaging resource, connect to a database, or use configuration supplied when the application is deployed.
Managing all these concerns directly inside the client increases complexity and can tightly couple application code to infrastructure.
The Application Client Container provides a layer between the client application and the Jakarta EE environment. It allows certain infrastructure concerns to be handled by the container while developers concentrate on application functionality.
For example, a client that needs an Enterprise Bean does not necessarily have to hard-code all the information required to locate that component. References and resources can instead be provided through the managed environment.
The ACC can therefore support responsibilities such as:
- Security: Helps establish the authentication context required when accessing protected enterprise resources.
- Resource access: Makes configured resources available to the client.
- Injection: Allows supported resources and references to be supplied to application components.
- Naming: Provides access to the component naming environment through JNDI.
- Deployment support: Allows application-specific configuration to be provided through the deployment environment.
Compared with larger server-side containers, the ACC can be relatively lightweight because its primary role is supporting the application client.
How Does an Application Client Container Work?
An Application Client Container sits between the Java application client and the enterprise environment it needs to access. Although implementations differ, the basic process can be understood in four stages.
1. The Application Client Starts
A Jakarta EE application client behaves like a normal Java program in one important respect: it runs in its own JVM and begins execution through its main method.
It is therefore different from a servlet or Enterprise Bean that executes inside a server-side container.
2. The ACC Prepares the Client Environment
The container provides the environment required by the application client.
Depending on the application and implementation, this can involve processing deployment information, preparing security, resolving declared resources, and making required references available to the application.
3. The Client Accesses Enterprise Resources
Once the environment is ready, the application can access the enterprise resources it requires.
For example, it might use a configured reference to access an Enterprise Bean or messaging resource. JNDI can also provide access to resources available through the application’s naming environment.
4. The Client Communicates With Server-Side Components
The ACC does not replace the Jakarta EE application server. It provides the environment from which the client can interact with appropriate server-side services.
The basic relationship is:
Client Machine
User
↓
Application Client
↓
Application Client Container
↓
Network
Jakarta EE Server
Enterprise Beans / Messaging / Web Services / Databases / Other Resources
The important distinction is that the Application Client Container operates with the client, while containers such as the Web Container and Enterprise Bean Container operate on the server.
Core Services Provided by an Application Client Container
The ACC exists to give an application client access to services expected in the Jakarta EE environment without turning the client itself into an application server.
Some of its most important responsibilities include:
| ACC Service | Purpose |
|---|---|
| Security | Supports the authentication environment needed to access protected resources |
| JNDI | Gives the client access to its naming environment |
| Resource access | Makes configured enterprise resources available |
| Injection | Supplies supported resources and references to application components |
| Enterprise Bean access | Enables clients to work with remote enterprise components where supported |
| Deployment support | Provides configuration required by the application client |
| Jakarta EE APIs | Makes applicable platform APIs available in the client environment |
The exact capabilities available to an application depend on the Jakarta EE product, platform version, configuration, and technologies being used.
Application Client Container Architecture
The easiest way to understand the ACC is to separate Jakarta EE architecture into the client side and server side.
Client Side
The client side typically contains:
- Java application client
- JVM
- Application Client Container
- Client-side libraries and configuration
The user interacts with the client application while the ACC supplies the managed environment around it.
Server Side
The Jakarta EE server can contain:
- Web components
- Enterprise Beans
- Business logic
- Messaging services
- Persistence services
- Databases and external resources
- Other enterprise services
The ACC acts as part of the bridge that allows the application client to work with services provided by this environment.
It is therefore important not to think of the ACC as a smaller application server. Its role is specifically focused on supporting application clients.
Packaging an Application Client
Jakarta EE application clients are normally packaged as JAR files.
The package contains the application’s classes and resources along with the information required to deploy or execute the client in a compatible environment.
A deployment descriptor, when used, is named:
META-INF/application-client.xml
It can describe information associated with the application client and its environment. Jakarta EE also supports annotations for many types of configuration, so developers should not assume that every application requires extensive XML configuration.
An application client JAR can also be included as part of a larger enterprise application archive when appropriate.
The exact deployment and launch process depends on the Jakarta EE implementation. GlassFish, for example, provides tooling specifically designed for launching application clients.
Application Client Container in GlassFish
Oracle’s GlassFish documentation describes the ACC as the client-side environment used to execute Java EE application clients outside the GlassFish Server JVM. GlassFish is one of the environments most closely associated with the term Application Client Container, partly because its documentation provides explicit tooling and configuration for Java EE application clients.
In GlassFish, the ACC contains the Java classes, libraries, and supporting files required to execute an application client outside the server JVM. The client can then access supported server-side services from its own JVM.
What Is appclient?
GlassFish provides an appclient command for launching its Application Client Container and executing an application client.
Conceptually, the process is:
appclient → ACC starts → application client starts → client accesses server resources
For example, an application client packaged in a JAR can be launched through the GlassFish client tooling rather than being treated as an entirely independent Java program.
GlassFish also provides implementation-specific configuration for its ACC and application clients.
These details are important when working with GlassFish specifically, but they should not be treated as universal requirements for every Jakarta EE implementation.
Application Client Container vs Web Container vs Enterprise Bean Container
Jakarta EE uses different containers because different types of application components require different runtime environments.
| Feature | Application Client Container | Web Container | Enterprise Bean Container |
|---|---|---|---|
| Location | Client side | Server side | Server side |
| Main purpose | Support application clients | Run web components | Run Enterprise Beans |
| Typical components | Java application clients | Servlets and other web components | Enterprise Beans |
| Runs application UI | Can support client-side UI | Commonly serves web interfaces/APIs | Usually no direct UI |
Starts with main | Application client does | No | No |
| Access to enterprise services | Yes, where supported | Yes | Yes |
The main difference is therefore where the component executes and what type of component the container manages.
Application Client Container vs Web Container
A Web Container runs web components on the server. These components commonly receive HTTP requests and provide web pages, APIs, or other web-based responses.
An Application Client Container supports Java application clients running outside the application server.
A typical web architecture looks like:
Browser → HTTP → Web Container → Application
An ACC-based architecture is closer to:
Java Application Client → ACC → Jakarta EE Server
If the application is primarily browser-based, the Web Container is generally the relevant environment. ACC applies specifically to Jakarta EE application clients.
Application Client Container vs Enterprise Bean Container
An Enterprise Bean Container and an Application Client Container perform different roles.
The Enterprise Bean Container runs and manages Enterprise Beans on the server. The Application Client Container runs with an application client that may need to access those enterprise components remotely.
A simplified relationship is:
Application Client → ACC → Enterprise Bean Container → Enterprise Bean
The ACC manages the client’s environment, while the Enterprise Bean Container manages the server-side Enterprise Bean.
Application Client Container vs Docker Container
The word container can create confusion because modern developers often associate containers with Docker.
An ACC and a Docker container are fundamentally different technologies.
| Application Client Container | Docker Container |
|---|---|
| Part of enterprise Java/Jakarta EE architecture | Application packaging and isolation technology |
| Provides a managed environment for application clients | Packages applications with runtime dependencies |
| Works at the Jakarta EE application level | Uses operating-system-level containerization |
| Provides access to applicable enterprise services | Provides process and environment isolation |
| Designed around Jakarta EE application clients | Can run applications written in many languages |
Docker containers can host Java applications, but that does not turn Docker into an Application Client Container.
The two technologies simply use the word container for different architectural concepts.
Is the Application Client Container Still Part of Jakarta EE?
Yes. The Application Client Container remains defined in the Jakarta EE Platform.
A full Jakarta EE Platform product must support the Application Client Container, although individual Jakarta EE profiles may not require it.
That distinction matters because ACC should not simply be described as a discontinued Java EE feature.
At the same time, being part of Jakarta EE does not mean ACC is the default choice for every new client-server application.
Many modern applications use browsers, mobile apps, REST APIs, and other HTTP-based interfaces to communicate with backend services. These architectures can provide simpler interoperability when clients are not tightly integrated with a Jakarta EE environment.
ACC remains most relevant when an application is specifically designed as a Jakarta EE application client or when developers are maintaining enterprise systems that already use this architecture.
When Should You Use an Application Client Container?
An ACC makes the most sense when its managed Jakarta EE environment provides a clear advantage.
Potential situations include:
- Maintaining an existing Java EE or Jakarta EE application client
- Building a Java client that depends on Jakarta EE services
- Accessing remote Enterprise Beans from an application client
- Working within an organization already standardized around compatible Jakarta EE infrastructure
- Supporting enterprise Java applications that rely on container-managed resources and configuration
For a new application, however, developers should compare ACC with simpler alternatives before choosing the architecture.
If a desktop, mobile, or web client only needs to communicate with backend functionality, exposing that functionality through well-designed APIs may provide greater flexibility across languages, platforms, and deployment environments.
The right choice depends on the system being built rather than whether ACC is technically available.
Common Application Client Container Issues
Application Client Containers introduce another managed environment into the architecture, so problems can occur when the client, configuration, and server are not aligned.
Resource or JNDI Lookup Failures
A client may fail to locate a required resource because the resource is not configured correctly, the expected name does not match the deployed resource, or the required service is unavailable.
Check both the application configuration and server-side resource configuration.
Authentication Problems
Protected enterprise resources can require authentication before the client is allowed to access them.
Incorrect credentials, security configuration, or mismatched authentication settings can prevent the application from connecting successfully.
Missing Client Dependencies
The application client requires the correct classes and libraries at runtime. Missing dependencies can lead to class-loading or startup failures.
Using the client tooling supplied by the Jakarta EE implementation can help ensure that the required runtime components are available.
Client and Server Compatibility
Implementation-specific clients can depend on compatible server libraries and protocols.
This is particularly important with older GlassFish environments, where mixing client and server components from incompatible major versions can cause problems.
Deployment Configuration Errors
Incorrect deployment descriptors, resource references, annotations, or implementation-specific configuration can prevent the ACC from preparing the correct client environment.
When troubleshooting, verify the client configuration against the documentation for the exact Jakarta EE product and version being used.
Application Client Container in Modern Enterprise Architecture
The Application Client Container represents an important architectural idea in enterprise Java: applications can rely on managed runtime services rather than implementing every infrastructure concern themselves.
That same principle appears throughout modern software architecture, even when ACC itself is not being used.
Containers, application platforms, managed cloud services, dependency injection frameworks, API gateways, and service platforms all attempt in different ways to separate infrastructure responsibilities from application logic.
For organizations maintaining Java EE or Jakarta EE systems, understanding ACC can therefore be useful beyond simply knowing how to run a client. It helps explain how enterprise Java separates application components from the runtime services supporting them.
When organizations move from tightly integrated enterprise Java clients toward API-based, cloud, or distributed architectures, custom AI development can help turn modern application requirements into scalable, production-ready systems. The implementation changes, but the architectural question stays similar: which responsibilities belong inside application code, and which should be handled by the surrounding platform?
Key Takeaways
An Application Client Container (ACC) is a Jakarta EE runtime environment that supports application clients executing in their own JVM.
Unlike Web Containers and Enterprise Bean Containers, the ACC operates with the client rather than hosting server-side components.
It can provide the application client with services such as deployment support, security, naming, resource access, and access to applicable Jakarta EE APIs.
GlassFish provides a well-known implementation of this architecture and includes appclient tooling for launching application clients.
ACC remains part of the Jakarta EE Platform, but modern API-based architectures may be a better fit for many new applications that do not require close integration with Jakarta EE services.
Understanding the ACC is therefore most valuable when working with Jakarta EE architecture, GlassFish, Enterprise Beans, or existing enterprise Java systems.
Frequently Asked Questions
1. What is an Application Client Container?
An Application Client Container (ACC) is a Jakarta EE container that provides runtime services to an application client executing in its own JVM.
2. Where does an Application Client Container run?
The ACC operates on the client side with the application client, rather than inside the server-side Web or Enterprise Bean Container.
3. What is the difference between an Application Client Container and a Web Container?
An ACC supports Java application clients running outside the application server. A Web Container runs web components on the server and commonly handles HTTP-based requests.
4. What is the difference between an ACC and an Enterprise Bean Container?
The ACC manages the environment of the application client. The Enterprise Bean Container manages Enterprise Beans running on the Jakarta EE server.
5. Is the Application Client Container still part of Jakarta EE?
Yes. ACC remains part of the Jakarta EE Platform. Full Jakarta EE Platform products must support it, although individual Jakarta EE profiles may not require Application Client Container support.
