For most Java developers, JAR files and their specialized cousins, WARs and EARs, are simply the end result of a long Ant or Maven process. It's standard procedure to copy the JAR to the right place on the server (or, more rarely, the user's machine) and forget about it.
Actually, JARs can do more than store source code, but you have to know what else is possible, and how to ask for it. The tips in this installment of the 5 things series will show you how to make the most of Java Archive files (and in some cases WARs and EARs, too), especially at deployment time.
Because so many Java developers use Spring (and because the Spring framework presents some particular challenges to our traditional use of JARs), several of the tips specifically address JARs in Spring applications. I'll start out with a quick example of a standard Java Archive file procedure, which will serve as a foundation for the tips that follow.
Put it in a JAR
Normally, you build a JAR file after your code source has been compiled, collecting the Java code (which has been segregated by package) into a single collection via either the jar command-line utility, or more commonly, the Ant jar task. The process is straightforward enough that I won't demonstrate it here, though later in the article we'll return to the topic of how JARs are constructed. For now, we just need to archive Hello, a stand-alone console utility that does the incredibly useful task of printing a message to the console, shown in Listing 1: Listing 1. Archiving the console utility
package com.tedneward.jars;public class Hello
{
public static void main(String[] args)
{
System.out.println("Howdy!");
}
}The Hello utility isn't much, but it's a useful scaffold for exploring JAR files, starting with executing the code.1. JARs are executableLanguages like .NET and C++ have historically had the advantage of being OS-friendly, in that simply referencing their name at the command-line (helloWorld.exe) or double-clicking their icon in the GUI shell would launch the application. In Java programming, however, a launcher application — java — bootstraps the JVM into the process, and we have to pass a command-line argument (com.tedneward.Hello) indicating the class whose main() method we want to launch.
These additional steps make it harder to create user-friendly applications in Java. Not only does the end user have to type all of these elements at the command-line, which many end users would rather avoid, but chances are good that he or she will somehow fat-finger it and get an obscure error back. Read more: IBM
Actually, JARs can do more than store source code, but you have to know what else is possible, and how to ask for it. The tips in this installment of the 5 things series will show you how to make the most of Java Archive files (and in some cases WARs and EARs, too), especially at deployment time.
Because so many Java developers use Spring (and because the Spring framework presents some particular challenges to our traditional use of JARs), several of the tips specifically address JARs in Spring applications. I'll start out with a quick example of a standard Java Archive file procedure, which will serve as a foundation for the tips that follow.
Put it in a JAR
Normally, you build a JAR file after your code source has been compiled, collecting the Java code (which has been segregated by package) into a single collection via either the jar command-line utility, or more commonly, the Ant jar task. The process is straightforward enough that I won't demonstrate it here, though later in the article we'll return to the topic of how JARs are constructed. For now, we just need to archive Hello, a stand-alone console utility that does the incredibly useful task of printing a message to the console, shown in Listing 1: Listing 1. Archiving the console utility
package com.tedneward.jars;public class Hello
{
public static void main(String[] args)
{
System.out.println("Howdy!");
}
}The Hello utility isn't much, but it's a useful scaffold for exploring JAR files, starting with executing the code.1. JARs are executableLanguages like .NET and C++ have historically had the advantage of being OS-friendly, in that simply referencing their name at the command-line (helloWorld.exe) or double-clicking their icon in the GUI shell would launch the application. In Java programming, however, a launcher application — java — bootstraps the JVM into the process, and we have to pass a command-line argument (com.tedneward.Hello) indicating the class whose main() method we want to launch.
These additional steps make it harder to create user-friendly applications in Java. Not only does the end user have to type all of these elements at the command-line, which many end users would rather avoid, but chances are good that he or she will somehow fat-finger it and get an obscure error back. Read more: IBM
Posts
0 comments:
Post a Comment