by Claude Duguay and Patrick Sokolan
From the original promise of a portable, secure, robust, network-ready language, Java has become the de-factor platform for Internet development. What’s good for the Internet is good for an Intranet, so numerous applications are being or have been ported to make them web-ready. Today, you can find Java virtually everywhere. Rare seems the platform that doesn’t support it. Most offer a choice of virtual machines. Java runs on small devices, mainframes, televisions, personal computers, servers of every kind, embedded or otherwise.
The open community process had brought ideas to fruition. The standard APIs are so encompassing that few software problems cannot effectively be addressed directly in Java. On rare occasions, native code is required, but JNI provides an effective gateway. Where special graphical capabilities are required, Swing, the 2D and 3D APIs are ready. The J2EE umbrella brings everything from database access to dynamic page control, object-relational mapping, directory services and high-performance solutions.
The path ahead is enticing. So much so, that for the first time this year, studies announced that more job postings included Java experience as a deciding factor than other language in the US market. The surveys tell us that most of the Fortune 2000 companies are now doing Java development in their operation. Industry watchers tell us the money is overflowing and the prospects look bright.
All the evidence points to success. JavaOne has grown to more than 25,000 attendees. More trade shows center around Java than ever. The hype is still there but the facts far outweigh the propaganda. Java success stories abound. Whole industries focused on building Java tools, providing training and consulting have emerged.
Programmers love Java. In fact, it’s rare to meet anyone who’s worked on a project using Java who didn’t decide they preferred it to other languages. Bring the latest ideals into play - things like Patterns, UML, Refactoring and Extreme Programming - and the stage is set for some serious innovation and enjoyable times.
Java is clearly unique. Never before has a programming language crossed platform and operating system boundaries so effectively. Because of this, Java is already dramatically changing the world. Before Java, it was ludicrous to think that we could bridge platforms using proprietary approaches to language development. Every time we tried, the native extensions got in the way.
Simplicity is the key to making technologies ubiquitous. X.500 was a great idea that tried to do too much. It failed. LDAP, a simplification of X.500, was virtually an instant success. SGML tried to deal with endless document structure variants and failed. XML, another simplification, was readily adopted by almost everyone. These success stories center on simple designs that meet the base requirements instead of trying to do everything at once.
Another example of an over-designed (by committee) solution is CORBA; it tries to do too much. Virtually everyone who’s deployed CORBA solutions has used only a subset of the specification and usually had to applied proprietary extensions to make things functional. The net effect is a thousand CORBA variants, few of which are able to communicate with each other (though things are admittedly improving).
The most fundamental difference between Java and earlier languages is that Sun managed to get most of it right, successfully implementing the 80/20-rule. Other languages have more of a 40/60 ratio, failing completely in areas that the language was “not really designed for”. Java tends to address a much broader set of problems with very loose coupling to the environment.
To put things in perspective, we’ll take a quick look back at a few Java campaign promises and significant events from JavaOne over the past few years and see which predictions were prescient and which were nothing more than unfulfilled promises.
John Gage had a few things to say back in 1996 at the first JavaOne conference. Quoting Arthur van Hoff with, “Arthur would say the mantra of the design group: ‘If you’re going to do it, do it right.’ And that led to each of the simplifying decisions in the language design”.
On the same subject, “There’s a second maxim. Avoid gratuitous difference, because we’re aiming for ubiquity. And that little demon - that little Steve Jobs that lives in all of us – ‘I can’t make money unless I make it different,’ you know, you’ve got to bat that demon down.” These were the early keys to Java’s impending success. “We’re trying to build something so that it’s ubiquity on the bottom, and innovation up above.”
There’s been remarkable pressure over the years from many different areas (notably Microsoft, IBM, HP and a few others), which could have taken Java down a different path, but Sun has managed to successfully resist proprietary changes to the fundamental Java design and kept the core true to this early vision.
Given the unflattering reference to Steve Jobs, it’s a little ironic that he showed up at this year’s JavaOne to promise that the Mac OS10 was going to be the best Java delivery vehicle in the world.
Tim Berners-Lee, Director of the World Wide Web Consortium, Laboratory for Computer Science at MIT hit the mark with a couple of comments.
He said, “I find it kind of interesting that object-oriented programming became viable when it went global. Hypertext was around a long time before the World Wide Web, but when those Hypertext links could only point somewhere on your local disk, it just wasn’t very exciting. Making it go global with the Web, suddenly made it very exciting.”
And, “Object-oriented programming in a global environment is suddenly very exciting when you can inherit from something miles and miles away written by someone you don’t know, from whom you’ve only just found the documentation, but whose home page you’ve read.”
These are insightful comment. Without the globalization effect of the web, and Java’s network-readiness, the Java adoption curve would have looked a lot different.
Tim also though that “If you want to compile that COBOL down to Java byte code and send it across the Net; then, no, nobody’s going to object. That’s fine. We’ve got a great flexibility point there, so we’ve got flexibility between the programming language and the byte code, and that’s very interesting.”
Although it’s certainly possible and interesting that you could compile COBOL into byte code, there are too many proprietary native elements in predecessor languages to make this an effective choice. What’s more, without the object-oriented mindset, the resulting code degrades into a giant main method with little to offer in the way or reusability or maintainability.
A final comment by Berners-Lee: “So bit by bit the new Java classes they’ve brought out so that you can run Java applications and Java Applets in a lightweight environment where you don’t need a heavy operating system pretty soon-are replacing the operating system. You really don’t need the operating system.”
OK, so we’re not quite ready for this just yet, though this statement might be more accurate in the information appliance market. As of today the operating systems market is intact and in no danger of being subsumed by the Java platform. To the OS companies, Java remains just another programming language, though certainly one they now feel compelled to deliver on their platform.
Dr. Alan Baratz, President of JavaSoft, had this to say in 1996: “I would like to make a set of announcements this morning. These include: the JavaOS, the new HotJava product, enhancements to the base Java developer kit, a project we call ‘JavaBeans’ (I didn’t come up with the name), and then our new on-line Developer Support Program.”
JavaOS appears to have been a failure, a good learning experience, but little more at the moment. In fact, it looks like the better alternative is a small Linux kernel with a JVM sitting on top of it. HotJava is a good proof-of-concept, but never realistically a commercial browser.
JavaBeans, on the other hand, are a fundamental improvement to the way we write software. Of course, no one knew back in 1996 that adoption would take so long. Even today, Enterprise JavaBeans are still in need of a few fundamental improvements. The earlier JavaBeans, introduced in that keynote, are still waiting for a forward-compatible serialization format.
Baratz continued to say that “Finally, there’s internationalization. I had the opportunity to visit Japan about two weeks ago, and the single most important message that came from every one of those meetings was internationalization and localization. This work is also well underway.”
This was an excellent harbinger of things to come. At this year’s JavaOne the international presence was clear, with about 50% of attendees from outside the country. The internationalization and localization support in Java is second to none and exemplary in so many ways. Initial Unicode support in the language was the key.
Scott McNeely is still making promises, but in 1996 he was saying: “We’re not trying to replace the PCs absolutely. There’s plenty of time for that.”
We haven’t noticed any slow down in PC sales recently. In fact, if anything, Java probably played a role in increasing PC sales. There were substantial incursions into what used to be firmly held native application spaces by cross-platform Java solutions in the rush to Internet-enable software, driving down the barrier to entry for high-end applications that only ran on bigger machines in the past.
Another comment from Scott: “The best way to get press on this network terminal is to call it a $500 terminal.” Unfortunately, a $500 terminal is still a terminal, not a PC.
The big story was that “Corel is doing the WordPerfect Office Suite in Java.” This was definitely an interesting story. It teaches that porting to Java without giving careful thought to the architecture of your application is not to be recommended.
Corel made incredible investments in programming time and effort only to fail in the market as an early adopter. Java just wasn’t quite ready for sophisticated GUI applications. StarOffice has since proved that Java is more than suitable for developing a complete office suite, so Corel’s idea was right on the mark, but the execution was poor and when the going got tough, they just didn’t seem to have the stamina.
McNeely was driving for adoption “Cool! It’s time to start rewriting the legacy apps in Java.” Great notion! But most legacy databases have still not been replaced. Java and EJB-based applications have been installed in parallel with the legacy systems; delivering newly required feature sets to customers but rarely displacing the existing investment. This is largely caused by the sad state of the database schemas in these systems and the difficulty in porting so much existing functionality without loosing important features in the process.
It turns out to be easier to leave the monsters in place, bring up parallel Java applications, which access these databases, moving the legacy data into a new structures over time. This approach prevents significant downtime or outages to the legacy systems, which are typically mission-critical implementations. The objective remains, but the timeline is not so immediate.
And here’s the key phrase: “Write Once Run Everywhere.” We all know this one. In development we call it “Write Once, Test Everywhere” and in operations we call it “Write Once, Tune Everywhere”. This is a good problem to have, compared to the previous alternatives.
The portability is real, and both the authors can speak from experience, including projects that moved large Java applications across major platforms with minimal effort. One of these was a 150k-line EJB solution that was moved from one application server/database/operating system to another completely different set in only 1.5 man-days.
It’s remarkably satisfying to go to a vendor and say “Oh Yeah… It runs just fine on this other platform! Perhaps we can go give the same demo to my customer, who also seems to like buying your products, just to see what they think”. After a statement like that, the level of vendor support seems to go up dramatically.
Swing was the word in 1997. Said James Gosling: “It will have a rich set of pre-defined components, will be fully customizable, will simplify commercial GUI development, and will create an open component market. All the GUI components will interoperate. Programmers should be able to switch the look and feel of any GUI back and forth, from Mac to PC to whatever.”
Most of this is true but the open component market is just starting to emerge and hasn’t been as successful as these statements imply. With the release of Java 1.3, Swing is almost as good as it gets. The secret to Swing’s success is that it doesn’t force a non-native look-and-feel on the user. Instead, it offers this as an option, succeeding where other cross-platform GUI solutions have failed.
Goslin also spoke about PersonalJava and EmbeddedJava. “EmbeddedJava is designed to shrink memory usage – it’s for small devices where the byte code is much smaller and ROM and RAM requirements are smaller. EmbeddedJava will also be useful in products such as industrial controllers, pagers, routers, switches, or any device that requires less than 0.5 MB of ROM.”
Another important announcement was the”100% Certification Program”. Unfortunately, the definition of 100% Java is too loose to be useful. How can you call anything “pure Java” if the standard assumes that Java wrappers to native code are sufficient? This approach defeats the purpose of certification and makes this claim a failure.
Remote Method Invocation arrived in 1997, introducing Java serialization and enabling remote object calls across the Internet. This was clearly one of the many little things that make Java so big.
In 1998 they were claiming that that the “’Write Once, Run Anywhere’ promise actually works.” Sorry. It’s still Write Once, Test and Tune everywhere. But we’ll take that over any alternative.
Goslin was saying, “But then, with 1.1, there are all these JITs that have come out.” This is both a curse and a blessing. In time, the implementation issues will dissolve but there are still sporadic problems, depending on the vendor and platform you run on, especially in multi-threaded solutions. Still, this was a major step forward in Java performance and made a huge difference.
The big story was that the “International Standards Organization recently approved our submission of the Java technology specifications.” Unfortunately, this was later withdrawn.
Of course, this is a heavily debated topic, so we’ll make the inflammatory comment that we think its good that Sun has held the reigns so far. They’ve implemented an open process that’s responsive and community-driven. Java is not strictly an open standard but Sun has acted benevolently, making the process successful. With a clear owner, they’ve avoided the design by committee problem (Don’t write about this, it’s just our opinion).
This one was optimistic, “The way Java JumpStart works is as an enterprise IS organizations you can purchase that on the CD and install it on your servers. All the VMs will go on to each of your servers. You then use Project Java Activator in conjunction with your Java application.” Sadly, automatic writing to any Microsoft Platform is fraught with danger. Given the market share, JumpStart adoption never got off the ground.
RMI/IIOP was introduced as the communications substrate and the Java Naming Directory Interface (JNDI) was another home run for Enterprise Java. Enterprise JavaBeans were introduced for the first time, as a technology preview, in 1998. This was one of the most significant contributions from Sun, solidifying cross-platform interfaces rather than inventing new solutions.
In 1999 the focus was on Server-side Java: “I also see us focusing in on the server side.” They said. Sun may have moved over to the server side, but for developers it was an all out stampede.
Jini was introduced – a truly revolutionary technology, possibly as important as the birth of IP. Jini augments the transport layer by allowing services and devices to find each other on the network. Vendor support in the device arena was very quick and Sun focused on that angle, but it took a while for developers to see the benefit to software services. This is where the real power of Jini lies. The number of Jini success stories at JavaOne 2000 should be proof enough. If you’re a skeptic, just wait and see.
Sun had a deal to spread Palm Pilots throughout JavaOne in 1999. You could buy them for $200 a pop, so they were literally everywhere. The KVM made it possible to write Java applications for an information appliance and this was the talk of the town. The K Virtual Machine was the right train, on the right track, in need only of a little more horsepower.
In 1999 J2EE gained new ground. Developers that used EJB session-managed persistence got instant value. Those using container-managed persistence continue to struggle. If deployment used a well laid-out database, it worked with only minor tuning. Promises in the legacy database arena remain unfulfilled.
JMS was also introduced in 1999, a great idea still waiting for maturity, and another successful specification that defines an interface rather than a given solution. It’s difficult to distinguish good vendors from bad right now, hard to figure out how to tune their implementations and unclear what they greatest strengths and weaknesses are. For all that, JMS is a winning technology, still waiting for the large applications to force vendors to handle truly intensive load conditions.
This year the focus was on adding value to existing technologies. Most of the sessions centered on J2EE solutions, GUI development and Jini success stories.
Of special note was the introduction of Jiro, a distributed management infrastructure that takes advantage of Jini to get the job done. Jiro is a layered solution that lets you plug in existing protocols and management tools, tying things together in significant ways. This is a technology to watch, though it’s too early to tell how successful it will be.
The announcement that, “J2EE will run on any other app server.” Was right., though it will run better on some, and this is definitely what you want. Pick the right vendor and you’re in heaven. Pick the wrong vendor and you can always move to another. Just stay away from any vendor-specific solutions.
Linux support was ubiquitous. The only drawback here is the addition of a massive user community, but then that’s just the kind of problem you want. Tim O’Reilly was there to spout the virtues of open source and Sun donated many of their licenses to the Apache group. They even announced that they would make a couple of their recent acquisitions open source, including Forte and StarOffice, both of which are very significant applications.
So where will all this lead us? It’s our turn to gaze into the crystal ball.
Ubiquitous, cross-platform, easy to use, robust, secure and fast, Java is here to stay. Java addresses real-world issues with working solutions in the marketplace, so there are plenty of opportunities, money and enjoyable experiences ahead.
The future holds more, new Java-enabled devices.
If you think of the cost spread, you’ll realize that for every one or two thousand dollar PC you own, you could easily afford a handful of smaller devices. Embedding Java in appliances, vehicles and peripherals is inevitable. Though it remains unclear what the exact manifestations will look like, we know without question that Java plays a role in all of these markets. It also plays a role at the other end, in satellites, aerospace solutions, super-computing and more. In short, Java is as close to a shared view of software development as we’ve ever come.
This shared view is what makes it possible for developers to work at a logical abstraction level, typically forgetting about the physical aspects of what they program. In practice, of course, you must know your audience and tools to be effective, but a Java developer working on PCs today is a great candidate for both PIM development, and super-computing development. This has a huge impact on our economy, since it will become easier to find skilled people to fill these niches and the demand will continue to grow exponentially. By having a common vocabulary, portable tools and an eye on tomorrow, Java programmers really do make a difference.
Other than the endless array of devices Java can run on, there are new possibilities, which have only been peripherally explored in preceding technologies. Jini provides a true plug-and-play solution. Distributed computing is a real solution to our scaling dilemmas. Remote management technologies are increasingly sophisticated, especially with the introduction of Jiro to support distributed Jini-enabled service management.
The world of tomorrow is more organic that the current times suggest, replete with software that’s self-healing, autonomous, mobile, more intelligent and fault-tolerant. It seems likely that we’ll find ways of doing things more dynamically and adaptively in the future. We’ll follow the natural path, putting myriad small solutions into the network ecology to interact more effectively in the quest to provide solutions. The network is merely the current frontier, likely to transform in unfathomable ways over time.
The future beckons us to invent the solutions that science fiction writers have imagined over the centuries and more that we simply can’t imagine today. What we can say is that the future will be influenced by today’s Java experience. The visionaries of our time, the leaders and thinkers in this new renaissance are shaping the world in significant ways. Without doubt, computers, software and the Java programming language are responsible for many of the fundamental changes we see in the world, radically changing our ability to automate and invent new forms of entertainment, improve the quality of life, empower individuals, and solve a number of previously unapproachable problems. We are building the future and Java is central to our mission, to make it a better place for everyone.
This is the promise of Java: To be the ultimate foundation for truly usable and re-usable software. Five years and counting, Java is stable, ubiquitous, cross-platform, fast, effective, easy to use and even fun to develop in. What more could you ask for?