Packages within JAR files can be optionally sealed, which means that all classes defined in that package must be archived in the same JAR file. You might want to seal a package, for example, to ensure version consistency among the classes in your software.

You seal a package in a JAR file by adding the Sealed header in the manifest, which has the general form:

Name: myCompany/myPackage/

Sealed: true

The value myCompany/myPackage/ is the name of the package to seal.

Note that the package name must end with a “/”.

An Example

We want to seal two packages firstPackage and secondPackage in the JAR file MyJar.jar.

We first create a text file named Manifest.txt with the following contents:

Name: myCompany/firstPackage/

Sealed: true

Name: myCompany/secondPackage/

Sealed: true

---

Warning : 

The text file must end with a new line or carriage return. The last line will not be parsed properly if it does not end with a new line or carriage return.

---

We then create a JAR file named MyJar.jar by entering the following command:

jar cmf MyJar.jar Manifest.txt MyPackage/*.class

This creates the JAR file with a manifest with the following contents:

Manifest-Version: 1.0

Created-By: 1.6.0 (Sun Microsystems Inc.)

Name: myCompany/firstPackage/

Sealed: true

Name: myCompany/secondPackage/

Sealed: true

Sealing JAR Files

If you want to guarantee that all classes in a package come from the same code source, use JAR sealing. A sealed JAR specifies that all packages defined by that JAR are sealed unless overridden on a per-package basis.

To seal a jar file, use the Sealed manifest header with the value true. For example,

Sealed: true

specifies that all packages in this archive are sealed unless explicitly overridden for particular packages with the Sealed attribute in a manifest entry.

When you create a JAR file, it automatically receives a default manifest file. There can be only one manifest file in an archive, and it always has the pathname

META-INF/MANIFEST.MF

When you create a JAR file, the default manifest file simply contains the following:

Manifest-Version: 1.0Created-By: 1.6.0 (Sun Microsystems Inc.)

These lines show that a manifest`s entries take the form of “header: value” pairs. The name of a header is separated from its value by a colon. The default manifest conforms to version 1.0 of the manifest specification and was created by the 1.6.0 version of the JDK.

The manifest can also contain information about the other files that are packaged in the archive. Exactly what file information should be recorded in the manifest depends on how you intend to use the JAR file. The default manifest makes no assumptions about what information it should record about other files.

Digest information is not included in the default manifest. To learn more about digests and signing, see the Signing and Verifying JAR Files lesson.

Typically, verification of signed JAR files will be the responsibility of your Java^TM Runtime Environment. Your browser will verify signed applets that it downloads. Signed applications invoked with the -jar option of the interpreter will be verified by the runtime environment.

However, you can verify signed JAR files yourself by using the Jarsigner tool. You might want to do this, for example, to test a signed JAR file that you’ve prepared.

The basic command to use for verifying a signed JAR file is:

jarsigner -verify jar-file

This command will verify the JAR file’s signature and ensure that the files in the archive haven’t changed since it was signed. You’ll see the following message if the verification is successful:

jar verified.

If you try to verify an unsigned JAR file, the following message results:

jar is unsigned. (signatures missing or not parsable)

If the verification fails, an appropriate message is displayed. For example, if the contents of a JAR file have changed since the JAR file was signed, a message similar to the following will result if you try to verify the file:

jarsigner: java.lang.SecurityException: invalid SHA1

signature file digest for test/classes/Manifest.class

The Java^TM platform enables you to digitally sign JAR files. You digitally sign a file for the same reason you might sign a paper document with pen and ink — to let readers know that you wrote the document, or at least that the document has your approval.

When you sign a letter, for example, everyone who recognizes your signature can confirm that you wrote the letter. Similarly when you digitally sign a file, anyone who “recognizes” your digital signature knows that the file came from you. The process of “recognizing” electronic signatures is called verification.

The ability to sign and verify files is an important part of the Java platform’s security architecture. Security is controlled by the security policy that’s in force at runtime. You can configure the policy to grant security privileges to applets and to applications. For example, you could grant permission to an applet to perform normally forbidden operations such as reading and writing local files or running local executable programs. If you have downloaded some code that’s signed by a trusted entity, you can use that fact as a criterion in deciding which security permissions to assign to the code.

Once you (or your browser) have verified that an applet is from a trusted source, you can have the platform relax security restrictions to let the applet perform operations that would ordinarily be forbidden. A trusted applet can have freedoms as specified by the policy file in force.

The Java platform enables signing and verification by using special numbers called public and private keys. Public keys and private keys come in pairs, and they play complementary roles.

The private key is the electronic “pen” with which you can sign a file. As its name implies, your private key is known only to you so that no one else can “forge” your signature. A file signed with your private key can be verified only by the corresponding public key.

Public and private keys alone, however, aren’t enough to truly verify a signature. Even if you’ve verified that a signed file contains a matching key pair, you still need some way to confirm that the public key actually comes from the signer that it purports to come from.

One more element, therefore, is required to make signing and verification work. That additional element is the certificate that the signer includes in a signed JAR file. A certificate is a digitally signed statement from a recognized certification authority that indicates who owns a particular public key. A certification authority are entities (typically firms specializing in digital security) that are trusted throughout the industry to sign and issue certificates for keys and their owners. In the case of signed JAR files, the certificate indicates who owns the public key contained in the JAR file.

When you sign a JAR file your public key is placed inside the archive along with an associated certificate so that it’s easily available for use by anyone wanting to verify your signature.

To summarize digital signing:

• The signer signs the JAR file using a private key.


• The corresponding public key is placed in the JAR file, together with its certificate, so that it is available for use by anyone who wants to verify the signature.

Digests and the Signature File

When you sign a JAR file, each file in the archive is given a digest entry in the archive’s manifest. Here’s an example of what such an entry might look like:

Name: test/classes/ClassOne.class

SHA1-Digest: TD1GZt8G11dXY2p4olSZPc5Rj64=

The digest values are hashes or encoded representations of the contents of the files as they were at the time of signing. A file’s digest will change if and only if the file itself changes.

When a JAR file is signed, a signature file is automatically generated and placed in the JAR file’s META-INF directory, the same directory that contains the archive’s manifest. Signature files have filenames with an .SF extension. Here is an example of the contents of a signature file:

Signature-Version: 1.0

SHA1-Digest-Manifest: h1yS+K9T7DyHtZrtI+LxvgqaMYM=

Created-By: 1.6.0 (Sun Microsystems Inc.)

Name: test/classes/ClassOne.class

SHA1-Digest: fcav7ShIG6i86xPepmitOVo4vWY=
Name: test/classes/ClassTwo.class

SHA1-Digest: xrQem9snnPhLySDiZyclMlsFdtM=
Name: test/images/ImageOne.gif

SHA1-Digest: kdHbE7kL9ZHLgK7akHttYV4XIa0=
Name: test/images/ImageTwo.gif

SHA1-Digest: mF0D5zpk68R4oaxEqoS9Q7nhm60=

As you can see, the signature file contains digest entries for the archive’s files that look similar to the digest-value entries in the manifest. However, while the digest values in the manifest are computed from the files themselves, the digest values in the signature file are computed from the corresponding entries in the manifest. Signature files also contain a digest value for the entire manifest (see the SHA1-Digest-Manifest header in the above example).

When a signed JAR file is being verified, the digests of each of its files are re-computed and compared with the digests recorded in the manifest to ensure that the contents of the JAR file haven’t changed since it was signed. As an additional check, digest values for the manifest file itself are re-computed and compared against the values recorded in the signature file.

You can read additional information about signature files on the Manifest Format page of the JDK^TM documentation.

The Signature Block File

In addition to the signature file, a signature block file is automatically placed in the META-INF directory when a JAR file is signed. Unlike the manifest file or the signature file, signature block files are not human-readable.

The signature block file contains two elements essential for verification:

• The digital signature for the JAR file that was generated with the signer’s private key


• The certificate containing the signer’s public key, to be used by anyone wanting to verify the signed JAR file

Signature block filenames typically will have a .DSA extension indicating that they were created by the default Digital Signature Algorithm. Other filename extensions are possible if keys associated with some other standard algorithm are used for signing.

You may need to include package version information in a JAR file’s manifest. You provide this information with the following headers in the manifest:

Headers in a manifest

Header	Definition
Name	The name of the specification.
Specification-Title	The title of the specification.
Specification-Version	The version of the specification.
Specification-Vendor	The vendor of the specification.
Implementation-Title	The title of the implementation.
Implementation-Version	The build number of the implementation.
Implementation-Vendor	The vendor of the implementation.

One set of such headers can be assigned to each package. The versioning headers should appear directly beneath the Name header for the package. This example shows all the versioning headers:

Name: java/util/

Specification-Title: Java Utility Classes

Specification-Version: 1.2

Specification-Vendor: Sun Microsystems, Inc.

Implementation-Title: java.util

Implementation-Version: build57

Implementation-Vendor: Sun Microsystems, Inc.

For more information about package version headers, see the Package Versioning specification .

An Example

We want to include the headers in the example above in the manifest of MyJar.jar.

We first create a text file named Manifest.txt with the following contents:

Name: java/util/

Specification-Title: Java Utility Classes

Specification-Version: 1.2

Specification-Vendor: Sun Microsystems, Inc.

Implementation-Title: java.util

Implementation-Version: build57

Implementation-Vendor: Sun Microsystems, Inc.

---

Warning : The text file must end with a new line or carriage return. The last line will not be parsed properly if it does not end with a new line or carriage return.

---

We then create a JAR file named MyJar.jar by entering the following command:

jar cmf MyJar.jar Manifest.txt MyPackage/*.class

This creates the JAR file with a manifest with the following contents:

Manifest-Version: 1.0

Created-By: 1.6.0 (Sun Microsystems Inc.)

Name: java/util/

Specification-Title: Java Utility Classes

Specification-Version: 1.2

Specification-Vendor: Sun Microsystems, Inc.

Implementation-Title: java.util

Implementation-Version: build57

Implementation-Vendor: Sun Microsystems, Inc.

Distributing your Application as an executable JAR file

A JAR (Java ARchive) is a way of packaging together all of the resources associated with a program (class files, images, sounds, etc.). Putting your program in a JAR allows it to be distributed as a single executable file, saving space and simplifying the download process. The information in this tutorial applies to Java version 1.2 or higher. For more information about JAR files, follow Sun’s tutorial. To learn about signing the JAR and Java Web Start.

A simple example. Let’s say we wanted to distribute the simple program Hello.java as a JAR. First, we create a text file named Hello.mf which contains:

Manifest-Version: 1.0

Main-Class: Hello

Then, we create the archive by typing:

jar cmf Hello.mf Hello.jar Hello.class Hello.java

and run it by typing:

java -jar Hello.jar

The file Hello.jar can now be downloaded and executed.

Creating an executable JAR file. Here is the general procedure for creating an executable JAR:

1. Compile your java code, generating all of the program’s class files.
   



2. Create a manifest file containing the following 2 lines:
   

   Manifest-Version: 1.0
   
   Main-Class: name of class containing main
   
   

   The name of the file should end with the .mf suffix. It is important that the file ends with a blank line.
   



3. To create the JAR, type the following command:
   

   jar cmf manifest-file jar-file input-files

   The input-files must include any class files, images, sounds, etc. that your program uses. Optionally, you can include the program’s .java files in the JAR. See below for adding directories ot the JAR.
   



4. To view the contents of the JAR, type:
   

   jar tf jar-file

   
   



5. Execute the application from the command line by typing:
   

   java -jar jar-file

   If the application is GUI-based, you can also launch it by double-clicking the JAR file.

Accessing resources in a JAR. In general, the first step in accessing a JAR resource involves creating a URL. This might require modifying your program. For example, you can no longer use the following code fragment to read in an image that is stored in a file as follows

Image image = Toolkit.getDefaultToolkit().getImage(filename);

Instead, create the URL object using

URL url = getClass.getResource(filename);

Image image = Toolkit.getDefaultToolkit().getImage(url);

Or, if the code is in a static method of class X, then create the URL with

URL url = X.class.getResource(filename); 

Now, the resource can be accessed the same way, regardless of whether it is in a JAR or the current directory. See the method play(filename) in StdDraw.java for an example involving audio clips, and and the constructor In(String s) in In.java for an example involving text files.

JAR Subdirectories. The JAR format also support storing files in a directory structure. Consider a program Sample.java, which uses the Turtle Graphics interface to display a collection of pictures stored in a subdirectory called images. Our working directory looks like:

The Manifest should read:

Manifest-Version: 1.0

Main-Class: Sample

To create the JAR, type:

jar cmf Sample.mf Sample.jar Sample.class Turtle.class Sample.java Turtle.java images

The contents listing appears as:

META-INF/

META-INF/MANIFEST.MF

Sample.class

Turtle.class

Sample.java

Turtle.java

images/

images/image1.gif

images/image2.gif

images/image3.gif

Notice that the directory structure is still preserved (the META-INF directory is created to hold the manifest and other general information about the JAR).

Eclipse Integration

yWorks Ant Explorer is available as a plugin for the popular Java IDE Eclipse. It supports both the visualization and execution of Ant build scripts.

Installation

You can install the plugin by using Eclipse’s integrated Update Manager, which is available via the menu items “Help” – “Software Updates” – “Find and Install.”
A “New Remote Site” with URL “http://www.yworks.com/eclipse/update” has to be created.

Alternatively, the Jar archive containing the Eclipse plugin can be directly downloaded and extracted into the respective directory (normally, %ECLIPSE_HOME% or ${user.home}/.eclipse).

Usage

The views of yWorks Ant Explorer are opened whenever the visualization of an Ant build script is started via its menu item from the “Package Explorer.”

Furthermore, the views are automatically updated whenever they are visible and an Ant build script is opened inside the editor view.

One of the good features of Eclipse is its auto fill property. This can be further enhanced using its code template feature. Creation of code templates is necessary to improve development productivity. Templates add consistency and uniformity to your code. Eclipse has so many ready-to-use templates. And you can create your own code templates according to your requirements. To use these templates just type the starting characters of the template and then press “CTRL+SPACE”. For example in Ecipse IDE type “tr” and then press “CTRL+SPACE”, It will add “try-catch” block to the code.

This article will guide you to create your own code template. Let us take an example to generate a “if-else” template with one “else if” condition.

1. Go to the Templates ( Window –> Preference –> java–> Editor –> Templates) .


2. Click “New”. A window similiar to below appears.







3. Fill the details as shown above.


4. Click “OK”.


5. Now you can use your custom template in the program like any other template by pressing “CTRL+SPACE” as shown in the below given screenshots.