Java in the enterprise, part 1 At age three, what can Java do for enterprise developers? By Joel Scotkin

July  1998

In this first of two articles, Joel Scotkin takes a bird's eye view of the Java platform, explaining recent changes to the language, the virtual machine, and the class libraries. He also tells you what you need to know about JDK 1.2 and the new extension classes. Click here to jump to part 2 (2,400 words)

Mail this article to a friend

n May 23, 1995, Java was released into the world at large. Now, more than three years after that early alpha release, it can be seen as nothing less than a phenomenon. And as Sun readies the next release of its Java Development Kit (JDK 1.2), the latest Java technology promises to change the way enterprise development is done.

Early 1996 saw the first official production release of the Java Development Kit (version 1.0). It was followed by the more familiar version 1.0.2. This stable and functional version, supported by major browsers and ported to almost every platform, became the workhorse of the Java revolution. Since then, Java has continued to evolve. The JDK 1.1 release last year gave Java the firm base it needed to support enterprise-level server applications. The upcoming JDK 1.2, along with a blossoming of auxiliary Java toolkits, are giving the platform the full armory it needs to confirm its position as the premier platform for enterprise development and commercial applications.

In this first of a two-part series on the evolution of the Java technologies, I will take a high-level look at the new functionality and programming interfaces added to the JDK, and I'll talk about some of the new initiatives in the enterprise and media arenas. Next month, I'll put these technologies into context with a look at real-world examples of Java at work.

People mean different things when they say Java, because the Java platform is really a combination of three things. First, it's a powerful object-oriented programming language. Second, it's a standard for cross-platform binary executables. Finally, Java is a set of standard APIs, specifications, and toolkits. We'll take a look at what Sun's been up to in each of these areas.

The Java language
We're all familiar with Java as an object-oriented programming language. Strong typing, single inheritance, memory management, and powerful exception handling -- along with a real attempt to create a programming environment that can be grasped within the limits of human short-term memory -- give us an environment that could, in theory at least, make code debugging a thing of the past. The Java language has changed very little from its early versions to the present, with one major exception: the advent of inner classes. This addition enabled a new model of object-oriented (OO) design and development -- one more in sync with the latest models of object-oriented programming -- and is worth a quick look.

Inheritance, with its fine-grained modular reuse, is a powerful concept -- but it can be overused. Recent thinking in the OO field is that inheritance should be used to modify fundamental principles of an object -- extending or modifying its core properties. However, inheritance should not be used to make changes to auxiliary behaviors. Instead, these behaviors should be delegated to an associate object that takes the appropriate actions. The AWT (Java's Abstract Windowing Toolkit, or user interface API) was built to an inheritance model. Originally, programming a button's behavior when the mouse was pressed required inheriting from the button and modifying code. The JDK 1.1, with its inner classes and delegation model, changed all that. Now, functionality is handed off to a local helper class, which cleanly implements the needed behavior without redefining the basic attributes of the button. Programming a button's behavior when the mouse is pressed no longer requires inheriting from the button and modifying code. This is a powerful model; one that makes sense for all types of object-oriented development, well beyond system events.

The Java virtual machine
The Java virtual machine (JVM) is a specification for an idealized processor -- one that could be built in silicon, but hasn't yet been. Actual implementations of the Java virtual machine, called runtimes, have the job of converting bytecode targeted to the JVM into bytecode for the local native processor (for example, a SPARC or a Pentium chip). Improvements in just-in-time compilers -- which keep the translation in memory, and then run natively for the rest of the process's lifetime -- have sped up Java execution about twenty-fold since the early days of pure interpreters. Recent tests show Java running neck and neck with C++ in many cases.

New execution technology, such as Sun's HotSpot virtual machine, promises another performance leap through adaptive optimization. In this implementation, the VM can literally profile your code as it runs, and determine the fastest possible sequence of instructions for your particular chip. In theory, virtual machines will eventually exceed the performance of C and C++ applications because they will take better advantage of their particular hardware configurations. For instance, rather than compiling an executable file for the SPARC v8 or i386 instruction set (the standard for almost all of today's SPARC or Win32 programs), HotSpot will be able to generate code using UltraSPARC- or Pentium-specific instructions. This is expected to give Java an easy 20 percent boost in performance.

The Java class libraries
The Java class libraries are the heart of the Java platform. There are two main sets of class libraries: core platform APIs, and optional extensions and toolkits. Vendors are required to ship the core libraries in order to use the Java trademark. Guaranteed access to the libraries ensures that any Java program written to these libraries will run unchanged on any hardware platform or operating system. The core has grown significantly since the 1.0.2 JDK, and a number of optional extensions have allowed the Java platform to fan out into new areas like transaction services and systems management.

Most of the changes in JDK 1.1 were fundamental improvements to the platform to help developers build server-side applications and distributed systems. The upcoming release of the 1.2 JDK (in beta now, but expected in September) focuses on updating the user interface and client side of the toolkits; it also has some significant lower-level improvements. Though 1.2 will not be officially released for a while, several of its key components -- such as Swing and Collections -- have been released independently. They are available for download from the JavaSoft Web site.

JDK 1.1
For starters, 1.1 integrated several of the APIs that had been released as extensions to 1.0.2. These include the remote method invocation (RMI) framework for distributed communication, as well as Java database connectivity (JDBC) 1.2 for database access. New functionality included serialization and externalization, reflection and introspection, character IO streams, printing support, digital signatures, and the previously discussed changes to the AWT event model.

Serialization gives Java objects the ability to write themselves out to a stream, and to be reconstructed from an object stream. The stream itself could then be targeted anywhere: It could be piped over the network (the heart of RMI), written to disk (persistent storage), saved to a database, or simply used to create easy duplicates of an object. Serialization saves entire graphs of objects -- so any objects pointed to will also be saved out to the stream. A new keyword transient was added to the language so that developers can mark variables that should not be written out.

The externalization interface is a variant on serialization. Rather than having Java automatically write out the entire object, the developer can override the reading and writing functionality to define how the object should be read in and written out.

Reflection allows Java objects to expose their core properties to an observer. By querying an object (the act of introspecting), an observer object can learn about an object's class type, constructors, fields and methods. It can then proceed to make method calls on otherwise unknown objects. Reflection is a key enabling technology for both serialization (so the system can learn what needs to be written out), and JavaBeans (so that visual editors can learn what bean properties an object has). Reflection is also useful to developers who want the flexibility to do runtime binding of objects and methods, enabling whole new classes of applications. Using this feature, writing a simple Java scripting language would be extremely easy.

JDK 1.2
Similar to the 1.1 JDK, 1.2 starts off by integrating some of the external packages into the core APIs. The most prominent of these is the Java Interface Description Language (IDL) package, which provides a full Internet Inter-Orb Protocol (IIOP)-compliant Common Object Request Broker Architecture (CORBA). Major new class libraries include the Java Foundation Classes, JDBC 2.0, Collections, and Cryptography, along with new features such as weak references and the Java Extensions Framework (a standard mechanism for optional class libraries).

The Java Foundation Classes are really a collection of four new APIs: Swing, Drag and Drop, Java 2D, and Accessibility. The Swing classes are intended to make GUIs cross-platform. Instead of following the AWT peering model, which attempts to map a Java button to a native (Motif or Win32) button, Swing is 100 percent pure Java, and only uses the most basic drawing and windowing services from the underlying operating system. Swing provides peerless equivalents for all of the AWT components, along with some new ones such as tabs, tables, and trees. Pluggable look-and-feels allow the user interface to be retargeted during runtime to sport a Motif, Windows, or custom look, such as the default Metal look-and-feel. Swing is available now from JavaSoft for use with the 1.1 JDK, and will be part of the 1.2 core API set.

Drag and Drop will enable interoperability with non-Java applications and desktops, allowing Java apps to send and receive information from other Java and non-Java programs. The Accessibility class libraries support alternative methods of interaction, including screen readers, screen magnifiers, and speech-recognition devices. Finally, the reworked Java 2D classes replace the current basic graphics display engine (the Graphics class) with a set of new classes supporting Postscript-like display and printing.

JDBC 2.0 is a major upgrade to the JDBC specification. Improvements include scrollable result sets, including arbitrary result set cursor positioning, batch updating, and support for SQL3 types, including BLOBs (binary large objects), structured types, and user-defined types. This gives developers much more flexibility when interacting with databases, and lets them easily store Java objects in databases along with their type information for use in queries. The new JDBC also adds a standard extension that supports full transactional semantics for two-phase commits, a key enabler in the Java Transaction Service, and Enterprise JavaBeans.

The Collections classes provide a set of generic containers that go well beyond the Vector and Hashtable provided in the previous JDK releases. Collections provide standard interfaces for Sets (a basic collection), Lists (ordered collections), and Maps (key/value data), along with a number of implementations of each. The Collections APIs provide iterators for traversing a collection and comparators for ordering elements, and come with built-in operators for fast sorting and searching.

Extension classes
Along with the new classes in the 1.2 core, Sun has begun to release sets of extension class libraries. Vendors are not required to ship these classes, and they are usually more task-oriented than those in the general framework. Many of them are targeted directly at the enterprise, including the Java Naming and Directory Interface (JNDI), Java Mail, Java Management (JMAPI), Java Messaging Service (JMS), Java Transaction Service (JTS), and Enterprise JavaBeans.

The Java Naming and Directory Interface is a specification that provides a uniform API to almost any hierarchical naming service. As with JDBC, vendors provide service drivers which hook the JNDI into their own naming schema. A large number of service drivers already exist, including Lightweight Directory Access Protocol (LDAP), Domain Name Service (DNS), Network Information Service (NIS), NetWare Directory Services (NDS), and the CORBA Naming Service. You can see this service in action in JDBC 2.0, which can use it to locate its databases without extra application coding by the developer.

Java Mail provides a full interface to SMTP mail -- an easy way to make any application mail-aware. Java Management is a toolkit for building network and application management tools, as well as tools for writing monitoring services into your own applications. Java Management lets you parse and generate SNMP messages -- so you can easily monitor your applications with a network management product like Tivoli, or track the status of your network with a Java program.

The Java Messaging Service (JMS) and Java Transaction Service (JTS) are both specifications for common interfaces that vendors will build into their products. JMS is a fairly generic API for publish-and-subscribe messaging, and most major vendors have signed on to support it. JTS is a wrapper around the CORBA OTS (Object Transaction Service) specification, and is a key enabler for distributed transactions.

Finally, Enterprise JavaBeans is a powerful initiative from Sun to create a server-side component model. The specification, which is being implemented by a number of vendors, is intended to create a common model for distributed application services, with full transactional support (both for database transactions and application transactions). Enterprise JavaBeans leverages either CORBA or RMI for the underlying communications, and adds a common and consistent mechanism for inter-application communications and management. The goal is to provide a server-side framework as powerful and intuitive as the drag-and-drop user interface frameworks we've come to know and love.

The real world
The Java platform has come quite a long way since its initial release. The enterprise-level changes alone have catapulted Java from being a neat tool for shiny Web pages into a powerhouse for server-side and middle-tier development. Next month we'll take a look at some of the real-world projects being built with Java, and talk about the application architectures that are being enabled by the new Java technologies.

Resources

• Part 2 of this series on Java in the enterprise http://www.sunworld.com/sunworldonline/swol-08-1998/swol-08-java.html
• JavaSoft http://java.sun.com
• SunWorld sister publication, JavaWorld http://www.javaworld.com
• A listing of Java-related stories in SunWorld's Site Index http://www.sunworld.com/common/swol-siteindex.html#Java

About the author
Joel Scotkin is president of Random Walk Computing, a New York-based consulting firm that specializes in delivering Java and CORBA solutions to the financial industry. Reach Joel at joel.scotkin@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-07-1998/swol-07-java.html
Last modified: