Title: A Personal View

I wondered into my local bookshop recently to browse their shelves to see if there was anything worth reading. I'd prepared a list of possibles from the last issue of C Vu and was looking for something that might give me some insight into Java. Had I not had the advantage of C Vu reviews I would have been completely swamped. Books on Java have got a long way past a joke. It hardly seems credible that it was only about three years ago that Java escaped from its nursery. I use that expression advisedly because it clearly still has a lot of growing up to do and equally clearly was still under development when it first became generally available. It launched itself on the World at just about the time that the World Wide Web was taking off in a big way. The result seems to have been a two-way feeding frenzy. Normally sane and competent programmers suddenly abandoned all their experience and fell in love with Java. Nothing else can describe the way that they talked about a language that still had so many shortcomings.

The fundamentals of Java are fine for what it was designed for (and quite a bit more). It wasn't perfect but then what is? I guess that the long years spent tracking C++ as it struggled towards both completion and stability had taken its toll on quite a few programmers. When you add in that C++ code was extraordinarily difficult to port. The multitude of different compilers all implemented different versions of the language. Worse still, it was being used for applications with Graphical User Interfaces and porting between these (even platforms from the same company) is far from trivial. When Java came along it was notably simpler than C++ while claiming that it would run anywhere (that would support a JVM). Battle weary software developers flocked to its standard.

The problem is that it is easy to confuse what was effectively a universal interpreted assembler with a full-fledged language. The two things that make Java interesting are the underlying JVM and the superstructure of APIs (libraries). There are some flaws with the JVM specification (the lack of detailed specification for garbage collection, the lack of any reliable way that the programmer can ensure that resources are actually released in a timely fashion etc.) but time and experience would get those right. On the other hand the libraries are a classic example of what happens when you rush to production. The AWT was bad enough but some of what has been added since is even less well considered. The trouble with the Internet culture is that it leads people to expect instant gratification. What they get is immature products ready to create chaos (look how many people continuously use beta versions of products downloaded from the Net). Look at the bizarre relationship between Date and Calendar. I have even heard someone claim that Date has been deprecated (deprecated after less than three years? Why?) and that Calendar supersedes it. What rubbish. Calendar is an abstract class and it actually uses Date to do most of its work. While you are checking that out, have a look at the getTime() method of Calendar; it returns a Date. At the very least both these classes are badly named but actually there are some much more fundamental flaws (someone told me that Date is not fully Y2K conformant, yes I know that makes it hearsay, but with nearly 4000 pages of core library documentation to wade through…)

Now I learn that Sun Microsystems are proposing to ship a standard for vote some time in the Spring of 1999. Putting aside the stupidity that allowed Sun Microsystems (SM, hmm…) to be a PAS submitter (publicly available standards) because that was a piece of political chicanery, let us focus on the future.

How can the experts of any National Standards Body express a considered opinion on the proposal? The sheer weight of potential documentation would defeat anyone. Even those who have actually been involved in writing the documentation would be hard put to have a considered opinion. Proposing to put such a massive document out to vote by people who have had no part in tracking its development. and no feedback into that process is laughable. I thought that some of the French reservations about the C++ CD1 were unhelpful (e.g. just saying that the library was too complicated without going into detail) but they had had the opportunity to participate in its development. But how else should NBs respond to a proposal to create an International Standard? It is difficult to vote against it because they would then be expected to itemise what is wrong with it. Let us assume that the result is that we get an IS for Java. The next question is who should be responsible for maintenance? In other words, who responds to requests for clarification? Even more important, who is responsible for defect reports? Every one of these requires some form of record of response. At least it does if the normal ISO mechanisms are followed. In other words, if I ask a serious question, I am entitled to a serious answer. In normal cases there is an ISO workgroup responsible which is effectively funded by time and resources donated by all interested parties. Languages such as C and C++ have gone one better by arranging that there are joint meetings of an ANSI sub-committee (J11 or J16) with an ISO SC22 workgroup (WG14 or WG21). The result is that a body of interested, but collectively independent, participants is responsible for developing and maintaining those languages.

Rumour has it that SM want to retain sole responsibility for the development and maintenance of Java after it becomes an IS. Pardon me for being suspicious, but what is in it for them? The shareholders of SM are hardly likely to want to pour their profits away in some altruistic move.

Looking at it from a different perspective, how are SM's competitors going to view SM retaining such ultimate control?

Yes we need a standard for Java, but one that is maintained by a properly authorised group who can and will provide proper responses to 'bug' reports. What we do not need is a Java IS in open warfare with some other company's product. We need a modularis-ed standard that can go through incremental develop-ment, not a single monolithic catch all that necessarily includes APIs and implementations knocked up JIT to catch the only departure for a Java standard.

Finally, you might like to note that the next meeting of the ISO Java Study Group is in Tokyo on October 26-27. If I were trying to control Java I can think of few better ways to do so. I hardly think that a two-day meeting in Tokyo (a very expensive location for Westerners) will attract much international participation. The timing, about two weeks after C and C++ committees meet at the same venue in Silicon Valley (so they can co-operate as well as keep participation costs down) is about as bad. Which company is going to release their language experts for a 'jolly' to Tokyo two weeks after they have just sent one or more employees to a meeting in San Jose. However, such lunacy seems about par for the Java course.