How are Java applications deployed in the "real world"?

Tdorno picture Tdorno · May 14, 2013 · Viewed 11.2k times · Source

As a novice to the world of Java programming, this question has always boggled my mind. I first believed that all Java files were compacted into applets and then ran, but I soon realized that this isn't always the case. Could someone explain to me how we actually interweave our Java applications into a real product of everyday life?

TL;DR: How do we implement our code for practical usage?

Answer

Daniel Kaplan picture Daniel Kaplan · May 14, 2013

It depends on the application. There are many options depending on how you want your users to use your app. Usually it's packaged as a jar or a specialized jar (war, ear).

In theory, you could zip the raw directory structure with your .class files in it and provide a shell script/instructions that run the java command for the user. I don't recommend this because it's kind of unprofessional and requires you to maintain a shell script for each OS you want to be able to run the program on.

Jar files are used to package libraries but you can also have a manifest file in it that says, "When someone double clicks/executes this, run this class". That class can start up a GUI or be a headless task that responds to the parameters, etc.

You can have applets, like you said. These programs are run in the user's browser.

You can have a war file, which is a way to package a web application. You give this to a web server and it knows how to deploy it so that you can visit the web pages. An example web server/container is tomcat or jetty.

You can have an ear file which can contain other war files inside it. This is used for applications that need other parts of the javaee functionality (ejbs, jms queues, etc.). An example of an application server is jboss or glassfish.

There's also java web start apps. These are apps you can run by visiting a webpage, but they get downloaded to your computer and run on the user's computer (instead of on the server's backend, like in a war/ear).

There's also javafx. I don't know anything about that though. By skimming the FAQ, it appears to be Java's answer to Adobe's Flex. You configure UI components with an xml configuration. I'm not sure what format JavaFX apps use, but it does say, "Deploy on the desktop or in the browser".


As Sotirios Delimanolis mentioned in a comment below, you can build these files with build systems like Ant or Maven. You can also build them "by hand" with the tools that come with the java/javaee sdk. For example, you should have a jar command in your path if you installed the sdk. Here are some details of these build systems:

  • Maven
    1. High level (you tell it what to build, not how to build it)
    2. Much more than just a build system. It also has dependency management, etc.
    3. Opinionated (it uses convention over configuration, each config file generates 1 artifact, etc.)
  • Ant
    1. Low level (you tell it how to build things)
    2. Flexible
    3. Config files can do whatever you want, build as many artifacts as you want
    4. Easy to learn
  • SDK tools
    1. Always up to date. EG: Very rarely, maven/ant may not be able to set a configuration option
    2. Difficult to remember commands
    3. Very low level
    4. By itself, not repeatable (EG: unless you build a script, you will have to type the jar command yourself each time)