The phrase "not invented here," or NIH, when applied to technology, describes a resistance by a group to use a perfectly valid solution to a problem they're encountering because they'd rather build the answer from scratch than adopt something existing that already does the job. Assuming that there are no legal or licensing issues to stop the already-built technology from being included, the reasons behind the recalcitrance to its usage usually boil down to human nature.

Software engineers are inventors, and inventors like to build things from first principles. Arriving at their door with a completed solution takes the wind out of their sails; it undermines their relevance and forces them to examine something built by people who are possibly smarter than themselves. Most scientists revel in such group sharing of knowledge; as Sir Isaac Newton acknowledged, "If I have seen further it is by standing on ye shoulders of Giants." Only by recognizing, embracing, and then using the solution as a platform to further advance can science move forward. At a recent presentation given by some NASA engineers who base their command and control systems on the Eclipse Rich Client Platform, they described the decision to do this by drawing analogies to rockets. As developers, their job at NASA is to work on the payload of the rocket and perfect the portion that rides on the top to boldly go and do novel and exciting stuff in space. The lower part that propels them into orbit is basically a commodity to them and bought off the shelf from Boeing and other big companies whose expertise is in moving big and heavy things efficiently through the atmosphere. This embracing of Newton's wisdom to pre-requisite technology such as Java and the Eclipse RCP is not rocket science to mature and sensible developers.

Leaving the world of space exploration for a moment, one of Java's problems since its inception has been the model by which classes are loaded into a JVM. Simplistically speaking, when a JVM starts it is given a classpath that contains a list of directories, or .jar files, and each time the JVM wants to load a class it scans the classpath until a matching .class file is found. Having been located, the .class file gets loaded by the JVM's ClassLoader and instances can be created. This model of having a JVM start up with all of its classpath ducks lined in a row, requiring termination and restarting when anything changes, is overdue for an overhaul.

Fortunately, the OSGi alliance, www.osgi.org, has been tackling this problem for about eight years now, during which time it has created an extremely mature and well-thought through dynamic module system for Java. OSGi's member companies are a who's who of today's software giants: BEA, Oracle, Motorola, IBM, Intel, Red Hat, Ericsson, and numerous others. Among the few absentees are Sun. The OSGi component software module model covers not only the execution environment, but encompasses life cycle management, as well as a registry of discoverable services. The technology is used today by the Eclipse framework and, along with the Standard Widget Toolkit, underpins applications built on the Rich Client Platform. A sensible strategy going forward would be for OSGi's Java component model to be included in the language. Such an initiative exists: Java Specification Request 291. JSR 291 was recently ratified by the JCP, a move that is goodness to all, from Java developers who can now build more flexible and robust applications, right through to the end users who will enjoy having more dynamic, more resilient, and more organic applications on their desktops, their servers, and their mobile devices. Everyone wins.

For some strange reason though, a cloud still lurks over JSR 291. Sun voted against ratification of JSR 291 in a move that many in the community are unable to reconcile as nothing more than an extreme case of NIH. In their defense Sun did have one other community member who voted with them to block the OSGi work becoming the de-facto Java module mechanism, Hani Suleiman, a gentleman not shy of sharing his opinions on the subject (www.eclipsezone.com/eclipse/forums/t92517.rhtml#92138332).

To complicate matters for JSR watchers, there is JSR 277 whose goal is to create a new static component model for Java 7. Many believe it is some kind of last ditch rearguard action to undermine JSR 291, OSGi, and, by ironic inference, the JCP.

Edmund Burke, the English philosopher, once remarked that, "The only thing necessary for the triumph of evil is for good men to do nothing." He was remarking about the fact that if nothing is done to counteract belligerence, arrogance, and bellicose behavior, then it will ultimately succeed. What I find remarkably refreshing about the Java space, however, is that time after time the recipe that triumphs for success is for strong positive arguments, strong technology, and strong communities to come together and tackle problems collectively. Those who choose not to participate are left behind and the consensus moves forward to a better place for the greater good of all involved.

As users of Java technology, we are all ultimately judged by the ability of the applications we build using the Java language to succeed or fail in front of our end users. The best way to serve them is to remain focused on their goals and wishes, collaborating with others if necessary to find answers to common problems, and intelligently assessing and adopting technology where relevant and applicable. The worst way to serve our end users is to adopt nihilistic attitudes to other's work, to engage in newsgroup insult wars over complex issues, or to attempt to apply a form of Java government that, like the ClassLoader, while rele-vant in the previous millennium, no longer pulls its weight today and is merely dated, anachronistic, and ineffective.