This section of the chapter provides a brief overview of Java and J2EE for developers who have a background in Microsoft products. This section assumes that such developers have a typical Windows DNA architecture background and have had limited exposure to the Java platform.
Java, which is developed by Sun Microsystems, is both a platform and a programming language. The Java platform can be categorized in three editions: Java 2 Standard Edition (J2SE), Java 2 Enterprise Edition (J2EE), and Java 2 Micro Edition (J2ME). When I use the term Java in this book, I'm mainly referring to the functionality available in J2SE. When referring to the Enterprise Edition specifically , I'll use the acronym J2EE.
The Java platform shares much of the vision and underpinnings of .NET, ranging from the language itself to the wide use of the term Java and the number of products that have names prefixed with a J to indicate their adoption of Java. Microsoft developers will find many concepts in both Java and J2EE familiar, which is good news when it comes to developing interoperable solutions.
Three key factors differentiate Java from .NET. First, the Java platform targets multiple operating systems, meaning that applications written in Java can be executed on Windows, flavors of UNIX, Mac OS, and others. Today, applications written for Microsoft .NET will run only on Windows and on FreeBSD (via an academic port of the .NET Framework called Rotor). The second difference comes down to the programming language. Applications for the Java platform can only be written using the Java programming language. By contrast, .NET supports multiple programming languages on top of one common language runtime. The third difference is in the way that applications are compiled and executed. With Microsoft .NET, the IL is compiled to native machine-level code by the JIT compiler within the CLR. With Java, the Java source gets compiled to Java bytecode. The Java bytecode is then interpreted rather than compiled by the Java Virtual Machine (JVM), although newer versions of the compiler are starting to implement JIT by default.
The Java platform consists of the JVM and the Java API. The JVM shares some similarities with the CLR, but its main role is to translate the Java bytecode into instructions the native platform can understand and execute.
J2EE is a set of specifications that build on the J2SE platform to deliver a framework for creating and hosting enterprise-level applications. At the time of this writing, J2EE 1.3 has been released and J2EE 1.4 is in draft.
In essence, the J2EE framework comprises many parts that have evolved over the past few years . These technologies include JavaServer Pages (JSP), Server Side APIs (Java Servlets), Enterprise Java Beans (EJBs), Java Naming and Directory Interface (JNDI), Java Message Service (JMS), Java Transaction API (JTA), and many more. Many of these technologies have equivalent mappings to either namespaces within the .NET Framework or to components and elements of Microsoft Windows. For example, similar functionality offered by the JMS API can be found in the System.Messaging namespace in the .NET Framework.
As with the Java 2 SDK Standard Edition, Sun licenses the J2EE specification to vendors who want to create and resell application servers, branded with the J2EE logo via a compatibility test suite. At the time of this writing, these vendors include Sun (offering its ONE application server), IBM (WebSphere), BEA (WebLogic), and others. In addition, open -source implementations are now also available, with JBoss heading the pack.
The latest version of the Java 2 SDK Standard Edition is 1.4.1. The Java 2 SDK can be downloaded from Sun's Java software site ( http://java.sun.com ). It has also been licensed to other vendors who have produced their own versions. As with the J2EE application servers, these vendors include IBM, BEA, and a number of open-source implementations.
The Java 2 SDK contains the APIs and libraries for creating the source, as well as the compiler and binaries for executing these applications. The bin directory of the SDK contains JAVAC.EXE, which is used to compile Java source code (*.java files) into Java bytecode (*.class files).
One main difference with the Java compiler is that each class in Java will generate a separate .class file, whereas in .NET, an assembly can contain multiple classes. Because many applications often contain multiple .class files, the distribution and execution of Java applications tends to rely on Java Archive (JAR) files. In their simplest form, JAR files are collections of compiled Java classes; however, JAR files can contain files of any type, and they have a directory structure. You can use a tool named JAR.EXE, also found in the bin directory of the SDK, to add, list, or extract .class files from a JAR file.
Because classes and JAR files aren't recognized by the file system as executables, to execute a class file (either a standalone .class file or one embedded within a JAR file), you must use the JAVA.EXE tool.
The Java platform doesn't have an equivalent to the GAC in the .NET Framework, but many applications still need to cross-reference and share other classes. To do this, an environment variable named CLASSPATH is used to set a path for all classes that are required for executing an application.
By default, the CLASSPATH variable needs to include the main JAR file (tools.jar for v1.4.1) within the Java 2 SDK and a reference to the current directory (which is notated by a period). Any other JAR files required to execute an application are then added to the CLASSPATH just before the application is run.
For example, if you're developing an application that contains calls to a third-party library, you can adjust your CLASSPATH to include the required JAR just before compiling. This can be done using the MS-DOS SET command from the command line:
SET CLASSPATH = %CLASSPATH%;C:\THIRDPARTY\OTHER.JAR
This will append the OTHER.JAR file in the C:\THIRDPARTY directory to the existing CLASSPATH .
In addition, both JAVAC.EXE (the compiler) and JAVA.EXE (the tool to execute Java classes) accept a “ classpath parameter for including the CLASSPATH variable when they're run. Many Java IDEs will also allow the CLASSPATH variable to be set within their environment.
If you receive a ClassNotFoundException when executing your Java application, check your CLASSPATH environment variable to ensure that all the required libraries are included on the path. In most instances, not having all the required libraries will be the reason why the Java Virtual Machine threw the ClassNotFoundException . This is especially true for J2EE environments where some application servers require references to many libraries in order to run.
Environment variables tend to be used much more for developing Java applications than for developing applications in Microsoft .NET. Because Java applications can be developed to run on multiple operating systems, using environment variables offers a common denominator for setting and controlling the configuration.
Many other tools for the Java platform require other environment variables to be set in order to run correctly. These can include JAVA_HOME , which specifies the location of the Java SDK, and product-specific variables such as ANT_HOME and ELECTRIC_HOME .
As with .NET, the Java compiler can be accessed from the command line to build applications, as you saw a moment ago. In addition, a number of Java IDEs are available from multiple vendors. The combination of multiple application servers and IDEs has produced a number of add-ins that allow deployment and control of the J2EE application from within the IDE itself. For example, you might use a BEA WebLogic add-in for Borland JBuilder to deploy a Web application back to WebLogic.
Given the diversity of both the application server and IDE market, the samples in this book have been designed to be compiled and executed from the command line alone, and all of them have been designed to work with any application server that implements the J2EE 1.3 specification. Before you run any of the samples, I recommend that you include the bin directory of the Java 2 SDK in your System Path ( PATH) variable. (See the "Setting Environment Variables" section toward the end of this chapter for further information.) Including this directory in the System Path will allow you to run the tools in the directory without having to specify the directory name each time.
If you are familiar with Microsoft tools and are looking to view and develop the Java sample code without having to install a second IDE, you can edit all the code using Visual Studio .NET and the Microsoft Visual J# add-in, which is available from MSDN. (Visual J# enables you to develop .NET applications using the Java language syntax.) Using J# for your editing purposes will provide syntax highlighting and IntelliSense for API calls made in versions of the Java SDK earlier than v1.1.4. To build the application, however, you'll need to use the JAVAC.EXE compiler from the command line to run the application in a JVM.
JavaServer Pages, or JSP, is part of the J2EE specification and is a server-side technology for the development of Web applications on the Java platform. JSP technology is based on dynamically compiled .jsp pages and Java Servlets, which is a Java interface that provides server-side processing for Web-based applications. When a presentation tier is said to be based on JSP , the implication is that it's a mixture of JSP pages and Servlets. The terminology in this book makes this implication too.
Many technology options are available for hosting both JSP and Servlets. These options can range from free lightweight engines such as Apache Tomcat to the fully supported, vendor-based J2EE servers mentioned earlier.
Typically, JSP pages and Servlets are developed using one of the many IDEs available for Java, some of which include the ability to graphically develop pages and controls on the fly. A number of freeware and shareware independent JSP editors also exist that can be used to write and test pages. Many of these editors can be found and downloaded after a simple search on the Web.
The scripting elements within both JSP pages and Servlets are created using the Java programming language. At the time of this writing, the latest version of the Java Servlet API is v2.3, and the latest version of the JavaServer Pages specification is v1.2.
The key part of the J2EE specification is Enterprise Java Beans (EJBs). EJBs provide the framework for hosting components in a distributed enterprise environment. As with Component Services, the functionality provided by EJBs can include recycling, state, transactions, method-level security, logging, impersonation, and message queue support.
Without delving into the full specification, I can simply say that the most important thing for a Microsoft developer is to understand the two types of EJBs: Session Beans and Entity Beans. Session Beans are typically used to host business logic, and Entity Beans are used to map data from database tables to objects.
Each type of bean has two subtypes . Session Beans can be either stateful or stateless ” meaning that the state of a Session Bean can be tied to the client for the lifetime of the object. Entity Beans can be managed either by the container (known as Container Managed Persistence , or CMP ) or by the bean itself (known as Bean Managed Persistence , or BMP ). The management of the bean dictates how the code to access the database will be managed. With CMP, the container manages the mapping between fields in the bean and fields in the database. (An application server can contain many containers to host different beans.) A mapping file is used to configure this relationship. With BMP, the process of supplying the code to access the database is left to the developer. The EJB interfaces provide methods for loading, storing, removing, and so on. The developer is then free to supply the code as required.
So, why do EJBs have both CMP and BMP? Each has its own advantages. CMP tends to be easier to configure and maintain because no database code has to be written. The notion of mapping objects to databases, however, can come at a price: decreased performance. With BMP, the performance of the bean is directly related to the performance of the underlying database code that is written. Plus, the developer gets a lot more flexibility with BMP. For example, you could create a BMP EJB that maps against a Lightweight Directory Access Protocol (LDAP) directory or another source that doesn't use a database.
Building an application to run on a J2EE application server can involve a number of steps to ensure that all the required components are deployed correctly. In addition to JAR files that contain a number of Java class files, the J2EE specification defines Web Archive (WAR) files, which are essentially JAR files that contain a predefined structure for Web applications, and Enterprise Archive (EAR) files, which can contain WAR files, JAR files containing EJBs, and other content.
The settings for a J2EE deployment are configured via prespecified XML files known as deployment descriptors . Deployment descriptors are used to instruct the application server how to run the application by configuring services such as security, transactions, and logging. These files can contain settings similar to those found in Component Services. Although J2EE deployment descriptor settings are part of the J2EE specification, some descriptor files are specific to the application server vendor.
I've found the following collection of references and resources useful for introducing the Java language and various elements of the platform.
At http://java.sun.com , you can download the Java 2 SDK and find other links to Java-related information and products.
The http://www.theserverside.com site is one of the most popular Java and J2EE community resources on the Web. Included on the site are news, design patterns, reviews, and discussions around Java and J2EE technologies.
At http://jakarta.apache.org/struts , learn how to extend JSP and implement a Model-View-Controller (MVC) approach using Apache Struts, an open-source framework for building Web applications.
Use http://java.sun.com/products/jdk/awt/ as a starting place to find additional information about AWT and SWING, the Java UI libraries.