The pros and cons of the new Java

Wow. I wasn’t sure what to expect from JavaOne ’97. Last year I loved it, but at the time I didn’t know much about Java and had a lot to learn. This year, I went to JavaOne thinking it would be good for me but also that I might want to skip the Advanced Java Programming- and Java Tutorial-type sessions. I’ve been doing advanced Java programming for the last year now, so what was there to learn? The answer? Everything!

I had been reading about the new APIs, JavaBeans, remote method invocation (RMI), and some of the more recent announcements, but I just didn’t get a sense of the real impact of these technologies until I attended the conference. I needed to see some real demos, and get some of the hard-core facts from the actual developers. Of course, I learn the most when I actually try to use the programming tools. But because of current hardware and project constraints, I haven’t had the chance to try much of Java Development Kit (JDK) 1.1. Another benefit of the “conference approach” to learning is that the presenters (most of them being the original developers of the tools) gave examples of how they expect us to use their tools. I plan to go back through the slides, now at JavaSoft’s Web site (see Resources), and cut and paste these examples into my own code.

I’m not going to dive into the details of any of these new tools and technologies too much in this article. There should be plenty of details to read in this issue of JavaWorld, in JavaWorld‘s JavaOne Today coverage, and from JavaSoft’s Web site (see Resources). But I did come away with some general impressions I thought it would be important to share. Not all of them are positive, and you may not agree with all of them, but remember, these are my opinions.

Be a bean-head or just look like one!

First of all, yes, I feel like a true bean head now. Beans, beans, beans! JavaBeans was one of the central themes of JavaOne. (The other was “100% Pure Java”, but I’ll get to that in a minute.) As I start using Java 1.1, I will now make it a point to develop everything as a bean. This is not hard to do: JavaSoft has made it so transparent that I really don’t have to do much of anything for simple objects. But beans are more than just “cool”.

JavaBeans appear to be the best way to develop true “objects”: objects that can be written to and read from a file, with their implementation code!; distributed objects that can be delivered to other distributed objects anywhere in the world — or even in space. (NASA had a great demo during Jeff Johnson’s keynote!) But, of course, the strength of beans is the ability to “introspect” on beans — find out what they can do, how they can do it, and tie them together visually. It’s clear that non-programmers will be able to “hack” together a variety of powerful applications from some of the many beans that are just now being developed.

JavaSoft and its partners (there were many partners from across the industry) have done a terrific job in the design and implementation of the JavaBeans technology. It’s amazing that they finished this first release so far ahead of schedule. I particularly liked the demo of the HTML Renderer bean (a bean that downloads and formats HTML pages, and allows you to point and click to browse to other HTML documents), linked to the timer and button beans. In a few keystrokes, the presenter combined these three beans, linked events from some beans to functions in other beans, and had a working “kiosk-like” application. This application allowed him to do all the browsing he liked, for 30 seconds, and then automatically return to a default page.

It’s clean, it’s “Pure”

I also got warmed up to the idea of 100% Pure Java (see Resources). Be careful! This is a Sun Microsystems trademark (although I feel like I might slip sometime and use it to describe one of my applications or something). Despite the lousy name, 100% Pure is a very important concept. It goes hand in hand with the Java Compatibility Program (see Resources), and the idea is this: If I develop an application, and it passes the 100% Pure Java test suite, and I have a Java environment (compiler, libraries, and virtual machine), and it passes the Java Compatibility test suite, my application is almost guaranteed to work with that Java environment.

Why is this such a big deal? Well, think of it in terms of today’s most popular native programming environment. One primary chip architecture (x86), and one primary chip manufacturer (Intel) dictate the, I mean, set the standards. If a compiler writer or assembly programmer develops to a particular chip, he or she pretty much knows what instructions that chip can process and how it will respond (with the exception of the occasional floating-point operation, of course). Also, there is one primary API developer for that chip (Microsoft), and Microsoft dictates (there I go again), sets the standards for the APIs. And since, for most of the APIs, there is no competition, a programmer generally can rely on the APIs to do what he or she expects of them. In short, if I develop a Wintel program and don’t try to exploit any weird or overly-complex features, it will probably work on 99.9% of the Wintel platforms out there in the world.

We don’t have that kind of assurance with Java today. Java is supposed to be portable because the Java virtual machine (JVM) is supposed to have been flawlessly ported to a number of different platforms and operating systems. But the JVMs, compilers, and libraries for JDK 1.0.2 and prior versions had insufficient test suites to assure flawlessness. That has changed. Under the Java Compatibility Program, there are now over 8000 tests for JVMs, compilers, and libraries. These tests are supposed to prove, beyond a reasonable doubt, that the Java environment meets the specifications. All Java tools will be expected to meet the specs, and therefore, in theory, all Java environments will be identical.

100% Pure Java certifies an application as having been developed exclusively in Java. No native code is allowed. At first, I thought this was a lashing out against Microsoft and its ActiveX components. But that is really not important at all. What is important is that, if an application is certified as 100% Pure Java, it will run on any Java-compatible virtual machine and library set. I need this! Right now, I have to work around the bugs and inconsistencies between platforms like Unix, Windows, and the Sun JavaStation — and even different VMs on the same platform!

It may be Pure, but it’s not free!

What I don’t like is that Sun expects us to buy 100% Pure Java testing. It has designated a third-party testing agency (KeyLabs, Inc.) the 100% Pure Java Certification center. But KeyLabs will not even release the final test suites to any developer unless they pay the ,100 fine, I mean, fee, for the certification. This is acceptable for companies developing commercial products; let them pay for the stamp of approval on their shrink-wrapped products if they want to.

But I use a lot of free software (like all of the GNU tools from the Free Software Foundation — see Resources). GNU developers from around the world contribute to this extensive code base. As Java tools start to appear, I’d like to know that these products are 100% Pure Java too! But who is going to pay ,100 to certify free software! DTAI (my company) develops Java products both for commercial sale and some for free, under the GNU Public License (GPL). I can probably add “Java Certification” as a budget item toward my commercial products, but I can’t get away with that for the free products. And we also do consulting work for customers with in-house products. But they are not used to having to certify their applications to make sure they will run on all of their Windows platforms. Are they going to want to spend ,100 on this process? I’m sure it will come up in the near future, so I’ll have to let you know.

JavaSoft defines software

Here’s another combination of relief and anxiety. I like standards I can work with. Java, the language, lends itself to developing good, object-oriented APIs, so most of the APIs I’ve seen I can work with. When Sun introduced Java with standard, object-oriented APIs for windows and graphics, data structures, text manipulation, I/O, and networking, I was thrilled. These are the basic building blocks I wanted to see in C++ but never really did.

But now I see JavaSoft taking this API thing to an extreme. I have to admit, it has its benefits. The JVM, language, and API teams are all working under the same roof, under the same authority structure, and they appear to be communicating. Many of the new APIs blend well together. And I would like to see (and I am starting to see) improvements to the basic APIs that were introduced in Java 1.0. But now JavaSoft is starting to define a number of fringe APIs, like the Java Management API, Java Transaction API, Java IDL, and others that could be written in “Pure Java” by anyone. There are benefits to having a standard, but why is Sun setting the standards?

Microsoft sets the industry standard by their own mandate, but is Sun really supposed to be modeling its Java strategy after Microsoft’s? From all of the Microsoft bashing I heard at JavaOne, you would think it’s a bad idea. But the truth is, Sun knows that the Microsoft standards model is a pretty good one, if Sun can get away with it. It gives the company a lot of control, and as long as it doesn’t trip up too much, it might get away with it for a while. In fact, Sun has applied to become an official standards body. (Sun, like X/Open, for example, could become a standards intermidiary for Java. See Resources.) This may or may not happen officially, but it has already happened as a matter of fact, since Sun, with its smart but tough licensing policies, is currently the only Java authority.

JavaSoft report card for 1996-97: A-

Despite my complaints, I have to say, JavaSoft has done an admirable job, technically speaking, with Java this past year. And most of the technology is still free to the developer. However, I am a firm believer that everything should be free to the developer. Us hackers need the freedom to grab whatever we can off of the toolshelf, slap things together, and produce the next “killer app” like Mosaic once was. This is the kind of success I’d like to look forward to some day. Java, and now JavaBeans, will make that much easier for me and for the rest of the world.