Home > DeveloperSection > Articles > JDK 1.1: Code Name Oak

JDK 1.1: Code Name Oak

Java Java  API(s) 
1 Comment(s)
 369  View(s)
Rate this:

JDK 1.1: Code Name Oak 

After the release of JDK 1.0 and its increasing popularity, the next major release for Java was in 19th February of 1997. As we can see, this major release came just one year after its original release. One can imagine the popularity that Java must have gained in this short period of time. So what major additions were made to Java in this release? In JDK 1.1 The number of:


·Classes  was 504

·Packages were 23.


These figures speak to the number of additions made to the Java APIs. Thus, although the change in release number was minor, this was in fact a major change.


The major change in the Java language at this time was the new event-processing model. JDK 1.0 used the hierarchical event model used by Windows operating systems. JDK 1.1 and above use the delegation event model, which is more efficient compared to the older model. This helped improve Java’s performance, which was highly desired because Java in those days lacked in performance due to its compiled and interpreted nature, as explained earlier. Programming for the delegation event model may employ the newly added anonymous and inner classes for improved efficiency.


JDK 1.1 had many minor releases over next two years, until its last release, which was JDK 1.1.8 in April 1999. Each release added new classes and interfaces to the library, and thus Java was growing every day. Some of the major milestones in these minor releases are detailed next.

Java Beans

The JavaBeans API was introduced during this period for component development in Java. Java Beans are reusable software components, written in Java that can be manipulated visually in a builder tool. Thus, we could build sophisticated GUIs (graphical user interfaces) visually by using third-party components based on the JavaBeans API.

Remote Method Invocation

JDK 1.1 also introduced Remote Method Invocation (RMI), which allows a client to invoke a method on an application running on a remote server. RMI used a proprietary binary protocol called the Java Remote Method Protocol (JRMP). Later on, a newer protocol, called the Internet InterORB Protocol (IIOP), was widely accepted by the industry and became preferred over JRMP. IIOP was designed as part of the Common Object Request Broker Architecture (CORBA). To bridge the gap between the two protocols, Java also introduced RMI over IIOP.

The JAR File Format

A Java applet may consist of many source files. When such applet code is compiled, it generates a separate object code (.class) file for each public class or interface. When the applet code is downloaded to the client machine, all such .class files must be downloaded before the applet can begin its execution. The HTTP 1.0 protocol required the creation of a separate socket connection for each file download. Typically, each .class file is a few hundred bytes in size. The time required making a connection and disconnection was much longer than the time required for each file download. To resolve this problem, JDK 1.1 introduced the JAR concept, whereby all applet .class files were archived in one single file using the PKZIP algorithm. The resultant JAR file was referenced in the APPLET tag of the HTML code. The client would now download

Digital Signatures

Another major change provided in JDK 1.1 was the introduction of digital signing. In JDK 1.0, a Java applet would run in a sandbox with several security restrictions and limited access to system resources; conversely, a stand-alone Java application runs outside the sandbox with full access to all the system resources. With digital signing, applets that were generally deployed on remote servers could now be trusted after their signatures were verified. The client would grant full privileges of a stand-alone application to such verified signed applets.

AWT Enhancements

The AWT, which contains the interfaces and classes for building the GUI, provided several enhancements in JDK 1.1. The most noticeable change was the new event model mentioned earlier. Besides this, several other additions were made to the AWT package. The GUI now supported data transfer using the clipboard so that we could cut/copy/paste the contents of our documents from even a native application to a Java application, and vice versa. We could set and use desktop colours in our Java applications. We could also define shortcut keys for menu items. It also became possible to create pop-up menus like the ones in applications running on Microsoft Windows. Finally, AWT classes added printing support. Printing was not at all possible in JDK 1.0. AWT also added a ScrollPane container for displaying large documents in windows with scrollbars.


Note that even such basic facilities were not available in JDK 1.0, and it received wide acceptance in the very short period of one year. Thus, Java had a promising future, as was proved by now.

Other Changes

Some of the other noticeable changes in JDK 1.1 included the introduction of object serialization classes, the Introspection and Reflection API, and the facility to define Inner classes. In addition, general performance improvements were made in several places.

Wonderful article

By Jonas Stuart on   2 months ago
This is a wonderful article. It gives all the details in short and simple. Thank you very much. Well done guys.

Don't want to miss updates? Please click the below button!

Follow MindStick