HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

I'll be the first to admit I was a little reluctant when JDJ approached me about reviewing the newest release of Sun's Java 2 Standard Edition platform. It's a little like asking a Jim Morrison fanatic to review the Doors Greatest Hits CD. Since I spend most of my days working and thinking in Java, I find it a little hard to be truly objective about it. (And it's even more difficult to choose which topics are worthy of inclusion in a review!) Nevertheless, the Java 2 platform is jam-packed with critical technologies for building enterprise-class applications. Sun has released new versions of both the Standard and Enterprise editions, and in this article I'll be taking a brief look at them.

Java 2 Platform, Standard Edition 1.3
Over the past 12 months much of the focus has been on the use of Java as a server-side technology. Many application developers have shifted their focus toward using Java as a technology for generating XML and HTML applications to the browser. Although this trend has certainly garnered a lot of press, armies of developers are still using Java to build client applications as well. The focus of the Java 2 Platform, Standard Edition 1.3 release is heavily weighted toward performance gains and improved deployment options for client-side applets and applications.

This is an important area of improvement for Java. Most of the enterprise hardware and software vendors have been migrating to Java as a platform over the past several years. Enterprise vendors have historically supported multiple platforms with their applications. There were many inconsistencies between applications on these different platforms because vendors were forced to code at the operating-system level. The version of any given program on Windows was often very different from its counterpart on UNIX in terms of both functionality and user interface. The advent of common "platforms" of functionality such as OSF/Motif solved part of the problem, but inconsistencies between platforms were still the order of the day. The Java platform has been a unifying umbrella for these enterprise vendors. Java provides a consistent set of interfaces to the operating system and a common user interface layer across multiple platforms.

Consider the case of Oracle Corporation. Oracle8i comes equipped with a database management utility in the form of the DBA Studio. Since it's written in Java, database administrators have a standard, consistent interface with which to manage databases, regardless of the platform. Countless enterprise vendors have adopted this technique of using Java Applets and Applications as the standard deployment platform for what I call rich-client applications.

Technology enthusiasts tend to paint things with broad brushstrokes. When Java first appeared, we jumped all over ourselves to build client applications using applets. Then, when we realized there were some potential issues with this approach, we went in the opposite direction - lock, stock and barrel. The truth is, we need client-side Java and server-side Java. While Java Servlets may be ideal for developing dynamic HTML applications, they don't offer a rich enough user interface to deliver an application such as Oracle's DBA Studio. As usual, we were both right and wrong about client-side Java.

The official Reviewer's Guide for the Java 2 Platform, Standard Edition v1.3 release highlights five different classes of improvement (four of which apply to rich-client development):

  • Performance
  • Web deployment
  • Interoperability
  • Security
  • Development productivity

Sun promotes the J2SE 1.3 release as the fastest release of the Java platform thus far. One of the major complaints with rich-client Java applications has always been performance. Operating system and user-interface independence are important goals, but inferior performance is a heavy price to pay for such portability. Sun has included a new production version of their HotSpot technology into J2SE that improves the performance of rich-client applications. They've also made strides in optimizing and tuning the J2SE class libraries for faster execution, improved application start-up and reduced resource (memory and disk) usage. While Sun makes official performance claims regarding HotSpot, the best resource for more information on performance is the Java Developer Connection forum on their web site. The general impression I got from scanning the forum entries was that developers have found HotSpot extremely beneficial for improving performance - especially for JDBC-based applications. While HotSpot was an optional add-on for previous releases of the SDK, it's the default JVM for 1.3. The primary performance improvement technique within HotSpot is the dynamic analysis and compilation of critical portions of your code - thus the name HotSpot.

Web Deployment
Sun has also made some improvements in the area of Web deployment for when you need to deploy rich-client applications using applets. J2SE 1.3 supports the concept of applet caching. Frequently used applets can be cached locally on the desktop (without violating any of the security mechanisms). The applet cache is maintained separately from the browser cache with the J2SE, which ensures that applets won't get flushed from the client cache unless the applet itself is changed on the server. Applets can now have optional packages included as part of their definition, and these additional APIs can be downloaded (and installed) as necessary when the host applet is run.

J2SE now sports a production version of the CORBA IDL compiler along with support for RMI (Remote Method Invocation) over the IIOP (Internet InterORB Protocol). This is an important consideration for linking Java applications to preexisting code that may have been written in other languages, such as C or COBOL. In this brave new world of application interoperability you may find the need to link your newfangled Java applications back into legacy code. While vendors have offered their own extensions for supporting CORBA, the J2SE 1.3 release makes this a standardized part of the Java language.

Security has been enhanced in several critical areas. J2SE 1.3 supports JNDI (Java Naming and Directory API), which allows developers to use directory servers with Java applications. This is an important consideration in making Java part of the overall infrastructure of a corporate application. Directory servers and JNDI offer you the ability to implement single sign-on services for applications and consolidated access to resources such as print and file servers. J2SE 1.3 also provides new support for RSA signatures and dynamic trust management, and by including standard RSA signatures from VeriSign and Thawte, developers can include RSA security without having to write their own service provider. Equally important is the fact that J2SE 1.3 provides dynamic pop-up dialogs that allow users to validate applet signers on an as-needed basis. This eliminates the need to preconfigure each client machine with a cache of trusted certificates for every applet that could potentially be accessed. This feature will make it a lot easier for software vendors to release versions of their software as applets as well as applications. In particular, certain types of management applications (database-monitoring tools come to mind) can be deployed as applets, allowing administrators to access these interfaces from remote workstations.

One of the most significant improvements in the J2SE is the addition of the Java Platform Debugger Architecture (JPDA). Ideally, developers should be able to use the best-of-breed approach when it comes to selecting Java development tools, application servers and database servers. However, two critical issues have forced developers to consider integrated "stacks" of technology over best-of-breed multivendor solutions. The first issue is the evolution of the EJB specification (addressed by J2EE) and the second is the difficulty in debugging multitiered applications. With the JPDA it becomes possible to debug the various tiers of your application (client, application server and database) within the familiar confines of your favorite Java IDE. The JPDA architecture is composed of three layers as shown in Figure 1.

Figure 1
Figure 1:

The first layer is the JVMDI, which defines the debugging services that a virtual machine must provide. Vendors that include a custom JVM within their products (such as database engines) can expose the VM to developers through the debugging API. Underneath the covers is the JDWP, which provides the format for information and messages that must be transferred between the debugger interface and the physical process being debugged. The last layer of the JPDA is the Java Debug Interface (JDI). Java IDE developers can use the JDI as the language interface for constructing remote debuggers. The inclusion of JPDA within the J2SE 1.3 release offers software vendors the ability to provide for higher levels of interoperability between the various layers of the application deployment topology. Most of the top technology vendors have already endorsed the JPDA architecture and have pledged support for it within their product lines.

Java 2 Platform, Enterprise Edition 1.2.1
While the two editions of the Java 2 platform are tightly intertwined, the focus of the Enterprise Edition is aimed squarely at the middle and database tiers of the application architecture. The J2EE model has been designed and architected to alleviate the problems associated with two-tier applications. The core of the J2EE model is the ability to divide the application work into two parts: business/presentation logic and standard system services. Application developers are responsible for constructing the business rules and presentation logic, while the multitier system services are provided by the J2EE platform.

Ten key technologies are defined as part of the Java 2 Enterprise Edition specification:

  • Enterprise JavaBeans
  • JavaServer Pages
  • Servlets
  • Java Message Service
  • Transactions
  • J2EE Connector
  • JDBC
  • XML
  • JNDI

It's difficult to argue which of these technologies are the most important, but most technologists would agree that EJBs (Enterprise JavaBeans) are at the top of the list. They're at the core of the J2EE platform. While Sun released a new version of the EJB 2.0 specification at the JavaOne conference, the current version of the J2EE platform includes support for the EJB 1.1 specification. The jump from EJB 1.0 to EJB 1.1 has been an important hurdle for application server vendors. Previously, vendors were required to provide support only for session beans, and the implementation of the descriptors for EJBs was somewhat ambiguous. EJB 1.1 requires support for entity beans (persistent objects) and makes use of XML descriptors. Ultimately this is a good thing for developers. The tighter the specification, the more likely it is that vendors will create consistent and compatible EJB products. In the longer term this means that developers should be able to create EJB components using one set of tools and applications - and be able to deploy these objects to servers provided by other vendors. Up until this point the various vendors that have implemented EJBs have tended to add proprietary extensions (particularly in the area of deployment). We aren't there yet, but EJB 1.1 is a step in the right direction, and EJB 2.0 goes even farther.

JavaServer Pages is an extension of the Java Servlet API, and it's one of the most exciting aspects to the J2EE platform (at least in this reviewer's mind). Java Servlets were introduced as a technique for providing CGI-style scripting using the Java language. JSP is a natural extension to Servlets - one that's easier to author and more compatible with popular HTML design tools. JSP provides XML-style tags and scriptlets that allow developers to build dynamic Web applications and keep the presentation logic separate from the content.

JavaServer Pages and Java Servlets provide the front end for browser-based applications in the J2EE architecture. They can be used on their own and in concert with EJBs to create enterprise class applications. While Java language programming can be complex for novice developers, JSPs and Servlets are much less daunting. Furthermore, the design of JSPs lends itself to the creation of prebuilt "tags" (just like XML tags) that can be distributed as libraries. This allows developers to create best-of-breed tags that can easily be used across applications. Although Sun owns the JSP and Java Servlets specification, they have turned over the reference implementation to Apache under a project known as Tomcat. By doing so, they're making world-class JSP/Servlet technology available to the masses. Even if your organization isn't ready to work with some of the other (more advanced) components of the J2EE, you'll be able to leverage the power of JSPs and Servlets.

Listing 1 shows the host JSP, which in turn uses the "include" directive to call the HTML code shown in Listing 2.

Executing this simple JSP produces the HTML page shown in Figure 2.

Figure 2
Figure 2:

The simple elegance of JSPs allows the J2EE to involve more customers and provide a large community of developers with the chance to work with Java in some fashion. The platform independence of JSPs and Servlets ensures developers that they'll have a wide variety of platform choices on which to run their applications. If you've been sitting on the fence when it comes to Java, now's the time to dive in - and JSPs are an ideal first step.

Sun continues to try to strike a balance between innovation and stability with the Java 2 platform. The J2SE and J2EE releases consolidate some of the individual APIs that have been defined along the way - and the resulting platform is packed with innovation. In addition to the components discussed in this article, the J2EE also contains asynchronous messaging with JMS and transaction management with JTS/JTA. Although the J2SE/J2EE specification is somewhat rigorous, there's still plenty of room for interpretation and this is where the real fun begins. All of the J2EE licensees have added their own interesting extensions (where appropriate). So, despite the fact that they're all working off a single standard, each individual product is loaded with unique customizations. I'd recommend that you read through the materials on the Java 2 platform site and take a look at the developer forums before you start talking to vendors about their products.

Author Bio
Jim Milbery is a software consultant with Kuromaku Partners LLC
( www.kuromaku.com), based in Easton, Pennsylvania. He has over 15 years of experience in application development and relational databases.
Jim can be contacted at: [email protected]


Listing 1: helloworld.jsp 

<%@ page info="a hello world example" %> 

<head><title>Hello, World</title></head> 
<body bgcolor="#ffffff" background="background.gif"> 
<%@ include file="dukebanner.html" %> 
<td width=150>   </td> 
<td width=250 align=right> <h1>Hello, World!</h1> </td> 

Listing 2: dukebanner.html 

<table border="0" width="400" cellspacing="0"  cellpadding="0"> 
<td height="150" width="150">   </td> 
<td width="250">   </td> 
<td width="150">   </td> 
<td align="right" width="250"> 
        <img src="duke.waving.gif"> </td> 


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.