The pros and cons of JDK 1.1

JavaSoft, Java developers describe the key benefits and shortcomings of the long-awaited Java software toolkit -- and discuss the pain of moving from 1.02

Sun Microsystems recently released version 1.1 of the Java Developer Kit to a world of application developers thirsting for increased speed, stability, and security in the APIs used to create Java apps. Weighing in at nearly 700 classes, and boasting significant security, structural, and performance enhancements -- as well as JavaBeans support -- the new JDK release enables programmers to now write applets and large-scale applications that conform to the Java core 1.1 API (and its JavaBeans 1.0 APIs). Initial interest in the upgrade has been significant: Within three weeks of the JDK 1.1 release, developers downloaded more than 220,000 copies of the new toolkit. The immediate obstacle to its full acceptance, though, comes from browser hurdles currently being addressed by such heavyweights as Microsoft and Netscape.

"What we're trying to do with 1.1 is raise the bar," said Eric Chu, product manager for the JDK. "We want to make it easy for people to write fuller, larger-scale applications. We are evolving Java to make it mature enough as a platform that people can write everything from Web-based applets to enterprise-wide applications." (For the complete text of JavaWorld's interview with Eric, see the sidebar Raising the bar with 1.1).

"The main things that turn me on about [JDK 1.1] are the JDBC, the security enhancements, and the JAR format," commented Adrian Scott, chief executive officer of Aereal, a VRML and Java development start-up (www.aereal.com). "In the long term, RMI and object serialization are going to move Java development in a very positive way, especially in combination with JDBC for some really wild distributed apps."

Heavyweight features, lightweight bugs

"We've been using the JDK 1.1 for several months," said Arthur van Hoff, chief technology officer for Marimba. "It certainly is a big step forward in performance, memory efficiency, and functionality. Despite some minor glitches, I'm very happy with it so far. Class unloading, for instance, makes Castanet [Marimba's "push" software] a lot more memory efficient."

"We've encountered a number of glitches associated with JDK 1.1," reported Geoff Vona, the KL Group's (www.klg.com) technical product manager for JClass Chart. "The FCS version contained a gratuitous name change, getId to getID, that broke our code and caused considerable embarrassment for us with our beta testers. And the validate() call in Container makes peer calls that cause the background of the peer to be blanked out. But the transition from JDK 1.0.2 to JDK 1.1 was, for the most part, a smooth process. We love the new event model, as it is very similar to the callback mechanism we introduced in our first Java product back in June of last year."

For the record, the new features in the JDK 1.1 include:

  • The JavaBeans 1.0 component architecture
  • A new AWT event model
  • Inner Classes
  • Internationalization
  • An enhanced I/O package
  • The Java Archive (JAR) file format
  • Java Database Connectivity (JDBC)
  • A Math package
  • Object serialization
  • Reflection
  • Remote method invocation (RMI)
  • Improved security (with those long-promised signed applets)

Also included with the JDK 1.1 are networking enhancements and a score of miscellaneous new or improved classes and protocols. Thrown in for good measure, 1.1 also includes a new wrinkle called the Java Native Interface, or JNI (more on this in a moment).

According to Sun, the JavaBeans APIs (which have been integrated into the JDK 1.1) "take interoperability a major step forward -- your code runs on every OS and within any application environment. A beans developer secures a future in the emerging network software market without losing customers that use proprietary platforms, because JavaBeans interoperate with ActiveX, OpenDoc, and LiveConnect." The JavaBeans Development Kit (BDK) 1.0 final release, which allows developers to create reusable software components, is also now available for downloading from Sun. The BDK currently contains the BeanBox test, example bean source code, bean demos, and a JavaBeans tutorial.

"We're doing a lot of work with beans," commented KL Group's Vona. "The BDK beta releases were not great. The BDK documentation was sufficient for simple beans but not sufficient for advanced bean development. The lack of support for indexed properties is a big problem. It is not clear how sub-objects should be exposed in a bean. Introspection and reflection are very slow. On the plus side, [JavaBeans] in general is what we call `good magic.' The serialization works well. And the beans users mailing list has been very helpful."

The Java Security API is designed to allow developers to incorporate both low-level and high-level security functionality into their Java applications. Java Security includes APIs for digital signatures and message digests. In addition, there are abstract interfaces for key management, certificate management, and access control. Specific APIs to support X.509 version 3 certificates and other certificate formats, as well as richer functionality in the area of access control, will follow in subsequent JDK releases. Version 1.1 also provides a tool for signing JAR files. The appletviewer allows any downloaded applets in JAR files that are properly signed by a trusted entity to run with the same rights as local applications.

In a related development, at the Spring Internet World tradeshow in Los Angeles JavaSoft announced the release of the Java Runtime Environment (JRE), which should be available for downloading by the time you read this. According to the Sun business unit, the JRE is a compact, flexible solution that developers can bundle within their applications to remove dependency on native operating systems. Using the JRE, developers can immediately begin shipping and deploying Java applications using the latest JDK 1.1 features.

Making the transition

"Growth is painful," commented Philip Meese, the director of technical services for Mercury Technologies (www.mercury.com), a Wall Street enterprise-solutions developer. "Although there was the original promise that the JDK API was frozen, anyone who worked with the first release of the toolkit realized that it would be impossible to effectively solve the problems of the JDK without breaking the API. This is what will make the transition to JDK 1.1 painful."

"I'm enthusiastic about the upgrade," said Bob Page, CTO of Accrue Software, a maker of site analysis software (www.accrue.com). "The stability and the speed are huge improvements. The feeling one gets is that everything feels a lot zippier. The ability to print is also very important to us. And I think we are going to take advantage of features like RMI and the JAR stuff right away."

"We're planning immediate support for the 1.1 features -- especially JavaBeans -- in our Cafe, Visual Cafe, and Visual Cafe Pro products," commented Mansour Safai, general manager of the Internet Tools division at Symantec. "On the negative side, I think it would have been good if there was a JIT included. Even though 1.1 is fast, a lot of developers would like to get decent speed by default with the JDK. Also, I think the AWT is still fairly limited. But it looks like there are a lot of 100% Pure Java class libraries coming. I would prefer if one was really adopted by JavaSoft in the JDK though. I would hate to see a class library war that confuses developers about what they need to use."

"Programmers will need to learn the new AWT event mechanisms to replace the old ones," Meese added. "Existing code will have to be rewritten to work under 1.1. On the positive side, Sun has made good on most of its promises for the features in 1.1. It is starting to look like a real programming environment, with the mechanisms required to support Java as a language capable of such complex applications as electronic commerce. The host of new features -- such as improved color handling, digital signatures, support for mouseless operations, and JAR format support -- begin to form a real foundation for sophisticated network-aware application development."

Sun says it is planning a follow-on release, to be called version 1.1.1 (due out in time for the JavaOne conference in April), so it is clear that the company expects users to encounter some bugs and incompatibilities in the initial upgrade. The JDK team asks that you post bug reports to a dedicated section on its Web site.

"We've filed a number of bugs that were not fixed in 1.1 but which will be fixed in 1.1.1," added Marimba's van Hoff. "None of them are very serious -- mostly related to the AWT. Apart from that, it seems to pretty much work fine."

Browser skirmish

The big snag to the immediate deployment of JDK 1.1-based apps is the temporary lack of support from the major browser vendors. Currently, only Sun's own HotJava 1.0 browser (due to FCS on March 24) will run apps created in version 1.1. Netscape already has said that it will embrace 1.1 in its Communicator final release, due this spring. Microsoft is on record as saying that it will not be able to support 1.1-based apps at least until Internet Explorer 4.0 ships this summer.

The problem for Microsoft lies in the aforementioned Java Native Interface. The JNI enables developers to write Java native methods and embed the Java VM into native applications, providing binary compatibility of native method libraries across all Java VM implementations on a given platform. Until now, Microsoft has been employing its own solution to the problem of a platform-specific interface, called the Raw Native Interface (RNI). This perceived conflict between the RNI and the JNI has touched off a controversy that has already been widely reported in the computer press. (See the Resources section of this article for links to several of these stories.)

"The JNI enables Java applications that have a need to access native code to do so consistently across all VMs," said Sun's Chu. "NMI was a good first attempt, but it was not comprehensive enough, which caused the various VM vendors to go off and start doing their own thing. As part of our effort to ensure write-once-run-everywhere, it became very clear to us that we needed to complete our work on this, so that an application could consistently access native code across all the different platforms."

According to Sun, applets relying only on APIs defined in version 1.0.2 of the JDK but recompiled for version 1.1 should run now on the major browsers. Note, though, that JavaSoft emphasizes backward compatibility has not been extensively tested, the company cautions, and so cannot be guaranteed.

"Both Netscape and Microsoft, as far as I understand, have publicly stated that they strongly endorse 1.1," added Chu. "So we'll see what will happen."

"I think Microsoft did the right thing in doing what they thought was best for their platform, in providing their own native interface," Accrue's Page said. "But I hope they'll eventually use the stuff that Sun's provided. I think that if they step back and look at it from the bigger picture, they'll have to concede that JavaSoft [with the JNI] has done the right thing, too."

"My advice to JavaSoft is, from here on, to take the 1.1 as it's defined now and make it very fast and very stable," added Symantec's Safai. "That's really what developers want for writing great apps with Java. Also, definitely do not get into a war with Microsoft or anybody else. Above all, we don't want Java to become as big and complicated as C++ or its class libraries. The most beautiful thing about Java is its simplicity, as it makes it attractive to a variety of programmers out there."

No matter what occurs on the browser front, version 1.1 of the JDK clearly marks a major milestone for Sun. As a development environment, the new toolkit promises to be a more mature place to do business. If you work with Java, development childhood is nearing an end. Now anyone, from the serious student to the advanced ISV team leader, can feel at home in a sandbox that is rapidly turning into a seaside community.

A regular JavaWorld correspondent, Kieron Murphy is a managing editor at EarthWeb.Net (earthweb.net), the home of Gamelan (www.gamelan.com), Sun's official directory of Java resources. He has previously served as managing editor at the Java Report, the C++ Report, and the X Journal.
Related:
1 2 Page 1
Page 1 of 2