Prior to deciding to attend JavaOne the Friday before the conference, I wasn't sure if it would be worth the price of admission and thought that it would be simply a hype-fest of grand proportions.Siskel & Ebert giving JavaOne two thumbs up.
Talking to the people who were administering the conference, I learned that the response was far above what they had expected; the initial guess of 3,500 total attendees was being exceeded and they estimated on Wednesday that they would have to close off pre-registration by Friday. By the time I called around 10:00, pre-registration was already sold out. I had to fly down to San Francisco without a guarantee that I would even get in and register at the door. Sun claimed the final total was 6,000 attendees (which John Gage proudly pointed out exceeded Microsoft's recent web developer's conference). That fact that Sun underestimated the response from the development community says something about Java's popularity.
Of course there was a lot of blatant hype, along with some good humored Microsoft-bashing, and a great deal of expensive design and production that went into the sets in the main auditorium -- smoke machines, billowing curtains behind the speaker's podium (or was it a post-industrial pulpit?), randomly alternating rear-screen projections of the sponsor's logos, sound/light mixing boards that looked like they belonged at a Grateful Dead concert, etc. It made me wonder what a Microsoft developer's conference looks like.
But beyond the glitz there was also a great deal of technical information and excellent questions in the sections of the technical and design tracks that I attended, and even some useful information buried in the mostly "Rah-Rah JAVA!" keynote addresses.
Several things impressed me in a positive way during the conference.
Sun is working very hard on producing encryption and digital signature technologies that will plug in to Java applets to provide such things as cryptographic signatures of applets, SSL for secure socket-level communication, secure commerce with customer authentication and secure payment facilities. Electronic commerce ("Java wallet" was the phrase used to describe their scheme) was mentioned very frequently in keynotes and several technical sessions. Sun intends Java to do all this easily, safely and flexibly, by taking advantage of the language's dynamic loading features and other benefits of well partitioned object oriented programs.
It was also surprising to me to see the number of quite large applications and class libraries that have been written entirely in Java. In fact, the JavaOS itself, announced by Sun in a keynote address and demonstrated on the pavilion floor by both Mitsubishi and Sun, is written almost entirely in Java (including NFS client layer, the TCP/IP networking stack and the ethernet, mouse, and keyboard device drivers.) One vendor even demonstrated a 3D, real-time, VRML based, chat system with all of the client/server communication, 3D rendering and user interface written entirely in Java. Patrick Naughton of Starwave -- at a recent Seattle Java User's Group meeting -- described how they use Java applications for doing real-time billing, database service, and client/server communication, with no crashes in hundreds of days of continuous operation. Java is clearly adequate for producing large, "mission critical" applications and networked services.
Many vendors, including Sun, are positioning themselves as suppliers of reusable code in the form of class libraries. Sun's new HotJava is designed to be a small browser application, supported by a large, reusable class library base. You will be able to license (pricing and redistribution restrictions are still unclear) the HotJava class libraries and use them as the foundation for your own applications and applets.
Finally, I couldn't help but feel that Java really can level the WinTel vs. The World playing field. I'm personally sick and tired of hearing how Unix is going to die because Microsoft holds 85+% of the operating system market world-wide (even though the vast majority of these are single-user, single-tasking, and non-networked computers) and any programmer in their right mind would be crazy to write for anything but Windows.
It also bothers me that Win95/NT are marketed as being "open" technologies, when you can't use Microsoft products on the Internet with your Alpha (unless its running NT), your Linux PC, your Mac, or your Sun. I'd love to be able to develop code that works on all of these platforms (and ones yet to come) without having to waste months learning each and every one of these complicated and vastly different operating systems and windowing architectures.
This is one of Java's central strong points and because of it, the price for programmers has just gone significantly down. And that isn't even considering the money that will be saved when programmers start writing more robust object-oriented programs, reusing code, spending less time debugging and more time designing (gee, now what will the excuse be for not properly documenting your programs?)
There was one somewhat disturbing impression that I got from the conference.
I recently returned from a trip to Australia and Bali. As soon as I left the US, I couldn't help but notice how much hype and noise there is here surrounding computing in general, and the Web in particular. There's Java vs. OCX's for embedded content, Netscape vs. Microsoft in the browser and HTML standards wars, security bugs galore in everything, user's clamoring for the latest browsers (nevermind the risks they face) and jumping on proprietary extensions like they're an escalator to heaven ("Netscape Now!" the icons scream.) The Aussies were telling me I worked too hard and the Balinese were telling me I was in too much of a hurry.
And now, three keynote speakers and several session speakers start talking about the Internet running on Dog Years and Web weeks on the Internet being like seven weeks in "regular time" and the speed at which programmers can innovate now being unlimited.
I've been reading and reviewing several Java books and have found that many are written in such haste that they are either based on already obsolete APIs, are chock full of errors and are so weak on depth and detail that they are barely worth the $30+ dollars they cost. By the time I've finished thoroughly reading them, I've only seen a quick introduction to the basics and the book is nearly out of date. The next book (which may have been written with more care, hence the delay) comes out and adds something the other didn't, but it too will be out of date as soon as Q(n+1)'s set of API's comes out for digital signing, electronic commerce, 2D/3D/Media extensions, etc. and you start the process all over again. With some 100+ books out there right now, a book buyer is hard pressed to even find a consistent comparison, let alone a book that gives them what they need.
My worry is that the rate of change will be so fast and furious that it will be even more difficult than it is now to stay on top of the Java wave and provide the level of support that users demand, while also acquiring the software engineering skills for producing reusable code and actually gaining the benefits promised by object-oriented methodologies. The challenge to management to support the production of reliable, well designed and reusable code is just as great as the challenge to programmers to gain these skills in the first place. Perhaps it is a failure to get this kind of support that prompted many at the conference to jump their current corporate ships and start their own new dynamic companies like John Gage kept evangelizing in his keynote introductions. Trying to live on Internet time may kill Microsofts like the dinosaurs, or it may cause the burnout rate go sky-high.
I tended towards the technical and design tracks, and managed to tape at least the Q&A portions of some (for those interested in listening to the tapes, they are on micro-cassette). I also have the keynotes taped, although Sun is making transcripts and slides available online.
Some of the more memorable things I gained from these talks are summarized here.
It was mentioned in one of the technical sessions that the way packages are implemented and the way the class loader works has an impact on the way your web server's directory structure must be set up. Java source files must reside in a directory hierarchy that matches the package name components (e.g., sun.net.Foo comes from the file sun/net/Foo.class) and that the resulting class files must reside in a similar tree below one of the root directories specified in the CLASSPATH environment variable for the client or server to find them. This has implications for directory permissions and ownerships in a shared-code environment and may get complicated a bit by the way the www.washington.edu web servers are designed. Add to this the fact that class names must match the name of the source file and it makes it difficult to do wholesale renaming or reorganization of Java classes.
Also, the upcoming signature facilities will rely on the package names, so it was hinted strongly that organizations should work on their class name space hierarchy to make sure they can easily organize, share, and sign their classes.
Because of the importance of dealing with these package naming issues, I think we should get a handle on this sooner rather than later (when we have hundreds or thousands of Java files that must be all be reorganized.)
I also see the need to work rather quickly to develop an education and training course on Java (perhaps designed in conjunction with someone from the Computer Science department) to deal with what I think will be a high demand for Java training. Alternatively, we should work with UW Extension to get them to provide a course. My own experience in reviewing books on Java and trying to follow "proper" class and applet design principles has shown me that there are hurdles to get over in doing it "right." I'm spending as much time as I can coming up to speed on Java in hopes of perhaps rewriting some or all of QnA in Java to get around some performance problems with large Perl programs and concurrent access to database files. The conference certainly added to my enthusiasm about such an endeavor.
Finally, I was struck (but not altogether surprised, given Sun's sordid history) at the total lack of security in the "Hacker's Lounge." There were a mish-mash of 30 or so machines (Sun, SGI, Win95 PCs, Macintosh), all thrown together in a layout that screamed "free-for-all!" The Sun's all had the same account name/password (I wasn't at all surprised when I heard from one of the support technicians the second day that a machine had been broken into "from the outside" and the OS completely trashed to the point were it was down all day being reloaded. They changed the password each day as a "response.") The SGI's (another non-surprise, given their history) didn't even have passwords on the guest accounts! I didn't feel very safe using the terminals and changed my password before each log out as a defense against what I assumed would be rampant password capturing using the standard network monitoring attack. To top it off, most people didn't even bother to close xhost + access controls or even restart the session to get a new X "magic cookie" before/after using the workstations.
Next time I travel to a conference and need email access back here, I think I'll spend the time to get skey installed on my workstation before I leave. After seeing this setup, I couldn't help but feel proud of what we did for the email terminals at the SIGIR conference last year. Sun should have spent a bit less on showmanship and a bit more on providing a secure network (if they want to sell secure network products).