Summary
One commenter on my previous blog entry suggested that, because "Jini has recently been released by Sun as an ALV2 licensed opensource system. Thus, the door has opened for a whole new wave of distributed systems revolution."

Jini is clever technology, but it's been around for quite awhile and yet to make a big impact. Maybe it will someday, but not until the presentation and packaging changes. For instance, the most common example given for Jini seems to be the "smart printer" example, where you need to print something and your Jini client dynamically finds an available printer. I asked Bill Venners if anyone had ever implemented this, and he said no. So when you give people this example, and then say that Jini isn't really used for that, it leaves you with the question "what do I use it for, then?" AOP had this problem for the longest time, when the single example they gave was "logging." People came away thinking, "Well, if I ever needed to do a lot of logging that way, then maybe I'll go to the trouble of learning AOP."

Jini also needs a better out-of-the-box experience. You should be able to install it and throw together a Jini server and client with only a few simple lines of code and very little research. Linux had this problem for years, where you'd start to install it and it would begin asking arcane questions about your computer hardware configuration. I tried installing it once a year, for two or three years, giving up each time because I was just curious and not interested enough to put a lot of effort in. Only when Red Hat came along and made the install easy did Linux begin to get some real traction.

But finally, I have to ask whether Jini solves a problem that we need to solve, enough to go up the Jini learning curve -- and Bill also said that the Jini learning curve is not an easy one. Yes, Jini solves the problem of communication between service providers and service consumers on a network, where both providers and consumers can come and go as they please. But if it's too hard, then I will find a simpler solution. For example, no one has actually implemented the Jini printer example, which is presented in the literature as the classic simple example of a Jini application. They probably decided it was easier just to plug a printer into their computer than to implement the example.

The problem of "too hard" is often ignored by technologists. One commenter on the previous blog entry said that the reason that WSDL/SOAP Web Services were not more ubiquitous is that, "Maybe because folks on both ends of the wire get overwhelmed by how theoretically complex one could make a SOAP service, don't see how practically simple it can really be..." But just saying it's simple doesn't make it so. The fact that folks get overwhelmed is the problem. It's a problem that has damned many technologies (consider JNI and RMI, for example), and I think it's why Jini hasn't taken off. You can't just take an afternoon and get something working as a throwaway experiment; it's a big investment of time and you don't really know if you're going to benefit from that investment.

Here's an example: I've recently been working on a distributed programming problem, and the possibility of using Jini came up. It quickly became obvious that the overhead of implementing the dynamic lookup mechanism -- which is, indeed, a clever and thorough solution to that problem -- was something that we had no idea how long it would take to implement. It was easier, and more predictable, to just do "the simplest thing that could possibly work," and to solve our particular problem rather than solving the entire space of problems that Jini solves.

Every once in awhile someone will write an article saying how great Jini is and how its day is coming. Or make a comment like the one on my last blog entry. Of course, anything's possible, but I've also heard the same thing about the Eiffel programming language, which has been around longer than C++. There are some interesting ideas in Eiffel, in particular Design by Contract (DBC) which seems to dominate much of the thinking in the language. DBC is an important contribution to programming thought, but the problem is that DBC is a necessary, but not sufficient solution to creating correct programs. I think Gödel's Incompleteness Theorem comes into play here. Is this why Eiffel has not taken the world by storm, and never will? Maybe. But it's been around long enough that it's had plenty of opportunities to do so, and for whatever reason, it hasn't. Jini, too, has been around for quite awhile and I haven't personally seen or used any Jini-enabled applications (that I know of) and I haven't encountered any problems that have motivated me to go up the Jini learning curve myself.

If Jini can come up with a more compelling story, a simpler learning curve, and an easier out-of-the-box experience, then maybe it will go somewhere. If not, I think someone will come up with a more straightforward solution to the problem (if we can actually pin down what the problem is), and that solution will be successful instead.

Talk Back!

Have an opinion? Readers have already posted 17 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.