Posted on 12/26/2003 5:42:36 PM PST by gitmo
Though the two companies appear to be cooperating more, especially in the area of Web services, the desires of IBM and Microsoft to vanquish one another should not be underestimated.
IBM and Microsoft routinely argue that their cooperation, which is producing de facto standards at a record-breaking pace, is happening for the benefit of their customers. But standards, especially Web services standards, also facilitate the substitution of one platform for another. In this case, Java for .Net and vice versa. Nothing would please either company more than to win one of the other's customers by booting out the incumbent run-time environment.
Behind the scenes of this industry's most important struggle for supremacy, Microsoft must be grinning. Only one company is in control of Windows and .Net and all that goes with them, including the various approachable entry points (Microsoft Office, Visual Studio, etc.) and their respective development environments, which share some commonalities. When Microsoft has to make a change to any of its technologies to advance its agenda, it's largely unencumbered by external forces.
But in the Java world, where IBM is heavily bound, the consensus within the Java Community Process (JCP) controls the software ecosystem. If any single vendor has more influence than others, it's Sun. Change and advancement in the interest of one company's agenda are subject to politics, which have historically driven wedges into the Java community. In fact, Microsoft couldn't have executed a better divide-and-conquer war plan than the one that's being handed to it on a silver platter.
The two fronts on which Java unity most matters when facing the stiff wind from Redmond are the application server front and integrated development environment (IDE). Respectively, these platforms are where Microsoft's Windows .Net Server is battling with several Java 2 Enterprise Edition (J2EE)-based application servers, and where Visual Studio is competing against two primarily Java-driven IDEs. These two arenas, with the mobile run-time environment running a distant third, are where the war between Java and .Net will be fought most vociferously. Fortunately for Microsoft, it is precisely on these two fronts where the fractures in the Java community run the deepest.
This fissure was never more evident than during a recent six-business day period in which the wedges were driven deeper on both fronts as a result of two events, which Sun claims are unrelated. The first of these was an announcement by IBM and BEA that their competing J2EE-based applications servers--IBM's WebSphere and BEA's WebLogic--would support the same proprietary extensions to the J2EE specification. The second of these, which occurred about a week later, was Sun's decision to back away from a project that was supposed to merge the two dominant open source-based IDEs for Java (the Sun-endorsed NetBeans and IBM-endorsed Eclipse) into a single development platform.
Though casual observers may not see the connection, and the players may deny it, I'm not so sure. The JCP allows for proprietary extensions to J2EE as long as the development environment signals to developers that they are departing from the world of compatibility that's ensured by conformance to the latest JCP-ratified specification (currently J2EE 1.4). Without extensions, all J2EE-based servers should respond identically to a programmer's commands. With extensions, however, compatibility isn't guaranteed. J2EE vendors such as IBM, BEA, and Oracle traditionally offer different proprietary extensions as a means of differentiating the functionality of their offerings. Differentiation may help to optimize integration with some other software offering from the application server vendor.
Normally, if a member of the JCP sees a pressing need for modifications to one of the many Java specifications, those modifications are proposed within the relevant Java Service Request (JSR) first. If proposed changes move forward and garner support through the reference implementation and testing phases, the new specification is officially ratified. The JCP's Web site explains the process and JSR 151, the primary J2EE JSR. On the J2EE front, however, the IBM-BEA deal marks the first time that the providers of the two market-leading offerings collaborated (some might say "colluded") to support the same proprietary extensions first and offer them to the JCP second.
For the last two years, IBM has complained that with Sun sitting at the head of the JCP as well as certain JSRs (including JSR 151), the process is not as democratic as Sun claims it to be. The result has been that various Java specifications in which IBM is heavily vested have not evolved to IBM's liking.
Sun's control over Java and the JCP is quite debatable. Regardless of the merits of that debate, however, IBM has been keenly interested in loosening Sun's grip on Java as well as the JCP. What better way to do it than to marginalize the JCP altogether?
When the two leaders in any given segment collaborate to produce specifications, the rest of that segment has little choice but to follow. In the same way that the combined force of market leaders IBM and Microsoft left the rest of the market with little or no choice but to follow the de facto core Web services standards that the two collaborated on, the combined force of IBM and BEA in the J2EE segment leaves the rest of the members of J2EE JSR 151--such as Borland, Iona, Macromedia, Oracle and of course Sun--little choice but to follow.
The power play must have also left Sun and the other members of the JCP as frustrated as the World Wide Web Consortium (W3C) was when it was similarly victimized by IBM. If you're in IBM's camp, then you should be marveling at the brilliant game of chess that the company is playing. For the record, Sun is downplaying the significance of the IBM-BEA deal, but I don't buy it. Nothing makes Sun more furious than attempts to circumvent the JCP. Fully marginalizing the JCP, however, which the IBM-BEA deal successfully did, must have raised Sun's ire to a new level.
Six business days following the IBM-BEA deal, (timing that's pure coincidence, if you believe Sun), Sun backed away from the Eclipse-NetBeans merger. If you trace back through history looking for the last IBM-led effort that raised Sun's blood pressure to new levels, it's Eclipse. As with things on the J2EE front, where IBM wants to keep Microsoft squarely in its crosshairs, Big Blue was not quite satisfied with the direction that the open source-based IDE NetBeans was going. In a chess move that helped set the stage for this latest IBM/BEA-led power play, Big Blue jumpstarted the Eclipse Project as an alternative to NetBeans by donating some of the core technology behind IBM's IDE used for WebSphere development to the open source community. Sun executives fumed over the way JCP-member IBM was openly promoting Eclipse's cross-platform target support (which included Windows and Linux)--an idea considered sacrilege by Java purists and devotees of NetBeans because of the way certain Java conventions needed to be broken in order to provide that level of compatibility.
The open-source "donation" was the one of many such donations on IBM's behalf that had the effect of turning IBM technologies into de facto standards. It was also one of the first successful stakes in the ground that would split the Java development community. Eclipse's virtual overnight success forced development tool makers with their IDE plug-ins to either pick sides or support both at their own expense because the plug-in architectures of the two were incompatible with each other. The battle lines were drawn.
For enterprises, the fissure means choosing products that support either NetBeans or Eclipse. As usual, customers are caught in the crossfire, and Microsoft benefits from the in-fighting in the Java camp.
For two years, the number of Java developers has stagnated at about 3 million. As the rift in the Java camp has deepened, the entire community lost site of the more important goal in the battle with Microsoft: winning over more developers. The best way to do this would have been to lure in a new breed of developer as Microsoft has done by making Windows development far more approachable for everyone from children to engineers. In other words, Java has no farm team.
A merger between Eclipse and NetBeans would have been the first of the many steps necessary to incubate the vibrant growth that the Java developer base needs.
Both Sun and IBM obviously know that simplifying development environments is a critical step to gaining adherents. The two companies are sinking money into making Java easier. With its Project Rave --now officially known as Java Studio Creator --Sun has been hard at work to build more Visual Studio-like tools that can simplify Java development. Meanwhile, IBM is also honing its development tools in hopes of luring developers away from Microsoft. If there's any doubt regarding IBM's real target, a quote from Buell Duncan, the company's general manager for developer relations, lays that doubt to rest. "More and more, developers want an alternative to Microsoft," said Duncan. "It's time to crank up the heat and take this to the next level."
Meanwhile, the reason for IBM and Sun to part ways and compete against Microsoft's development platform separately sounds a bit fishy to me. Rich Green, Sun Development Platforms Group executive vice president said, "To rework their respective plug-in systems as well as the underlying tool platform would require a great deal of time and expense on the part of both groups." Time and expense? Sun has over $5 billion of cash in the bank and IBM is, well IBM. Still, Sun insists that there's no connection between its pulling out of the NetBeans-Eclipse merger and the IBM-BEA agreement. That doesn't compute.
Either way, for Microsoft, this is a fortunate turn of events. Had Sun and IBM gone ahead with the unification plan, all sorts of interesting things might have happened. For example, during a recent discussion with Oracle, which was anxious to get the word out about the release of its grid-enabled application server, database, and supporting cast of development tools, I openly wondered about a single, freely downloadable integrated Java development environment with plug-ins, widgets, database servers, application servers, and sample applications from every vendor in the Java ecosystem. That same download would also be packaged with StarOffice because, similar to the Windows environment, the same visual tools that are used to create full-blown applications are also used to script the productivity applications. Though it was a phone conference, I could see the Oracle executives nodding their heads.
But alas, such unity is not to be. As a result, any loss for Java will very likely be .Net's gain. Advantage: Microsoft.
I suspect there will be Java flavors, just as I use FreeBSD instead of Linux and still run the same programs. But as long as the problems with cross compiling aren't too intense, this is still a better solution than Microsoft's new paradigm, which is "write only for us and Intel, only for three years until we get tired of the current version of Visual Studio and force you to completely relearn everything so we can charge you for new server, IDE and database software all tied to DRM". Oh, and "don't mind our bugs, incessant updates, intrusive licensing and high fees".
And before the usual suspects knock me for using Java, I saved $4000 personally using open source this year, and I don't think I'll have to rewrite my code for the next twenty years, so stuff a sock in it.
As they say, grow or die. The handwriting is officially on the wall. Good old "write once and debug everywhere" Java will be overtaken by Microsoft's .NET Framework. It is only a matter of time. The outcome is assured.
So9
Blue Screen O' Death is very stable. ;-)
When .Net takes control - I'm moving to SuSe or Mandrake.
So will I - as soon as Linus gets Mono running on them.
Proving once again that not every victory is really a victory.
The two fronts on which Java unity most matters when facing the stiff wind from Redmond are the application server front and integrated development environment (IDE).
These two are indeed important, but there's another area that matters just as much, and perhaps more. That is the realm of smart/rich client programs distributed over the Internet.
Amazon.com showed a prototype at Microsoft's Professional Developers Conference (PDC) of a smart client program to shop at Amazon. Compared to browser-based access, the smart client was far superior. And corporations are re-discovering how much more productive workers can be with intelligent user interfaces. The browser was never meant to be a host for sophisticated, intelligent UIs, and it simply can't compete.
This are is now catching fire, as PDC showed. During the entire keynote, one smart client demo after another was shown. Not a single browser-based demo. And the PDC keynote is famous for showing the direction Microsoft expects to be the mainstream in two or three years.
.NET is ideal for this type of application. The .NET Framework includes an extremely sophisticated forms engine, plus the ability to use Web Services to access data. And before you know it, .NET will be on the vast majority of desktops, as people turn over their PCs to new ones with an OS that includes .NET.
By contrast, Java is very weak on smart client development. Swing and AWT are both sub-standard forms packages. But more importantly, there's no mechanism for getting Java included on lots of desktops, so even if they had a good forms package, lack of presence in the market would be huge obstacle to using it. (I think that was why Sun sued Microsoft to get the Java VM included in Windows.)
Java guys in general think everything should be browser-based, so they have missed the signficance of this development. Microsoft guys, many of whom came up through the Visual Basic ranks, writing forms-based intelligent UIs, get it. I think that by the time the Java community realizes this weakness, it will be too late to do anything about it.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.