Skip to main content

Java EE appclients vs standalone clients

7 replies [Last post]
Joined: 2006-05-09

Could someone explain to me what the difference between these are? I thought clients are always Java programs that have a main class and they're supposed to have a Swing/AWT/Command line GUI, but it seems like appclients are deployed on the server. What is the point in this? I can't see the GUI if it's on the server!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-10

Apparently there's some confusion over application clients.
To quote from the Java EE platform spec:

....Application clients are Java programming language
....programs that are typically GUI programs that execute
....on a desktop computer. Application clients offer a
....user experience similar to that of native applications,
....and have access to all of the facilities of the Java EE
....middle tier.

Application clients are not expected to execute on the server,
although some people have found that useful in some situations.

Application clients are simply standalone Java applications
that execute in an environment that conveniently provides
access to the Java EE facilities. It's the application client
container that provides Java EE support to the application
client program.

Some people want to run "regular" Java SE applications, but
have access to Java EE facilities without need for the application
client container. Yes, you can do this. There's no magic here.
But there is a lot of work. You can duplicate most or all of
the work that the application client container is doing for you,
and thus run your "standalone" Java EE client application without
using the application client container.

There are some deficiencies in the specification for the
application client container, and some deficiencies in the
implementation, that I believe contribute to people avoiding
the use of the application client container.

One of the biggest deficiencies in the specification is that,
while it describes how to deploy your application, including
an application client component, it doesn't say anything about
how the application client component that is deployed to the
server actually gets to the client desktop machine where it
needs to run.

What we've done in GlassFish, and what we're considering adding
to the specification, is add support for Java Web Start for
deploying application clients. This allows the client desktop
machine to download the application client program on demand.

Some people want to use their own deployment approaches,
automated or manual, for deploying their desktop applications.
What they'd like is to have a simple, small jar file or other
bundle that is their application client, and run that application
just like they would run any other Java SE application. This is
the case that drives people to "standalone applications" instead
of application clients.

What we should do is create a simpler "application client runtime",
as similar as possible to the simple "java" command, that could be
used to run these applications.

The final deficiency, and one of the harder problems to solve, is
that the application client container depends on the application
server fairly heavily, e.g., for configuring access to resources.
If the server is unavailable (due to network problems or whatever),
the application client has no reasonable way to function in any
sort of degraded mode until the server is available again.
Improving this definitely requires work in the GlassFish
implementation, and may also require changes to the Java EE

Bill Shannon
Java EE Spec Lead

Joined: 2005-03-30

Although the appclient is deployed in the server, it runs in a different container called "[b]Application Client Container[/b]" which starts in a separate JVM, typically in client's host. So it can have a GUI like a nornal Java SE application. How an ACC is launched is vendor specific. In GlassFish, you can invoke it by running the command $GLASSFISH_HOME/bin/appclient or using Java Web Start. You can find more info about this in GlassFish documentation.

-- Sahoo

Joined: 2005-03-30

Sahoo is exactly right, and the situation can be even a little more confusing because of different uses of the term "stand-alone client."

A Java EE app client can be part of an EAR or it can reside in a JAR by itself. Some people refer to the second of these as a stand-alone client. In both cases, the client runs inside the app client container as Sahoo has described. Like the other Java EE containers, the app client container provides convenient services for the client such as handling annotations for EJB references and handling security authentication.

A developer can also write a Java program that does not run in the app client container but works with EJBs or other components on the back-end server. But such programs need to use JNDI to look up explicitly the components they want to access. There is no built-in processing of annotations, for example. Some people refer to this kind of client as a stand-alone client.

I mention all of this to provide a little background and to warn you that different people use the term stand-alone client to mean different things.

- Tim

Joined: 2006-05-09

Thanks, I've been so hopelessly confused over all this.

By the way, don't appclients also have to use JNDI for bean lookup? I mean, according to what I've read, injection only works for the main class -- or is it possible to somehow inject the InitialContext there?

Also, if you have any useful pointers on how to run appclients on JBoss, I'd be even more thankful. All I have seen is some theoretical info, never anything practical.

Joined: 2007-07-04

hanshin wrote:
Also, if you have any useful pointers on how to run appclients on JBoss, I'd be even more thankful. All I have seen is some theoretical info, never anything practical.

Sorry for rather late answer but for a future reference to run on JBoss AS 7 or Wildfly you can with:
$ bin/ myear.ear#myjar.jar

Joined: 2005-03-30

You are absolutely correct about the restriction regarding injection support in app clients. The app client container does the injection only in the app client's main class and only on [b]static [/b]elements.

If you want to refer to an injected field from some other class you could write a public (or package-visible if you prefer and it would work for you) static getter method that returns the annotated main class's field. The injection occurs before the main class's main method is invoked, so any code invoked directly or indirectly from there that invoked the getter would get the injected value.

As you pointed out, an alternative is to use JNDI explicitly from those other locations in the app client. Personally, if I were doing it that way I'd encapsulate the details of the JNDI retrieval in a utility class that other code would invoke...and at that point what would be gained over the injection-plus-getter-method approach?

I'm afraid I can't help with the JBoss question.

- Tim

Joined: 2004-01-19

For the moment using JEE appclients doesn't provide much advantages. Annotations are quite powerful but more on the server side. The static constraint is such that using client container isn't worth the pain. But that may change, client container is a great concept and I'm sure it will provide much features in the futur than simply annotation.
In DocDoku ( we chose a standalone client deployed with java web start and glassfish as the backend. Glassfish is also a great application server but there's a point I must admit I dislike which is the need to deploy heavy jar lib on the client. For example appserv-rt.jar is more 15Mb !
Hopefully we used pack200 to reduce its size to 5Mb. But please, Glassfish team, provide smaller client lib !

Message was edited by: florent_garin