|
YOUR FEEDBACK
Did you read today's front page stories & breaking news?
SYS-CON.TV |
TOP THREE LINKS YOU MUST CLICK ON Editorial Java Editorial — Not Invented Here: Reject, Repulse, and Reinvent
The phrase 'not invented here,' or NIH describes a resistance by a group to use a perfectly valid solution
By: Joe Winchester
Apr. 25, 2007 09:00 PM
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.
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. LATEST JAVA STORIES & POSTS
SUBSCRIBE TO THE WORLD'S MOST POWERFUL NEWSLETTERS SUBSCRIBE TO OUR RSS FEEDS & GET YOUR SYS-CON NEWS LIVE!
|
SYS-CON FEATURED WHITEPAPERS MOST READ THIS WEEK SPONSORED BY INFRAGISTICS
BREAKING JAVA NEWS
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||