Here we are again, back for another look at the underbelly of Java. Those of you that don't know what I write about, stay tuned; those that do, feel free to jump to the next paragraph. Straight talking is what we do here. We strip away all the hype and look under the cover of the Java engine to see what's really ticking. What you'll find here is something you won't read in any book or discover in any other column. I'm not out to win friends or butter up any company. I'm here to tell the truth, and I hope to get you, the developer, thinking and talking about Java.
Each month we address a potential problem and contrast it with a character attribute. In previous columns we looked at faith and trust. This month let's go for patience. Patience is one of those things we all have. Some of us think we have a lot of it until the moment we actually need it. For example, there really should be a law against teaching your loved ones how to drive. This takes all the patience in the world. It's been said that the world would be a much better place to live in if we all exercised a little patience.
People aren't the only ones to suffer from a lack of patience; companies are equally guilty. Pick up any magazine and you'll notice thousands of examples. The software industry is particularly bad with patience. It's amazing that consumer confidence is as high as it is considering the turnaround time and life cycles of some of the products. Some say it's progress; I say it's annoying. As soon as a product hits the shelves, a new version or updated feature is announced. Companies aren't allowing the market to absorb the product; they're exhibiting no patience, always rushing to be first to market. Let me explain.
N-ARY has recently returned from Tokyo. We had the good fortune to exhibit our company's services and products at JavaExpo98. It was the first time we'd been to Japan and we fell in love instantly. It was amazing to discover a city as big as Tokyo so clean and friendly. An advanced city as well. We all know how well the Japanese are at consumer electronics. How many of us have a Sony, Panasonic, JVC or some other Japanese derivative in our home somewhere? They have this knack of taking something and making it better - and, ultimately, smaller. We assumed we'd find the same level of experience and expertise in their software. A misplaced assumption, we'd soon discover.
We arrived preshow day and - once we persuaded the security guard that we were the representatives from N-ARY - proceeded to locate our wee corner booth. We walked past Oracle's stand. As usual, a huge impressive stage was being erected that resembled something from a Michael Jackson concert, not a computer show. I noticed something rather strange. Of all the great things Oracle is doing with Java, what do you think got top billing on their stand? The JDBC driver! Whoopee!
I thought this ironic, considering the topic of last month's column (if you missed that one, then it's worth getting a back issue for the column alone!) and my grievance with Oracle. I continued to look at the sign. Excuse me? The JDBC driver? You come all the way to Japan to promote the JDBC driver? Now I'm confused. We proceeded to set up our stand to promote our servlets and the power Java can offer on the server side. We were also promoting our new server monitoring product, n-formant, which is entirely servlet-based. In the excitement of setting up, we never got a chance to look any farther than the two or three stands beside us.
Show day came, as did the general public. Being a Java expo, we expected the majority of people coming in would be familiar with Java. So we prepared our pitch on servlets and n-formant, and how the coupling of Java at the server side could produce an excellent solution. Warning bells started ringing midway through the first day when we realized we hadn't done that much servlet talking but had spooled oodles on Java. Being of a suspicious nature, I looked around to make sure we had set up in the right hall and hadn't accidentally had a stand in the neighboring accountancy trade show. An easy mistake.
I know, I thought, let's go and see the Sun stand. That will put my mind at ease. I hadn't been to the Sun stand at this point and was very excited about seeing it (yes, I know, I must get out more!). The first thing I noticed was the big stage, stockpiled with Sun servers. Interestingly, they seemed to place a lot of emphasis on their hardware. Then I found the Java section. Here I went back in time.
The world of Java is moving fast, with lots of new, exciting APIs that allow the developer to do a host of things. Those of you who went to JavaOne this year know the sort of exciting demos Sun had to play with. Real eye-catching examples of where Java can be deployed. However, we saw none of this.
Nothing of worth was on the stand that hasn't been around for years. I kid you not. Not a single new API. The Java Web server wasn't even being demoed, let alone the servlet API. Other notable absentees included JavaPC, Media API, 3D/2D API and Beans. Would you believe that the bean concept was not being sold? I couldn't believe what I was seeing. I needed to speak to someone here.
Sometime later in the day the ISV manager, Tomohiro Yamazaki, came over and introduced himself to us. After we talked for a little I mentioned the lack of new Java technology, noting that even Oracle was only promoting JDBC. He wasn't surprised. He said that Japan as a whole was behind in the software market. We estimated around two to three years behind America. Java was experiencing a slow uptake in Japan, with the majority of developers still focusing on C++ and COBOL.
The reasons were many, ranging from the uptake of the Internet as a whole to the cultural differences in the way Japanese do business. Whatever the reasons, we saw similar feedback. I spoke to some of the Sun/Java server team in California when I got back, and they had experienced the same reaction when they gave a series of talks on servlets earlier in the year.
At first I was shocked and couldn't believe how behind they were; I felt exasperated at what seemed a very difficult sale. It was like selling car radios when you have to explain the merits of owning a car in the first place. Not easy.
However, thinking about it all, the Japanese are doing something they are renowned for and we aren't: they are exercising patience, resisting the urge to jump on the bandwagon and follow the crowd. But in this case, is it a good thing?
My first reaction is no. Java is evolving with more and more features coming online all the time and the developers need to stay informed. If they don't, then old technology will be employed and they'll be left behind. But is this a bad thing?
I don't think so. The problem is that Java is evolving a bit too fast. How many of you have moved over to the new 1.1 API? And how many of you have had to redo all your applets to work undeprecatingly in the latest browsers? A large number, I suspect. Well, can I let you in on a wee secret? We're about to change APIs again; be prepared for another learning curve, another rewrite and another version number. 1.2 is nearly upon us now, and I'm left thinking, Is this it now?
The time has come for us to say stop. Let's use what we have already and show the world what Java is really all about. Sometimes I feel like an Olympic runner (sadly, I don't look like one!) at the starting blocks; every time I think I hear the starter gun I'm told to return, it was a false start. Not only is this getting on the nerves of developers, it's not good for consumer confidence.
We've approached many large client companies that have plowed serious money into CGI/Perl solutions where a Java servlet solution was more applicable. The reason they don't use Java? It hasn't settled down yet....When it's in version 2 we'll look at it....Is it usable yet? These are just some of the comments we're getting, and I'm sure they're familiar to many of you as well.
Somebody at Sun has to stand up and say stop. Enough. Quit bringing out new APIs and allow us to get used to the existing one. Java is supposed to be "write once, run anywhere." It's more like "write once, run on any 1.1.x JVM anywhere." We're back into the old version number game again, and if we're not careful it's going to get worse before it gets better.
Sun needs to exhibit the same patience as Japan. It needs to hold Java back for a number of years, and allow it time to gain a foothold in the industry. I'm hoping this is what they're aiming for with the new 1.2 release, but only time will tell. Even at the server side, we need to be careful with the version numbers. This isn't supposed to be how the game is played.
As developers we need to learn to walk before we try running. We need to stop upgrading for the sake of upgrading. Although it's fashionable to always use the latest technology, it isn't always practical. Remember the phrase used when companies fail? They grew too big too fast. I fear this is in Java's future. It's growing too fast and isn't allowing the industry to catch up.
I'd like to thank Tomohiro Yamazaki from Sun (Japan) for talking to me in depth about this whole issue. His thoughts and insight into Japan were most welcome. We thoroughly enjoyed ourselves in Japan, and I would like to thank Mayuko Hayashi for her kind hospitality and for looking after us throughout the four days.
Patience, that's all we need to practice, and maybe we can make the world a happier place after all.
About the Author
Alan Williamson is on the board of directors at N-ARY Ltd., a UK-based Java software company specializing in JDBC and Java servlets. He has recently completed his second book on Java servlets. His first book looks at using Java/JDBC/servlets to provide an efficient database solution. He can be reached at