The #8 Reason that Sun is Setting: Fumbling Jini

Originally posted in May 2009...

Just an aside...

Before I go any further, let me just admit up front that I have a specific software bias in my perspective. Most bean-counter analysts will rightly say that the primary reason for Sun to be setting is that we didn't keep our stock price up and that we could have through a variety of financial measures, most notably more lay-offs. But in my opinion, the ability to keep the stock price up is directly related to how a company exploits all its market advantages over time, and I believe that the primary failures for Sun are in the areas of exploiting its software assets, not in a lack of aggressive job cuts.

Building to the "Next Big Thing"

When I joined Sun in January of 1997, Java technology had already transformed Sun from a technical workstation and server company into a software powerhouse. The 1997 JavaONE conference was the largest software developer conference ever held at the time. And Sun was charting an aggressive course for the technology, introducing Java Beans, JDBC, Abstract Windowing Toolkit (AWT), PersonalJava, EmbeddedJava, JavaCard, Enterprise Java Beans, Java Naming and Directory Interfaces, and on and on. And we quietly introduced something called Remote Method Invocation, or RMI. Interestingly, RMI, (along with another interface called Java Native Interface, or JNI), was one of the two aspects of Java 1.1 that Microsoft found so threatening that they refused to implement them in their Java 1.1.4 runtime, causing Sun to sue Microsoft over breach of contract.

RMI is actually a relatively innocuous technology that allows the Java software components (called "objects") in one Java environment (called a "virtual machine", or VM) to talk to Java objects running in another VM. This type of process enables something called "distributed computing", a concept that had been around for years in various forms (some of the more common ones were Common Object Request Broker Architecture, or CORBA, and Microsoft's own Component Object Model Plus, or COM+). Distributed computing enabled software systems to become distributed around a network and still cooperate in solving a given compute task. RMI introduced a Java-specific way to accomplish this and it turns out that by having the same type of objects on both sides of a distributed computing model, the whole process became much simpler and more powerful (CORBA and COM+ allowed objects of different types, like Visual Basic and COBOL, to talk to one another and required a complex set of request brokers and foreknowledge of the application in order to work). What was needed was some form of dynamic finding service where Java objects could register themselves and, using Java-specific capabilities like Reflection and Introspection, determine how to interact with one another at run-time.

Jini Jumps out of the Wrong Bottle

In 1998, Sun introduced something we called Jini. According to and interview with Bill Joy in Wired Magazine, "The Net made it possible. Java made it doable. Jini might just make it happen". What was "it"? It was the idea that the Network really could become the Computer, making Sun's long quoted catch phrase a reality. It was the idea that if every computing device in a network could run Java and RMI, then creating networks of applications that could easily describe themselves, broadcast their capabilities to the network and join up with other devices to create distributed compute networks would be greatly simplified. And by doing it all in Java, it could be programmatic and automated. Jini was the architecture that made the value of Java running everywhere leveragable. And don't forget that Bill Joy was Sun's resident genius and a strong proponent of both the idea of Jini and its development.

So what happened? How could a technology that was the brain child of Sun's resident genius and part of what Microsoft considered to be such a threat end up as a barely noticed project run by Apache? One obvious answer is that, like so many Sun products and technologies, it was a solution looking for a problem. Another obvious answer is that it was a technology that was simply ahead of its time. The real problem was that the engineers had built this technology using the latest Java platform (a beta of what would become Java 2 Standard Edition version 1.2) and had incorporated specific changes into J2SE 1.2 to support the Jini requirements. When launched, Jini could not run in anything smaller than a device with 64MB of memory and a Pentium-class processor (the minimum requirements for J2SE 1.2). Meanwhile, Marketing and PR were off describing uses of the technology that were all about small devices (cameras, printers, cell phones, etc.) that were completely unable to run RMI, nonetheless the Jini which was built on it. And to further complicate things, once this misalignment was identified, no consensus formed on how to solve it - should we abandon Jini in devices? Should we re-target Jini at servers and desktops? Should we re-architect Jini so it would work in a smaller memory footprint and processing power? (no small technical feat, I assure you). In the end, we did a little of everything and ended up confusing ourselves and everyone else about what Jini, the heir apparent to Java, was supposed to be.

Jini's Lasting Legacy

None of this was in-and-of itself devastating for Sun. Misalignment between engineering and marketing is commonplace throughout the technology industry. But Jini was no ordinary technology - it was being positioned as the "future of Java", the logical extension to the incredible network of Java-enabled devices that Sun and its partners had created. It was over-hyped for sure, but we didn't seem to realize or care that a vast amount of our reputation as a software innovator was getting wrapped up in Jini and that developers were starting to ponder if Sun was really up to continuing to lead them into new and wonderful markets or down some poorly thought out road to nowhere. In short, we were losing our software mojo.

Jini should have been first-and-foremost about distributed computing. This means big enterprise servers running networked, Internet-scale applications that could dynamically configure themselves and recover from unexpected outages. But ultimately, Sun never really delivered any commercial value with Jini. And we went on to market other "cool" four-lettered "J" technologies like JXTA and Jiro that also never caught on in the market. And worse still, we left the door so wide open on distributed computing that Microsoft and others were able to walk through it with "Web Services" and the associated complexity along with it (Jini could have solved all the problems currently encountered and would have locked alternative languages like Microsoft's C# out of the distributed computing market, to Sun's advantage).

Jini still has a loyal following and there have been some commercial successes based on Jini. But the promise of Jini when it was announced was that Sun would continue to innovate and drive the technology in new and unique directions, enabling things that had not been dreamed of before. Instead, Jini marked the beginning of an era in Java development characterized more by the Java Community Process and the JSRs and Executive Committees that spew forth from there. In short, the failure of Jini marked the end of Sun's vision leadership in software technologies.