The idea is that Microsoft would build Chai into.NET. This would open .NET servers and Internet-based services to non-Windows Java apps and Java-based devices. It would do so, however, by using a JVM that is independent of Sun and has been described as "the furthest thing from Sun's Java." And that's what has some people thinking that this could be the wedge that effectively splits Java and finally demolishes the "write once, run anywhere" dream.

Actually, Microsoft has had a license for Chai since 1998. Its license for Java from Sun dates back considerably farther, but that's been the subject of as much legal and political maneuvering as the Florida recount. Chai, on the other hand, is shaping up to be the keystone of a complex deal structure that would, among other things, resolve an XML technology issue over which Microsoft and HP are at odds.

That controversy involves HP's e-speak and Microsoft/IBM/Ariba's UDDI (Universal Description Discovery Integration), two overlapping specifications relating to registry, transaction rules, and business directory structure for b-to-b e-commerce. It appears, at the time I am writing this, that Microsoft and HP may agree to some compromise on e-speak and UDDI as part of the Chai/.NET deal. By the time you read this, it may be a done deal — although, at the time I am writing this, the U.S. presidential election is still undecided, so I'm not placing any bets on anybody coming to any agreement about anything.

Another item on that shopping list of technologies that Microsoft and HP are negotiating is Microsoft's C# language, sometimes portrayed as an alternative to Java. Microsoft wants to secure ISO certification for C# (as well as for .NET), and HP's support would be very helpful in that effort. HP wants the same for e-speak and Chai.

Even without ISO endorsement, Microsoft and HP could arguably establish Chai as a competing de facto Java standard, evolving it farther from Sun's de facto standard and fragmenting the market. Who was it who said that when two incompatible standards compete, each becomes a substandard?

C# in the Exit Polls

Back to C#: How plausible is the view of C# as an alternative to Java? One measure of that is developers' willingness to try out this Microsoft offering. The research firm Evans Data polled developers about C#, with the following results: Of the 600 developers polled last October, 30 percent said they would probably try out C# this year. But just who are these developers? Well, two-thirds of that 30 percent are people who use Visual Basic more than half the time. Among heavy Java users, only one in 10 expressed any interest in trying out C# this year. Based solely on these results, it would seem that C# is, at least for now, less of a Java killer than a VB killer.

That's not the end of the story, however. C# is very young: Tools and compilers are not yet publicly available. The language was designed to provide Java's main benefits and will certainly challenge Java to some degree as it matures.

Not a Banner Year for Java?

One particular market for Java apps may be slipping away — rich media web banners.

It was First Virtual that first introduced these rich media banners in 1996, using Java. First Virtual asserted that Java was the superior technology for such banner ads and win out over all competitors. It hasn't worked out that way. In this market, Macromedia Flash is emerging as the winning technology. As of a year ago, more than half of interactive service shops had settled on Flash as their top choice for a tool for such work, according to a Jupiter survey.

Alternatives to Java? Certainly, there are viable alternatives to Java mounting serious challenges to Java in particular markets.

Third-Party Candidates Come in Third

Third-party candidates don't generally do well in America, probably because of a self-defeating feedback loop: They aren't perceived as being winners, so they don't get the support they'd need to become winners. Americans do like to back a winner.

Minority solutions in software can prosper even if they don't win a majority of the electoral vote, though. The following development environments or tools have been pitched as alternatives to Java, by which the pitchers mean many different things. They're all good tools, but is there any sense to their specific claims to be alternatives to Java?

• Internet C++. Xoom is promoting its C++ implementation as an alternative to Java and C#. "Build one C/C++ program — run it everywhere" is their slogan, and it certainly catches one's attention. The key is the virtual machine, the ICVM. Xoom invites you to take your standard 32-bit C/C++ programs and recompile them for use on the Internet, using ICVM as the execution base. The target market is people developing 3D online games. The pitch is Standard C/C++ with the portability benefits of Java.
• Lisp. A little over a year ago, a study at JPL compared Java, C++, and Lisp implementations on a variety of criteria. The results go a long way toward debunking conventional wisdom that Lisp is slow. The results show Lisp performance as comparable to or better than C++, with significantly lower variability. The researchers argue that this reduced variability translates into reduced project risk, which may be a good point, but it speaks more to Lisp as an alternative to C/C++ than as an alternative to Java. Their argument for Lisp as a Java alternative runs as follows: Lisp, like Java, provides automatic memory management, dynamic object-oriented programming, and portability. Those are Java's purported benefits over C/C++. Lisp has all those benefits without the performance drawbacks of Java. Hence, it is a viable alternative to Java for many applications.

• Perl. Larry Wall, Perl's creator, gave a talk some time ago titled "Perl: An Alternative to Java?" The claim here is straightforward, but limited. Perl is probably the most widely used language for web programming (read "CGI programming") and has the portability advantages attributed to Java. But there are a number of other interpreted scripting systems that, while perhaps not as popular as Perl, can make a similar claim to portability. What they can't claim, as Perl can't, are the benefits of a real, full programming language. On the other hand, Perl is so popular now that we could almost expect a speech — probably not by Larry Wall — titled "Java: An Alternative to Perl?"

• Juice. Juice is an alternative to Java specifically in the area of downloadable applets, particularly large applets, rather than in other Java-targeted markets like consumer electronics and household appliances. Juice is based on Niklaus Wirth's language Oberon. Juice is to Oberon as JVM is to Java. Most of the key work on Juice actually predates the release of Java. Juice's inventor claims that his tree-structured program representation has significant advantages over Java's byte-code representation.

• Component Pascal. Speaking of Niklaus Wirth-inspired languages, Component Pascal has been mooted as an alternative to Java. Component Pascal is a considerably smaller, less complex language than Java. But like Java, it supports the dynamic loading of code and metaprogramming (reflection). In fact, it is sufficiently Java-like that there is a Component Pascal compiler that actually produces standard Java bytecode class files.

Clearly different people mean different things by "alternative to Java." Probably the only interpretation that carries any impact is "Java-killer." Certainly, you might choose to use Perl for a job that another developer would tackle using Java, but that's no threat to the existence of Java. Some would argue that there are only two real threats to Java's survival: Microsoft and Sun.

In December, Sun appointed new members of the executive board of the Java Community Process — members who do not work for Sun. Arguably, this is evidence that Sun is loosening its grip on the Java technology spec by an erg or so. It ain't easy for Sun. You can almost feel the strain as the company pries its own corporate fingers back from the deathgrip on its technology.

FileMaker: The Downgrade

Last month, I wrote about our efforts here at The Prose Garden to use FileMaker Pro as the database centerpiece of the e-commerce solution we are developing for my wife's farm/restaurant/andsoforth business, Summer Jo's. I was also, at the same time, trying to say something useful about the FileMaker Pro 5 family of database products. I had hoped to go into a little bit of detail about our experience this month, and in the process give readers a sense of the strengths and weaknesses of FileMaker Pro 5.

However, we are no longer using FileMaker Pro 5, and as a result, I can't write too much about that release just now. I don't want to suggest too much by our decision to drop back to Version 4.1. Although there was a security issue that influenced our decision, the deciding factor was simple compatibility with our service provider, who is using Version 4. The upshot, though, is that I haven't looked at FMP 5 in the past month in sufficient depth to say anything useful about it. That may change by next month. But whether it's Version 4 or Version 5, FileMaker certainly lets one knock out quick solutions — and that includes web-based e-commerce solutions. The scripting language built into FileMaker keeps the ease-of-use versus power balance from tipping too far from power, but it would be even nicer if the scripting language really were a scripting language.

What it is, unfortunately, is something less. I've been scripting FileMaker and reading the bible for FileMaker scripters. That would be Scriptology: FileMaker Pro Demystified, by Matt Petrowsky and John Mark Osborne (ISO Publishing, 1998, ISBN 0-9660876-0-7). I have a few things to say about the scripting experience and the book. ScriptMaker is the programming component of FileMaker. It's really just a macro generator. It does have logical operators and looping and branching statements and the ability for one script to call another. But it only automates manual operations that a FileMaker user/developer can perform, and despite what Petrowsky and Osborne say, it is not an object-oriented development system, or even a quasi object-oriented system.

Petrowsky and Osborne's book covers the ground it needs to cover: If you want to do anything with the scripting capability of FileMaker Pro, the book is almost mandatory for its documentation of the script language elements (called "steps"). It goes well beyond just documenting the steps, though: It includes a CD of useful scripts. I didn't find them very usefully indexed; finding a script to solve a particular problem is harder than it needs to be. But the scripts included have been chosen intelligently, and practicing FileMaker developers should find many of them useful.

The book also threads its way through the trickier parts of FileMaker, like cross-platform issues and using portals, from a scripting perspective. I understand why a developer at the FileMaker Developer's Conference last summer told me this was a must-have book. One area that is handled particularly well is optimization. This material is written from a solid practical knowledge of the peculiarities of FileMaker. Still...

I found the book less than ideally organized, with typos and grammatical errors. I think I know why. On page iii of the book is the list of credits, and here we find that Osborne and Petrowsky wear a lot of hats. Managing editor, editorial supervisor, production director, production editors, technical editors, layout designer, cover designer, CD-ROM content developer, interface developer, copy editor, product testers, and production team — it is possible to spread oneself too thin. Fine, boys, be your own CD-ROM content developers, but if you copyedit your own writing and act as your own technical editors — you know how they say that a man who acts as his own lawyer has a fool for a client? You might take it as a hint as you develop the next edition.

DDJ

Paradigms Past: History in the Making

There is always some critical mass of material that is necessary to collect, organize, and present for a history to work. Up to a point, a partial history isn't really a history at all. Only when you get close to an exhaustive survey of the subject do you have a chance of treating the material in a fair, accurate, balanced manner.

But because each of the processes of collecting original material, doing interviews, and writing lead to the discovery of new areas that need to be included (a process that can expand infinitely unless you find a logical way to curtail it), you find yourself early in the process with an unbalanced, unsatisfactory collection of material whose significance you may suspect, but you can't properly articulate. The pieces may be interesting on their own, but their connection with one another and their significance in the big picture are unclear.