eXtropia: the open web technology company
Technology | Support | Tutorials | Development | About Us | Users | Contact Us
Resources
 ::   Tutorials
 ::   Presentations
Perl & CGI tutorials
 ::   Intro to Perl/CGI and HTML Forms
 ::   Intro to Windows Perl
 ::   Intro to Perl 5
 ::   Intro to Perl
 ::   Intro to Perl Taint mode
 ::   Sherlock Holmes and the Case of the Broken CGI Script
 ::   Writing COM Components in Perl

Java tutorials
 ::   Intro to Java
 ::   Cross Browser Java

Misc technical tutorials
 ::   Intro to The Web Application Development Environment
 ::   Introduction to XML
 ::   Intro to Web Design
 ::   Intro to Web Security
 ::   Databases for Web Developers
 ::   UNIX for Web Developers
 ::   Intro to Adobe Photoshop
 ::   Web Programming 101
 ::   Introduction to Microsoft DNA

Misc non-technical tutorials
 ::   Misc Technopreneurship Docs
 ::   What is a Webmaster?
 ::   What is the open source business model?
 ::   Technical writing
 ::   Small and mid-sized businesses on the Web

Offsite tutorials
 ::   ISAPI Perl Primer
 ::   Serving up web server basics
 ::   Introduction to Java (Parts 1 and 2) in Slovak

 

Introduction to Web Programming
Table of Contents  
Distribution History
  • As we noted earlier, for most of the history of Java development, there was really no packaging. For the most part, the developer was required to put each class file as a separate file on the web server in the same hierarchy as the packages defined in your Java files. For example, if you had a com.test.utility package you would need a directory hierarchy of com/test/utility under the directory with the main applet class.

  • Unfortunately, this meant that in order for a web browser to get all of the supporting files it needed, it would have to open up a separate HTTP connection for each file. Given the state of web traffic, site overload, and any number of Internet gremlins, this could add all sorts of delays to the download. What's more, the files transferred were not compressed in any way.

    Archiving Applets with Netscape's ZIP Format

  • Initially, Netscape came to the rescue by allowing developers to put class files and supporting files like images and data in a single uncompressed ZIP file. Although, files were not compressed, this was certainly a valuable distribution option. Any web surfer who used Netscape Navigator to view a Java applet need only download a single ZIP file.

  • Thus, most developers created an uncompressed ZIP file and placed it along with the raw class files on the server. That way, Navigator users could get the speedier ZIP file and surfers using other Java-enabled browsers could still have the separate class files available to them. The HTML now evolved to something like this:

    <HTML>
    <HEAD>
    <TITLE>My Applet</TITLE>
    </HEAD>
    <BODY>
    <APPLET CODE = "myApplet.class" WIDTH = "200"
            HEIGHT = "400" ARCHIVE = "myApplet.zip">
    </APPLET>
    </BODY>
    </HTML>
    
    

    Compressing Archives with Microsoft's CAB Format

  • Nipping at the heels of Netscape, Microsoft soon introduced the CAB format to even the score, and as usual, make things even more complex for the developer. CAB files followed the same logic as Netscape's ZIP archive format. The developer could archive their entire applet into one file and use the CABBASE parameter to direct Internet Explorer browsers where they could pick up the code (this is discussed in Chapter Two). The HTML looked something like this:

    <HTML>
    <HEAD>
    <TITLE>My Applet</TITLE>
    </HEAD>
    <BODY>
    <APPLET CODE = "myApplet.class" WIDTH = "200"
            HEIGHT = "400">
    <PARAM NAME = "cabbase" VALUE = "myApplet.cab">
    
    </APPLET>
    </BODY>
    </HTML>
    

  • However, CAB files had one extra goody. Internet Explorer supported compressed CAB files. This made transferring large Java applets much more efficient because large files could be compressed into much smaller ones.

  • But, as we mentioned, this only added another level of complexity to the chores necessary for developers wishing to distribute their applications. Specifically, a developer now needed to have all the raw files available for non-big-two browsers such as Hot Java, a ZIP file for Netscape Navigator users, and a CAB file for Microsoft Internet Explorer users.

    Signing Compressed Archives with Netscape's JAR Format

  • Not to be outdone, and already deeply ensconced in the battle over web supremacy, Netscape and Sun joined together to develop the JAR (Java ARchive) format. Distributed as part of the JDK 1.1, JAR is a platform independent file format (based on the ZIP file format) that allows a developer to bundle and compress a Java applet and its requisite components (class files, images and sounds) into a single file.

  • Further, the JAR Format allowed applet authors to digitally sign individual entries in a JAR file to authenticate their origin. You create and manipulate JAR files using the jar utility program that has command line arguments similar to those of the popular UNIX tar program and then reference the archive using HTML such as the following:

    <HTML>
    <HEAD>
    <TITLE>My Applet</TITLE>
    </HEAD>
    <BODY>
    <APPLET CODE = "myApplet.class" WIDTH = "200"
            HEIGHT = "400" ARCHIVE = "myApplet.jar">
    
    </APPLET>
    </BODY>
    </HTML>
    

Previous Page | Next Page