HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Welcome to your monthly dose of controversy - the part of the magazine where I ask you to push back the keyboard, stop debugging that Java class that has been bugging you for the past couple of hours and get your shot of caffeine as I invite you to take a look at this crazy Java universe through the eyes of a British company.

It's been an interesting month for us here in Scotland, so I have a lot to tell you. As usual, we'll contrast our findings to a personality trait. This month I think we'll look at gullibility. That's one that all of us at some point in our lives have been subjected to. Whether we admit it or not is a trait for another month, so let's not get ahead of ourselves.

What I'm about to say may come as a bit of a shock to some of you. It appears that something rather exciting is about to happen. We're not too sure what it is, but I am reliably informed by the BBC and CNN that it will be major. What am I talking about? The end of the world, of course. The end of civilization as we know it. The millennium is fast approaching and we're down to days as opposed to years.

Since every other journalist under the sun has written about it, I thought it was about time I threw my two cents in about the whole thing. As with any good Clinton or Michael Jackson story, the millennium bug is full of complete misinformation. The only consistent fact is the name of the problem: Y2K. The computing industry, true to form, has assigned yet another acronym to the list of thousands we already manage. No wonder public perception is of doom and gloom if we shroud the problem in our own tech-speak!

But There's Always Hope
I'd seen so many contrasting and scaremongering reports that I'd given up hope on the world as a whole. Had the whole place gone mad? Reports of planes dropping from the sky, buildings falling over, governments crashing and wars taking place were all going to be attributed to a simple date problem.

Fortunately, my sanity was restored when I read a very informative and realistic article in the New Scientist Journal that profiled what the world is really going to be like when we wake on January 1, 2000. And here's where I'll let you all into a wee secret: the sun will still be shining, the earth will still be revolving...and Jerry Springer will still be broadcasting!

Don't get me wrong - I know there will be some problems we'll have to deal with, but on the whole I believe that the majority of the world's population will indeed be very disappointed with the turn of the year 2000. It's not going to be the big bang we're all expecting. I think the biggest shock will be to the companies that - for reasons best known to themselves - hired the cowboy consultants who are charging 20k a day for the 31/Dec/1999 to 1/Jan/2000 period, only to discover that the problems still exist. What's confusing me is just what these people expect to achieve.

For example, let's assume that they're Y2K experts. Let's further assume a problem does occur. Do they expect to fix it then and there? Because if they haven't been able to fix it beforehand, what are the chances of their achieving success on the given night? Personally speaking, I feel that this sort of behavior is taking advantage of computer-illiterate companies. Some of you will say they deserve it, or even So what? Well, there's that attitude, but that really doesn't do the industry a whole lot of good.

We all know the basic foundations for the Y2K problem: the saving of disk space when dealing with dates, and the year precision. Back in the 1960s it was assumed that their software would not still be running in the year 2000. Which, I suppose, you can't blame them for. If I were to ask if you thought the class you just wrote would still be running in 30 or 40 years' time, how many of you would say yes?

Not that many, I suspect. Why? Well, we probably think development languages will have moved on so much by then that there will be no place for a lonely Java class to exist, let alone still provide a useful function. This is another great debating point, and one that I welcome all e-mail on.

(Speaking of debating points, let me thank you all for the response to my article [JDJ Vol. 3, Issue 12] on company loyalty - I think I touched a nerve there. I had put forward the notion that employees aren't as loyal to companies as they were once. This sparked a flurry of e-mail from readers accusing me of not seeing the "two-way street" of loyalty. Of course I see the two-way street, where the company also shows loyalty to the employee. There are many stories of people who have given the majority of their working lives to a company only to be dumped when the going got tough. I appreciate this, and as I said in my article, it's the bigger companies that have made it sour for us smaller companies. I enjoyed debating the issues with you. So keep the e-mails coming!)

Back to our Y2K issue. Assuming our Java classes will see it to the next millennium and even past it to the next one, in some museum of computing through the ages will they cope with the change? Well, Sun has assured us that Java is indeed Y2K compliant - assuming you've been a good developer and stuck with the standard date classes within the JDK. If you haven't, you're on your own, which is fair enough.

Just for Fun...
Let's assume that there was a problem with the fundamental date classes that meant a wee problem on Hogmanay (New Year's Eve) 1999. How serious would this be to fix, compared with the problems facing the Y2K developer now? Well, assuming a problem existed in the java.util.Date class, for example, all that would be required would be for Sun to fix it and reissue the class file or virtual machine to the world at large. All we'd have to do is copy over the new class file and restart. That would be it. No recompiling required on our behalf. This would be the miracle cure that would require nothing more than a simple copy. That's the power of Java.

But this ease of upgrading or bug fixing can be applied to anything in the Java universe. That's one of the advantages of having a good class design and a good solid object structure. The ability to swap a bad module for a good one without disrupting the rest of the system is indeed a powerful one. For this reason, I believe that the Y2K problem is indeed a special time.

It'll probably be the last time we see a major problem on this sort of scale. If anything like this pops up in the future, we can take refuge in the fact that for us to fix a small fundamental component in the system won't require a lifestyle change.

Of course, this is assuming that we're still around to enjoy the turn of the century. While I was researching the material for this article, I stumbled across the origins of dates and calendars. I also came across some of the more doom and gloom predictions about this time of the century and I'll share some of my findings with you.

For a start, we can attribute the basic calendar to the early Egyptians. At one time they were managing up to three calendars at once, since each one was failing at given times of the year. The basic numbering of our years came from the biblical event of the birth of Jesus Christ. Hence the "BC" notation for describing years before the year 0. But I discovered a number of sources that point to the fact that Jesus may have been born closer to 75 AD, and around October rather than December, which is when we traditionally celebrate it. They can ascertain this by trying to figure out when the bright star - which supposedly guided Mary and Joseph to the stable - would be that high and that bright.

It's always amazed me that there was once a time when someone said; "Okay, this is now year 0, agreed?" Can you imagine being that decision maker? Talk about responsibility! So the fact that we're coming up to the year 2000 is more of a numerical fluke than some religious destiny.

Another man's name that's popping up frequently at this time of the year is that of our old French friend Nostradamus. If you've never heard the name, or even seen the movie, Nostradamus was a sixteenth-century prophet who seemingly predicted the world wars and a number of other notable events throughout history. The problem is that Nostradamus wrote his prophecies with much of the same vagueness as the Bible - and look at how many interpretations THAT document has had! But one of his most shocking predictions is coming up, apparently this year.

Nostradamus has predicted that the King of Terror will be coming in the seventh month of 1999 and will either destroy or significantly damage the world as we know it. Again, this is all so vague. Some believe it will be a meteor, while others maintain it's a nuclear war. The translation of the original documents is also open to debate, as the seventh month can mean either July or September. To join in or listen to the debates, join the alt.prophecies.nostradamus newsgroup at www.liquidinformation under a Nostradamus search.

What can we learn from this? Well, I wouldn't go signing that huge loan agreement just yet on the basis that the world might not be available for you to start making the repayments. But I wouldn't completely dismiss it. Let me tell you a wee story that scared the living daylights out of us. We've been experiencing some seriously bad storms here in Scotland. I was taking some time out from the keyboard, and we started chattering about Nostradamus and his predictions. I looked out, noticed the trees bending at an unbelievable angle and made the comment, "You know with all these storms, maybe this is the beginning of Armageddon." As soon as I had the last word out, the complete power for the whole village went off. We were standing in darkness, and we all just looked at each other in disbelief at the potential timing of those fateful words. Spooky!

On that note, I think we'd better wrap this article up before I encourage any further bad karma. Before I close, let me give you this month's recommended reading.

Recommended Reading
The books I love reading are the ones that tell stories of the rise - and sometimes fall - of large corporations. I was given a book, Insanely Great, penned by Steven Levy, that charts the rise of Apple computers and how Apple relied on the very fact of being Apple in the early days. He talks about how great it is to own an Apple, and there's a bit in the book where Levy admits that being an Apple devotee isn't without its costs. We all know Apple devotees - people who, for reasons non-Mac users can't fathom, believe that the only real computer is an Apple. According to Levy, it's because there's safety in numbers. In the early days the marketing of Apple sold little more than the reality. Therefore, for the buyer not to feel isolated he had to maintain the momentum of the Apple marketing people and gloss over the problems that hindered many of the early Apple machines to his colleagues, friends and family. It was like being a member of an elite club, where the golden rule was never to mention the failings. You loved your Apple, worms and all. It's an entertaining book, and you'll chortle at some of the information.

Now I'm going to prepare my nuclear bunker in preparation for the end of the world. If it hasn't happened by the time next month comes round, I'll be back!

About the Author
Alan Williamson is CEO of n-ary Ltd., a Java consulting firm with offices in Scotland, England and Australia. They specialize solely in Java at the server side. Alan is the author of two Java Servlet books and has contributed to the 2.1 Servlet API. He can be reached at [email protected] (www.n-ary.com).


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.