Just now, the big story in Jini-land is the Starter Kit release. I’ve been spending quite a bit of time here the last few days, trying to figure out whether it’s the future or not; either way, it’s important.

The Starter Kit · The starter kit is important because it makes it easy for anyone to go grab a big glob of Jini code that you can just turn on and use. Also, it uses the Apache license, which I’ve always liked (Summary: “This code is ours. Do whatever you want except lose our copyright notice. If it breaks, too bad.”). So the barriers to entry are low.

An email went around from Bob Scheifler about the starter kit but I didn’t see it reproduced on the site, here it is:

Technical enhancements in this release of the starter kit include:

  • JavaSpaces extension — adds new methods that enable many-to-many communications and batch operations using a JavaSpaces service

  • Ant build support — for generating binaries and documentation from starter kit source code

  • ConfigurationFile additions — support string concatenation and subclass exception control

  • EnvCheck tool — performs runtime environment validity checks

  • Installer — graphical starter kit installer, also verifies environment settings

  • JAR file changes — improve network security posture, and facilitate patching for layered systems

  • JoinManager additions — support for proxy replacement and configurable lease renewal intervals

  • Mailbox extension — provides pull—style access to the event mailbox service

  • Multihomed host support — Jini ERI and discovery utilities now attempt connections to all of a host name’s IP addresses

  • PreferredListGen tool — generates preferred class information for downloadable JAR files

  • Reggie enhancements — support for proxy evolution

  • Tool wrappers — executable JAR wrapper files for all tools in the starter kit

That list offered for your enjoyment without comment, because mostly I don’t understand it. More on that later.

Why It Matters · Jini, near as I can tell, represents a heroic attempt to build network-computing infrastructure that deals with reality as it actually is: sometimes the network breaks, sometimes the individual machines in it break, sometimes the program you’re interacting with breaks. Distributed applications shouldn’t. This is a Very Important Problem.

Jini has the fingerprints of Bill Joy and Jim Waldo all over its architecture, and these are obviously two of the Real Smart Guys. Rob Gingell, another one of them, said “Those who do not use Jini are doomed to re-invent it.”

Jini is not just a theoretical triumph; it’s being deployed in large mission-critical applications at places including Orbitz, Orange (the mobile-phone company), Raytheon, and the U.S. Army.

So, the evidence suggests that this should matter. Furthermore, I’m in the middle of writing an application that wants to run in multiple instances across a network, deal with node failures, bring more machines into the picture as required, and so on. Which sounds like more or less exactly what Jini is supposed to do. So not only is something that maybe the world should care about, it’s something that, specifically, I should care about.

The Tokyo Subway · I have two shortcomings which I have given up trying to overcome. First, I have a short attention span; I like things that I can learn quickly and put to use right away. Second, I am very, very bad at abstractions; when I think of programming problems I always have actual code snippets in my head, and when I think of networking problems I totally can’t see past the bits on the wire.

Jini just isn’t built for people like me. The discussions, of the core and of each of the Jini-based systems, seem to start with several sections of pure text, sometimes with block architecture diagrams, to get all the abstractions straight. The wire protocol is apparently RMI in practice but they’re careful to emphasize that that’s an abstraction, it could be anything.

I was trying to get cozy with one of the subsystems and found a “Hello World” example with one interface, six classes, and 625 lines of Java code. My first reaction was “These people are crazy”, but then I realized that it was a really, really complete “Hello World”, with a Swing UI and a Bean Factory and a Proxy Manager and so on and so on; in fact, a superb piece of work.

But still, I’m a person some of whose technical triumphs have involved judiciously-applied smallish Perl scripts, who invented the acronym MPRDV (“Minimum Progress Required To Declare Victory”), who runs around advocating “The Simplest Thing That Could Possibly Work” and crying “YAGNI!” I believe strongly in Larry Wall’s formulation: “Easy things should be easy, hard things should be possible.”

Jini makes me feel like I did the first time I stumbled, jet-lagged and luggage-laden, into the Tokyo subway system. Unfortunately for Jini, there are a lot of people like me.

That isn’t necessarily fatal: backed into a corner, I have built two non-trivial Apache modules, quite a bit of fairly sophisticated text-rendering code, a couple of full-text search engines, and one of the early Web-search implementations. But I will struggle like the devil to avoid dealing with that kind of complexity unless there’s absolutely no choice.

Hypotheses · So, let’s be ruthlessly logical here; I see three hypotheses which are consistent with the narrative thus far:

  1. Jini is The Simplest Thing Which Could Possibly Work, given the problem it’s addressing. After all, I am now a competent user of the Tokyo subway, which solves an insanely large and complex problem about as simply as possible.

  2. The complexity of Jini is appropriate, but it needs a simpler front-end, a lower barrier to entry, a starter kit for newbies. I mean, anyone who can program at all can learn to write a Perl script to pull the price of a book out of Amazon.com Web Services; but there is apparatus of mind-boggling complexity at work in the Perl implementation, in all the Web machinery that gets the messages back and forth, and inside the Amazon.com server farm.

  3. It’s overkill. It’s OSI networking, and we need TCP/IP. It’s Ada and we need Java.

I don’t see that the evidence so far can be said entirely to falsify any of these hypotheses. My hunch is that #2 is the right answer.

Anyhow, to paraphrase Rob Gingell, if I can’t figure out how to make Zeppelin use Jini, then I’m gonna have to invent something that does more or less what Jini claims to. I’d rather not.

author · Dad
colophon · rights
picture of the day
March 30, 2005
· Technology (90 fragments)
· · Java (123 more)

By .

The opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.

I’m on Mastodon!