30 Networking

• Internet Explorer:

  • Change proxy settings in Internet Explorer (Windows Vista, Windows 7, Windows 8)

  • Configure Proxy Settings for Internet Explorer (Windows Server 2008 R2)

• Firefox: Change proxy settings in the Options window - Advanced panel

• Chrome: Chrome uses the same connection and proxy settings as Windows; follow the same steps as you would with Internet Explorer

If you select Use automatic proxy configuration script, then you must enter the URL for the location of the JavaScript method called FindProxyForURL(URL url) that returns the proxy server to be used for a URL. Support for this script is the same as described in Section 30.1.4, "Automatic Proxy Configuration."

1. Consider the size of the JAR file, the contents of the JAR file, and the bandwidth of your target audience.

   All these factors play into choosing a compression technique. The unpack200 tool is designed to be as efficient as possible, and it takes little time to restore the original file. If you have large JAR files (2 MB or more) comprised mostly of class files, Pack200 is the preferred compression technique. If you have large JAR files which are comprised of resource files (JPEG, GIF, data, etc.), then gzip is the preferred compression technique.

2. Specify the segment limit for Pack200 compression.

   Pack200 loads the entire compressed file into memory. However, when target systems are memory and resource constrained, setting the Pack200.Packer.SEGMENT_LIMIT to a lower value will reduce the memory requirements during compression and uncompression.

   As a special case, a value of -1 will produce a single large segment with all input files, while a value of 0 will produce one segment for each class. Larger archive segments result in less fragmentation and better compression, but processing them requires more memory.

   The default is -1, which means pack200 will always create a single segment output file. In cases where extremely large output files are generated, you are are strongly encouraged to use segmenting or break up the input file into smaller JARs.

   For example, a 10 MB JAR packed without this limit will typically pack about 10% smaller, but pack200 may require a larger Java heap (about ten times the segment limit).

3. Sign the JAR files.

   Pack200 rearranges the contents of the resulting JAR file. The jarsigner tool hashes the contents of the class file and stores the hash in an encrypted digest in the manifest. When unpack200 uncompresses a file, the contents of the classes will be rearranged and thus invalidate the signature. Therefore, the JAR file must be normalized first using pack200 and unpack200, and thereafter signed.

   Here's why this works: Any reordering pack200 does on any class file structures is idempotent, so the second time it is compressed, it does not change the orderings produced by the first compression. Also, unpack200 is guaranteed by the JSR 200 specification to produce a specific bytewise image for any given transmission ordering of archive elements.

   For example, suppose you want to use HelloWorld.jar:

   1. Recompress, or repack, the file to normalize the JAR file; repacking uncompresses and compresses the JAR file in one step.

      % pack200 --repack HelloWorld.jar
      

   2. Sign the JAR.

      % jarsigner -keystore myKeystore HelloWorld.jar user_name
      

      
      

      Note: You must sign the repacked file with the same key that was used when building the original JAR file. Alternatively, delete all signature files found in the META-INF directory before repacking, re-signing and verifying. The signature files are named MANIFEST.MF, *.DSA and *.SF.

      
      

      Verify the just signed JAR file to ensure the signing worked.

      % jarsigner -verify HelloWorld.jar
      jar verified.
      

      Ensure the JAR file still works.

      % Java -jar HelloWorld.jar
      HelloWorld
      

   3. Compress the JAR file with pack200.

      % pack200 HelloWorld.jar.pack.gz HelloWorld.jar
      

      
      

      Note: You must compress the JAR file with the same options that you used to repack the file to normalize the JAR file, as demonstrated in Step a. Additionally, you must set the segment limit to -1 (unlimited) for all packing steps when using JDK 6 and earlier releases to prevent accidental variations of segment boundaries; class file sizes can change slightly under these circumstances, thus disrupting signatures. The default segment limit for JDK 7 and later is -1.

      
      

   4. Uncompress the file with unpack200

      % unpack200 HelloWorld.jar.pack.gz HelloT1.jar
      

   5. Verify the JAR file.

      % jarsigner -verify HelloT1.jar
      jar verified.
      

      Test the JAR file.

      % Java -jar HelloT1.jar
      HelloWorld
      

   After verification, you can deploy the compressed pack file HelloWorld.jar.pack.gz.

4. Apply reduction techniques.

   Pack200 by default behaves in a High Fidelity (Hi-Fi) mode, meaning all the original attributes present in the classes as well as the attributes of each individual entry in a JAR file is retained. These typically tend to add to the packed file size. Use the following techniques to further reduce the size of the download:

   • Modification times: If modification time of the individual entries in a JAR file is not a concern, specify the option Pack200.Packer.MODIFICATION_TIME="LATEST". This will allow one modification time to be transmitted in the pack file for each segment. The latest time will be the latest time of any entry within that segment.

   • Deflation hint: Similar to setting the modification time to "LATEST", if the compression state of the individual entries in the archive is not required, set Pack200.Packer.DEFLATION_HINT="false". This will fractionally reduce the download size, as individual compression hints will not be transmitted. However, the JAR file when recomposed will contain "stored" entries and hence may consume more disk space on the target system.

     For example:

     pack200 --modification-time=latest --deflate-hint="true"
     tools-md.jar.pack.gz tools.jar
     

     
     

     Note: The above optimizations will yield better results with a JAR file containing thousands of entries.

     
     

   • Attributes: Several class attributes are not required when deploying JAR files. These attributes can be stripped out of class files, significantly reducing download size. However, care must be taken to ensure that required runtime attributes are maintained.

     Debugging attributes: If debugging information, such as Line Numbers and Source File, is not required (typically in applications stack traces), then these attributes can be discarded by specifying Pack200.Packer.STRIP_DEBUG=true.This typically reduces the packed file by about 10%.

     Example:

     pack200 --strip-debug tools-stripped.jar.pack.gz tools.jar
     

     Other attributes: Advanced users can use some of the other strip-related properties to strip out additional attributes. However, extreme caution should be used when doing so, the resultant JAR file must be tested on all possible Java runtime systems to ensure that the runtime does not depend on the stripped attributes.

5. Handle unknown attributes.

   Pack200 deals with standard attributes defined by the Java Virtual Machine Specification; however compilers are free to introduce custom attributes. When such attributes are present, by default, Pack200 passes through the class, emitting a warning message. These "passed-through" class files may contribute to bloating of packed files. If the unknown attributes are prevalent in the classes of a JAR file, this may lead to a very large bloat in the compressed output. In such cases, consider the following strategies:

   • Strip the attribute if the attribute is deemed to be redundant at runtime; this can be achieved by setting the property Pack200.Packer.UNKNOWN_ATTRIBUTE=STRIP:

     pack200 --unknown-attribute=strip
     foo.pack.gz foo.jar
     

   • If the attributes are required at runtime, and they do contribute to inflation in the size of the compressed file, then identify the attribute from the warning message and apply a suitable layout for these as described in the Pack200 JSR 200 specification, and the Java API reference section for the interface Pack200.Packer.

   • It is possible that a compiler could define an attribute not implemented in the layout specification of Pack200, and may cause the pack200 to malfunction. In such cases, an entire class file or class files can be "passed through", as if it were a resource by virtue of its name and can be specified as follows:

     pack200 --pass-file="com/acme/foo/bar/baz.class" foo.pack.gz foo.jar
     

     The following passes through an entire directory and its contents,

     pack200 --pass-file="com/acme/foo/bar/" foo.pack.gz foo.jar
     

   
   

   Note: When signing large JAR files, this step might fail with a security error. A likely cause is bug 5078608. Use one of the following workarounds: Specify --segment-limit=-1 during repacking and packing. Follow these repacking and signing steps: pack200 --repack b.jar a.jar Sign b.jar. pack200 --repack c.jar b.jar Sign c.jar. pack200 out.jar.pack.gz c.jar Deploy out.jar.pack.gz.

   
   

6. Take advantage of Pack200 in your installation program.

   You may wish to take advantage of the Pack200 technology in your installation program, whereby a product's JAR files may need to compressed using Pack200 and uncompressed during installation. If the JRE or SDK is bundled in the installation, you are free to use the unpack200 (Solaris, Linux, or OS X) or unpack200.exe (Windows) tool in the distribution bin directory. This implementation is a pure C++ application requiring no Java runtime to be present for it to run.

   Windows: Installers may use a better algorithm than the one in GZIP to compress entries. In such cases, one will get better compression using the Installer's intrinsic compression, by using the pack200 tool as follows:

   pack200 --no-gzip foo.jar.pack foo.jar
   

   This will prevent the output file from being gzip compressed.

   unpack200 is a Windows console application; i.e. it will display a MS-DOS window during the install. To suppress this, use a launcher with a WinMain, which will suppress this window, as shown below.

   Sample Code:

   #include "windows.h"
   #include <stdio.h>
   
   int APIENTRY WinMain(HINSTANCE hInstance,
                        HINSTANCE hPrevInstance,
                        LPSTR     lpCmdLine,
                        int       nCmdShow) {
     STARTUPINFO si;
     memset(&si, 0, sizeof(si));
     si.cb = sizeof(si);
   
     PROCESS_INFORMATION pi;
     memset(&pi, 0, sizeof(pi));
   
     //Test
     //lpCmdLine = "c:/build/windows-i586/bin/unpack200 -l c:/Temp/log c:/Temp/rt.pack c:/Temp/rt.jar";
     int ret = CreateProcess(NULL,                 /* Exec. name */
                             lpCmdLine,            /* cmd line */
                             NULL,                 /* proc. sec. attr. */
                             NULL,                 /* thread sec. attr */
                             TRUE,                 /* inherit file handle */
                             CREATE_NO_WINDOW | DETACHED_PROCESS, /* detach the process/suppress console */
                             NULL,                 /* env block */
                             NULL,                 /* inherit cwd */
                             &si,                      /* startup info */
                             &pi);                     /* process info */
     if ( ret == 0) ExitProcess(255);
   
     // Wait until child process exits.
     WaitForSingleObject( pi.hProcess, INFINITE );
   
     DWORD exit_val;
   
     // Be conservative and return
     if (GetExitCodeProcess(pi.hProcess, &exit_val) == 0) ExitProcess(255);
   
     ExitProcess(exit_val); // Return the error code of the child process
   
     return -1;
   }