JAR File Specification

原文地址：http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest

注：JAR官方文档

Contents

• Introduction
• TheMETA-INF directory
• Name-Value pairs andSections
• JAR Manifest
  • Overview
  • ManifestSpecification
  • Main Attributes
  • Per-Entry Attributes
• Signed JAR file
  • Overview
  • Signature File
    • Signature validation
    • The Magic Attribute
  • Digital Signatures
• Notes onManifest and Signature Files
• JAR Index
  • Overview
  • Index FileSpecification
  • BackwardCompatibility
• Service Provider
  • Overview
  • Provider ConfigurationFile
  • Example
• API Details
• See Also

Introduction

JAR file is a file format based on the popular ZIP file format andis used for aggregating many files into one. A  JAR file isessentially a zip file that contains an optional META-INFdirectory. A JAR file can be created by the command-line jar tool, or by using the  java.util.jarAPI in the Java platform. There is no restriction on the name of aJAR file, it can be any legal file name on a particular platform.

In many cases, JAR files are not just simple archives of javaclasses files and/or resources. They are used as building blocksfor applications and extensions. The META-INF directory, if itexists, is used to store package and extension configuration data,including security, versioning, extension and services.

The META-INF directory

The following files/directories in the META-INF directory arerecognized and interpreted by the Java 2 Platform to configureapplications, extensions, class loaders and services:

• MANIFEST.MF

The manifest file that is used to define extension and packagerelated data.

• INDEX.LIST

This file is generated by the new " -i" option of the jartool, which contains location information for packages defined inan application or extension.  It is part of the JarIndeximplementation and used by class loaders to speed up their classloading process.

• x.SF

The signature file for the JAR file.  'x' stands for the basefile name.

• x.DSA

The signature block file associated with the signature file withthe same base file name. This file stores the digital signature ofthe corresponding signature file.

• services/

This directory stores all the service provider configuration files.

Name-Value pairs andSections

Before we go to the details of the contents of the individualconfiguration files, some format convention needs to be defined. Inmost cases, information contained within the manifest file andsignature files is represented as so-called "name: value" pairsinspired by the RFC822 standard.  We also call these pairsheaders or attributes.

Groups of name-value pairs are known as a "section". Sectionsare separated from other sections by empty lines.

Binary data of any form is represented as base64. Continuationsare required for binary data which causes line length to exceed 72bytes. Examples of binary data are digests and signatures.

Implementations shall support header values of up to 65535bytes.

All the specifications in this document use the same grammar inwhich terminal symbols are shown in fixed width font andnon-terminal symbols are shown in italic type face.

Specification:

  section:                      *header +newline
  nonempty-section:      +header+newline
 newline:                      CR LF | LF | CR ( not followed by LF)
  header:                      name : value
 name:                        alphanum *headerchar
 value:                         SPACE * otherchar newline *continuation
 continuation:             SPACE *otherchar newline
 alphanum:                 { A-Z} | { a-z} | { 0-9}
  headerchar:               alphanum | - | _
  otherchar:                 any UTF-8 character except NUL, CR and LF

; Also: To prevent mangling of files sent via straighte-mail, no
; header will start with the four letters "From".
 

Non-terminal symbols defined in the above specification will bereferenced in the following specifications.

JAR Manifest

Overview

A JAR file manifest consists of a main section followed by a listof sections for individual JAR file entries, each separated by anewline. Both the main section and individual sections follow thesection syntax specified above. They each have their own specificrestrictions and rules.

The main section contains security and configuration informationabout the JAR file itself, as well as the application or extensionthat this JAR file is a part of. It also defines main attributesthat apply to every individual manifest entry.  No attributein this section can have its name equal to  "Name".This section is terminated by an empty line.

The individual sections define various attributes for packagesor files contained in this JAR file. Not all files in the JAR fileneed to be listed in the manifest as entries, but all files whichare to be signed must be listed. The manifest file itself must notbe listed.  Each section must start with an attribute with thename as "Name", and the value must be a relative path tothe file, or an absolute URL referencing data outside thearchive.

If there are multiple individual sections for the same fileentry, the attributes in these sections are merged. If a certainattribute have different values in different sections, the last oneis recognized.

Attributes which are not understood are ignored. Such attributesmay include implementation specific information used byapplications.

Manifest Specification:

  manifest-file:                   main-section newline *individual-section
 main-section:                   version-info newline *main-attribute
 version-info:                      Manifest-Version : version-number
  version-number:              digit+{ . digit+}*
 main-attribute:                (any legitimate main attribute) newline
 individual-section:             Name : value newline*perentry-attribute
 perentry-attribute:           (any legitimate perentry attribute) newline
  newline:                            CR LF | LF | CR ( not followed by LF)
   digit:                                {0-9} 

In the above specification, attributes that can appear in themain section are referred to as main attributes, whereas attributesthat can appear in individual sections are referred to as per-entryattributes. Certain attributes can appear both in the main sectionand the individual sections, in which case the per-entry attributevalue overrides the main attribute value for the specified entry.The two types of attributes are defined as follows.
 

MainAttributes

Main attributes are the attributes that are present in the mainsection of the manifest. They fall into the following differentgroups:

• general main attributes
  • Manifest-Version: Defines the manifest file version. The valueis a legitimate version number, as described in the abovespec.
  • Created-By: Defines the version and the vendor of the javaimplementation on top of which this manifest file is generated.This attribute is generated by thejar tool.
  • Signature-Version: Defines the signature version of the jarfile. The value should be a validversion-numberstring.
  • Class-Path: The value of this attribute specifies the relativeURLs of the extensions or libraries that this application orextension needs. URLs are separated by one or more spaces. Theapplication or extension class loader uses the value of thisattribute to construct its internal search path.
• attribute defined for stand-alone applications: This attributeis used by stand-alone applications that are bundled intoexecutable jar files which can be invoked by the java runtimedirectly by running "java -jar x.jar".
  • Main-Class: The value of this attribute defines the relativepath of the main application class which the launcher will load atstartup time. The value mustnot have the .classextension appended to the class name.
• attributes defined for applets: These attributes are used by anapplet which is bundled into JAR files to define requirements,version and location information for the extensions which thisapplet depends on. (seeExtension Versioning ).
  • Extension-List: This attribute indicates the extensions thatare needed by the applet. Each extension listed in this attributewill have a set of additional attributes that the applet uses tospecify which version and vendor of the extension it requires.
  • <extension>-Extension-Name: This attribute is the uniquename of the extension. The Java Plug-in will compare the value ofthis attribute with the Extension-Name attribute in the manifestsof installed extensions to determine if the extension isinstalled.
  • <extension>-Specification-Version: This attributespecifies the minimum extension specification version that isrequired by the applet. The Java Plug-in will compare the value ofthis attribute with the Specification-Version attribute of theinstalled extension to determine if the extension is up todate.
  • <extension>-Implementation-Version: This attritutespecifies the minimum extension implementation version number thatis required by the applet. The Java Plug-in will compare the valueof this attribute with the Implementation-Version attribute of theinstalled extension to see if a more recent implementation needs tobe downloaded.
  • <extension>-Implementation-Vendor-Id: This attribute canbe used to identify the vendor of an extension implementation ifthe applet requires an implementation from a specific vendor. TheJava Plug-in will compare the value of this attribute with theImplementation-Vendor-Id attribute of the installed extension.
  • <extension>-Implementation-URL: This attribute specifiesa URL that can be used to obtain the most recent version of theextension if the required version is not already installed.
• attribute defined for extension identification: This attributeis used by extensions to define their unique identity.
  • Extension-Name: This attribute specifies a name for theextension contained in the Jar file. The name should be a uniqueidentifier such as the name of the main package comprising theextension.
• attributes defined for extension and  package versioning  and sealing information: Theseattributes define features of the extension which the JAR file is apart of. The value of these attributes apply to all the packages inthe JAR file, but can be overridden by per-entry attributes.
  • Implementation-Title: The value is a string that defines thetitle of the extension implementation.
  • Implementation-Version: The value is a string that defines theversion of the extension implementation.
  • Implementation-Vendor: The value is a string that defines theorganization that maintains the extension implementation.
  • Implementation-Vendor-Id: The value is a string id thatuniquely defines the organization that maintains the extension implementation.
  • Implementation-URL: This attribute defines the URL from whichthe extension implementation can be downloaded from.
  • Specification-Title: The value is a string that defines thetitle of the extension specification.
  • Specification-Version: The value is a string that defines theversion of the extension specification.
  • Specification-Vendor: The value is a string that defines theorganization that maintains the extension specification.
  • Sealed: This attribute defines whether this JAR file is sealedor not. The value can be either "true" or "false", case is ignored.If it is set to "true", then all the packages in the JAR file aredefaulted to be sealed, unless they are defined otherwiseindividually.

Per-Entry Attributes

Per-entry attributes apply only to the individual JAR file entry towhich the manifest entry is associated with.  If the sameattribute also appeared in the main section, then the value of theper-entry attribute overwrites the main attribute's value. Forexample, if JAR file a.jar has the following manifest content:

Manifest-Version: 1.0
Created-By: 1.2 (Sun Microsystems Inc.)
Sealed: true
Name: foo/bar/
Sealed: false

It means that all the packages archived in a.jar are sealed,except that package foo.bar is not.

The per-entry attributes fall into the following groups:

• attributes defined for file contents:
  • Content-Type: This attribute can be used to specify the MIMEtype and subtype of data for a specific file entry in theJAR file. The value should be a string in the form oftype/subtype. For example "image/bmp" is an image type witha subtype of bmp (representing bitmap). This would indicate thefile entry as an image with the data stored as a bitmap. RFC1521 and1522 discuss and definethe MIME types definition.
• attributes defined for package versioning and sealinginformation: These are the same set of attributes defined above asmain attributes that defines the extension package versioning andsealing information. When used as per-entry attributes, theseattributes overwrites the main attributes but only apply to theindividual file specified by the manifest entry.
• attribute defined for beans objects:
  • Java-Bean: Defines whether the specific jar file entry is a Java Beansobject or not. The value should be either "true" or "false", caseis ignored.
• attributes defined for signing: These attributes are used forsigning and verifying purposes. More details here.
  • x-Digest-y: The name of this attribute specifies the name ofthe digest algorithm used to compute the digest value for thecorresponding jar file entry. The value of this attribute storesthe actual digest value. The prefix 'x' specifies the algorithmname and the optional suffix 'y'  indicates to which languagethe digest value should be verified against.
  • Magic: This is an optional attribute that can be used byapplications to indicate how verifier should compute the digestvalue contained in the manifest entry.  The value of thisattribute is a set of comma separated context specific strings.Detailed description is here.

Signed JARFile

Overview

A JAR file can be signed by using the command line jarsigner tool ordirectly through the java.security API. Every fileentry, including non-signature related files in the META-INF directory, will be signed if the JAR file issigned by the jarsigner tool. The signature related files are:

• META-INF/MANIFEST.MF
• META-INF/*.SF
• META-INF/*.DSA
• META-INF/*.RSA
• META-INF/SIG-*

Note that if such files are located in META-INFsubdirectories, they are not considered signature-related.Case-insensitive versions of these filenames are reserved and willalso not be signed.

Subsets of a JAR file can be signed by using thejava.security API. A signed JAR file is exactly thesame as the original JAR file, except that its manifest is updatedand two additional files are added to theMETA-INFdirectory: a signature file and a signature block file. Whenjarsigner is not used, the signing program has to construct boththe signature file and the signature block file.

For every file entry signed in the signed JAR file, anindividual manifest entry is created for it as long as it does notalready exist in the manifest. Each manifest entry lists one ormore digest attributes and an optionalMagic attribute.

SignatureFile

Each signer is represented by a signature file with extension .SF. The major part of the file is similar to themanifest file. It consists of a main section which includesinformation supplied by the signer but not specific to anyparticular jar file entry. In addition to the Signature-Version and Created-Byattributes (see Main Attributes),the main section can also include the following securityattributes:

• x-Digest-Manifest-Main-Attributes (where x is the standard nameof a java.security.MessageDigest algorithm): The valueof this attribute is the digest value of the main attributes of themanifest.
• x-Digest-Manifest (where x is the standard name of ajava.security.MessageDigest algorithm): The value ofthis attribute is the digest value of the entire manifest.

The main section is followed by a list of individual entries whosenames must also be present in the manifest file. Each individualentry must contain at least the digest of its corresponding entryin the manifest file.

Paths or URLs appearing in the manifest file but not in thesignature file are not used in the calculation.

Signature Validation

A successful JAR file verification occurs if the signature(s) arevalid, and none of the files that were in the JAR file when thesignatures were generated have been changed since then. JAR fileverification involves the following steps:

1. Verify the signature over the signature file when the manifestis first parsed. For efficiency, this verification can beremembered. Note that this verification only validates thesignature directions themselves, not the actual archive files.

2. If an x-Digest-Manifest attribute exists in thesignature file, verify the value against a digest calculated overthe entire manifest. If more than onex-Digest-Manifest attribute exists in the signaturefile, verify that at least one of them matches the calculateddigest value.

3. If an x-Digest-Manifest attribute does not exist inthe signature file or none of the digest values calculated in theprevious step match, then a less optimized verification isperformed:

   1. If an x-Digest-Manifest-Main-Attributes entryexists in the signature file, verify the value against a digestcalculated over the main attributes in the manifest file. If thiscalculation fails, then JAR file verification fails. This decisioncan be remembered for efficiency. If anx-Digest-Manifest-Main-Attributes entry does not existin the signature file, its nonexistence does not affect JAR fileverification and the manifest main attributes are not verified.

   2. Verify the digest value in each source file information sectionin the signature file against a digest value calculated against thecorresponding entry in the manifest file. If any of the digestvalues don't match, then JAR file verification fails.

   One reason the digest value of the manifest file that is storedin the x-Digest-Manifest attribute may not equal thedigest value of the current manifest file is that one or more fileswere added to the JAR file (using the jar tool) after the signature(and thus the signature file) was generated. When the jar tool isused to add files, the manifest file is changed (sections are addedto it for the new files), but the signature file is not. Averification is still considered successful if none of the filesthat were in the JAR file when the signature was generated havebeen changed since then, which is the case if the digest values inthe non-header sections of the signature file equal the digestvalues of the corresponding sections in the manifest file.

4. For each entry in the manifest, verify the digest value in themanifest file against a digest calculated over the actual datareferenced in the "Name:" attribute, which specifies either arelative file path or URL. If any of the digest values don't match,then JAR file verification fails.

Example manifest file:

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

Name: common/class1.class
SHA-256-Digest: (base64 representation of SHA-256 digest)

Name: common/class2.class
SHA1-Digest: (base64 representation of SHA1 digest)
SHA-256-Digest: (base64 representation of SHA-256 digest)

The corresponding signature file would be:

Signature-Version: 1.0
SHA-256-Digest-Manifest: (base64 representation of SHA-256 digest)
SHA-256-Digest-Manifest-Main-Attributes: (base64 representation of SHA-256 digest)

Name: common/class1.class
SHA-256-Digest: (base64 representation of SHA-256 digest)

Name: common/class2.class
SHA-256-Digest: (base64 representation of SHA-256 digest)

TheMagic Attribute

Another requirement to validate the signature on a given manifestentry is that the verifier understand the value or values of theMagic key-pair value in that entry's manifest entry.

The Magic attribute is optional but it is required that a parserunderstand the value of an entry's Magic key if it is verifyingthat entry's signature.

The value or values of the Magic attribute are a set ofcomma-separated context-specific strings. The spaces before andafter the commas are ignored. Case is ignored. The exact meaning ofthe magic attributes is application specific. These values indicatehow to compute the hash value contained in the manifest entry, andare therefore crucial to the proper verification of the signature.The keywords may be used for dynamic or embedded content, multiplehashes for multilingual documents, etc.

Here are two examples of the potential use of Magic attribute inthe manifest file:

        Name: http://www.example-scripts.com/index#script1
        SHA-256-Digest: (base64 representation of SHA-256 hash)
        Magic: JavaScript, Dynamic

        Name: http://www.example-tourist.com/guide.html
        SHA-256-Digest: (base64 representation of SHA-256 hash)
        SHA-256-Digest-French: (base64 representation of SHA-256 hash)
        SHA-256-Digest-German: (base64 representation of SHA-256 hash)
        Magic: Multilingual

In the first example, these Magic values may indicate that theresult of an http query is the script embedded in the document, asopposed to the document itself, and also that the script isgenerated dynamically. These two pieces of information indicate howto compute the hash value against which to compare the manifest'sdigest value, thus comparing a valid signature.

In the second example, the Magic value indicates that thedocument retrieved may have been content-negotiated for a specificlanguage, and that the digest to verify against is dependent onwhich language the document retrieved is written in.

Digital Signatures

A digital signature is a signed version of the .SFsignature file. These are binary files not intended to beinterpreted by humans.

Digital signature files have the same filenames as the .SF filesbut different extensions. The extension varies depending on thetype of digital signature.

• .RSA (PKCS7 signature, SHA-256 + RSA)
• .DSA (PKCS7 signature, DSA)

Digital signature files for signature algorithms not listed abovemust reside in the META-INF directory and have theprefix " SIG-". The corresonding signature file( .SF file) must also have the same prefix.

For those formats that do not support external signed data, thefile shall consist of a signed copy of the.SF file.Thus some data may be duplicated and a verifier should compare thetwo files.

Formats that support external data either reference the.SF file, or perform calculations on it with implicitreference.

Each .SF file may have multiple digital signatures,but those signatures should be generated by the same legalentity.

File name extensions may be 1 to 3 alphanum characters.Unrecognized extensions are ignored.

Notes on Manifest andSignature Files

Following is a list of additional restrictions and rules that applyto manifest and signature files.

• Before parsing:
  • If the last character of the file is an EOF character (code26), the EOF is treated as whitespace. Two newlines are appended(one for editors that don't put a newline at the end of the lastline, and one so that the grammar doesn't have to special-case thelast entry, which may not have a blank line after it).
• Attributes:
  • In all cases for all sections, attributes which are notunderstood are ignored.
  • Attribute names are case insensitive. Programs which generatemanifest and signature files should use the cases shown in thisspecification however.
  • Attribute names cannot be repeated within a section.
• Versions:
  • Manifest-Version and Signature-Version must be first, and inexactly that case (so that they can be recognized easily as magicstrings). Other than that, the order of attributes within a mainsection is not significant.
• Ordering:
  • The order of individual manifest entries is notsignificant.
  • The order of individual signature entries is not significant,except that the digests that get signed are in that order.
• Line length:
  • No line may be longer than 72 bytes (not characters), in itsUTF8-encoded form. If a value would make the initial line longerthan this, it should be continued on extra lines (each startingwith a single SPACE).
• Errors:
  • If a file cannot be parsed according to this spec, a warningshould be output, and none of the signatures should betrusted.
• Limitations:
  • Because header names cannot be continued, the maximum length ofa header name is 70 bytes (there must be a colon and a SPACE afterthe name).
  • NUL, CR, and LF can't be embedded in header values, and NUL,CR, LF and ":" can't be embedded in header names.
  • Implementations should support 65535-byte (not character)header values, and 65535 headers per file. They might run out ofmemory, but there should not be hard-coded limits below thesevalues.
• Signers:
  • It is technically possible that different entities may usedifferent signing algorithms to share a single signature file. Thisviolates the standard, and the extra signature may be ignored.
• Algorithms:
  • No digest algorithm or signature algorithm is mandated by thisstandard. However, at least one of MD5 and SHA1 digestalgorithm must be supported.

JAR Index

Overview

Since 1.3, JarIndex is introduced to optimize the class searchingprocess of class loaders for network applications, especiallyapplets. Originally, an applet class loader uses a simple linearsearch algorithm to search each element on its internal searchpath, which is constructed from the "ARCHIVE" tag or the"Class-Path" main attribute. The class loader downloads and openseach element in its search path, until the class or resource isfound. If the class loader tries to find a nonexistent resource,then all the jar files within the application or applet will haveto be downloaded. For large network applications and applets thiscould result in slow startup, sluggish response and wasted networkbandwidth. The JarIndex mechanism collects the contents of all thejar files defined in an applet and stores the information in anindex file in the first jar file on the applet's class path. Afterthe first jar file is downloaded, the applet class loader will usethe collected content information for efficient downloading of jarfiles.

The existing jar tool is enhanced to be able to examinea list of jar files and generate directory information as to whichclasses and resources reside in which jar file. This directoryinformation is stored in a simple text file namedINDEX.LIST in the META-INF directory of the rootjar file. When the classloader loads the root jar file,  itreads theINDEX.LIST file and uses it to construct a hashtable of mappings from file and package names to lists of jar filenames. In order to find a class or a resource, the class loaderqueries the hashtable to find the proper jar file and thendownloads it if necessary.

Once the class loader finds a INDEX.LIST file in aparticular jar file, it always trusts the information listed in it.If a mapping is found for a particular class, but the class loaderfails to find it by following the link, an InvalidJarIndexExceptionis thrown. When this occurs, the application developer should rerunthe jar tool on the extension to get the right informationinto the index file.

To prevent adding too much space overhead to the application andto speed up the construction of the in-memory hash table, theINDEX.LIST file is kept as small as possible. For classes withnon-null package names, mappings are recorded at the package level.Normally one package name is mapped to one jar file, but if aparticular package spans more than one jar file, then the mappedvalue of this package will be a list of jar files. For resourcefiles with non-empty directory prefixes, mappings are also recordedat the directory level.  Only for classes with null packagename, and resource files which reside in the root directory, willthe mapping be recorded at the individual file level.

Index File Specification

The INDEX.LIST file contains one or more sections eachseparated by a single blank line. Each section defines the contentof a particular jar file, with a header defining the jar file pathname, followed by a list of package or file names, one perline.  All the jar file paths are relative to the code base ofthe root jar file. These path names are resolved in the same way asthe current extension mechanism does for bundled extensions.

The UTF-8 encoding is used to support non ASCII characters infile or package names in the index file.
 

Specification

    index file:                  version-info blankline section*
    version-info:              JarIndex-Version: version-number
    version-number:       digit+{.digit+}*
    section:                     body blankline
    body:                        header name*
    header:                     char+ .jar newline
    name:                       char+ newline
    char:                         any valid Unicode character except NULL, CR and LF
    blankline:                   newline newline
    newline:                      CR LF | LF | CR ( not followed by LF)
    digit:                          { 0-9}
 
The INDEX.LIST file is generated by running jar-i. See the jar manpage for more details.

Backward Compatibility

The new class loading scheme is totally backward compatible withapplications developed on top of the current extensionmechanism.  When the class loader loads the first jar file andan INDEX.LIST file is found in the META-INFdirectory, it would construct the index hash table and use the newloading scheme for the extension. Otherwise, the class loader willsimply use the original linear search algorithm.

ServiceProvider

Overview

Files in the META-INF/services directory are serviceprovider configuration files. A service is a well-known set ofinterfaces and (usually abstract) classes. A service provider is aspecific implementation of a service. The classes in a providertypically implement the interfaces and subclass the classes definedin the service itself. Service providers may be installed in animplementation of the Java platform in the form of extensions, thatis, jar files placed into any of the usual extension directories.Providers may also be made available by adding them to the appletor application class path or by some other platform-specificmeans.

A service is represented by an abstract class. A provider of agiven service contains one or more concrete classes that extendthis service class with data and code specific to the provider.This provider class will typically not be the entire provideritself but rather a proxy that contains enough information todecide whether the provider is able to satisfy a particular requesttogether with code that can create the actual provider on demand.The details of provider classes tend to be highly service-specific;no single class or interface could possibly unify them, so no suchclass has been defined. The only requirement enforced here is thatprovider classes must have a zero-argument constructor so that theymay be instantiated during lookup.

Provider-Configuration File

A service provider identifies itself by placing aprovider-configuration file in the resource directoryMETA-INF/services. The file's name should consist of thefully-qualified name of the abstract service class. The file shouldcontain a newline-separated list of unique concrete provider-classnames. Space and tab characters, as well as blank lines, areignored. The comment character is '#' (0x23); on each line allcharacters following the first comment character are ignored. Thefile must be encoded in UTF-8.

Example

Suppose we have a service class named java.io.spi.CharCodec. It hastwo abstract methods:

• public abstract CharEncoder getEncoder(StringencodingName);
• public abstract CharDecoder getDecoder(StringencodingName);

Each method returns an appropriate object or null if it cannottranslate the given encoding. Typical CharCodec providers willsupport more than one encoding.

If sun.io.StandardCodec is a provider of the CharCodec servicethen its jar file would contain the fileMETA-INF/services/java.io.spi.CharCodec. This file wouldcontain the single line:

sun.io.StandardCodec    # Standard codecs for the platform

To locate an encoder for a given encoding name, the internal I/Ocode would do something like this:

   CharEncoder getEncoder(String encodingName) {
       Iterator ps = Service.providers(CharCodec.class);
       while (ps.hasNext()) {
           CharCodec cc = (CharCodec)ps.next();
           CharEncoder ce = cc.getEncoder(encodingName);
           if (ce != null)
               return ce;
       }
       return null;
   }

The provider-lookup mechanism always executes in the securitycontext of the caller. Trusted system code should typically invokethe methods in this class from within a privileged securitycontext.

API Details

Package java.util.jar

See Also

Package java.security
Package java.util.zip