Chapter 3. Java and the Common Language Runtime

I l @ ve RuBoard

The Java programming language was designed with a number of aims in mind. James Gosling and Henry McGilton, two of the creators of the Java language, wrote a famous white paper called "The Java Language Environment" in which they discussed the goals of the language. (You can read the white paper at http://www.java.sun.com/docs/white/langenv.) The goals were that Java should be

• Simple, object-oriented, and familiar

• Robust and secure

• Architecture-neutral and portable

• High-performance

• Interpreted, threaded, and dynamic

Microsoft .NET fulfills these same goals. The only difference is the underlying platform ”Java-language programs built using the Java Development Kit (JDK) execute using the Java Virtual Machine (JVM), while .NET programs execute using the common language runtime. Object technologies have advanced since the Java language was first introduced, and the common language run ­time actually provides much more functionality than the JVM does. The JDK has attempted to keep up with the rest of the world while remaining true to its roots by having additional optional packages and specifications appended to it ”for example, the JavaBeans framework that provides a model for building and consuming components . Further extensions include Java 2 Enterprise Edition (J2EE), the specification of a framework for building and deploying enterprise applications.

With .NET, Microsoft has its own infrastructure that uses the features of the underlying Windows platform. Microsoft made the strategic decision that even though Visual J# would implement the syntax of the Java language, it would not support many of the additional specifications. Instead, you can use the enterprise features of .NET directly from J#. This chapter describes how Microsoft has retained the integrity of most of the semantics of the Java language while allowing you to access the features of .NET, and how the functionality of J2EE is matched, or in some cases exceeded, by that of .NET.

Visual J#, Visual J++, and the JDK

When Microsoft released Visual J++ 6.0, the current version of the JDK was 1.1.4. Microsoft implemented all the standard JDK 1.1.4 class libraries except Remote Method Invocation (RMI), and it offered some additional extensions for integrating with the Component Object Model (COM), Microsoft Windows, DLLs, and Microsoft Windows Foundation Classes for Java (WFC) ”Microsoft's own Windowing library.

Although the Java language has been stable for the last few years , some additions have been made to the standard class libraries, notably Swing, which is an updated GUI framework that replaced the Abstract Window Toolkit (AWT) of earlier releases, and Java Interface Definition Language (IDL), a tool that allows you to define Java objects that communicate with CORBA using Internet Inter-ORB Protocol (IIOP). Many of the existing libraries, such as those that handled security and serialization, were also modified and extended. Microsoft had already addressed these areas with its own extension libraries, so it decided that there was no need to support the additional libraries and updates. Visual J++ 6.0 thus retained the JDK 1.1.4 libraries throughout its lifetime.

In Visual J#, Microsoft provides independently developed class libraries that support many of the features of JDK1.1.4. For compatibility with Visual J++ 6.0, Microsoft has also kept many of the existing extension classes. The primary packages that are no longer supported are sun.io.* , sun.net.* , and netscape.* . There is some overlap between the extension class libraries of Visual J++ and the .NET Framework Class Library. If you have a choice, you should use the .NET Framework Class Library when you build new applications with Visual J#. For example, you should now use Windows Forms rather than WFC.

I l @ ve RuBoard