Welcome Guest!
Create Account | Login
Locator+ Code:

FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly

Java's Innovation Engine
Guest Opinion by Mike Milinkovich

April 6, 2006

The trend is clear, open source communities such as Apache and Eclipse are driving the innovation taking place in Java today. And this is very good news for all of us who care deeply about the future of Java.


From its inception, the Java Community Process (JCP) was developed to bring order and process to the development of standard APIs across Java. The focus at Sun Microsystems was to ensure a cohesive intellectual property policy, API compliance testing, and a controlling interest in all Java-branded technology. By all measures it has been a success, and the current mainstream success enjoyed by Java is owed in no small measure to the successful execution of the JCP process.

However, this success came at a cost: stifled innovation. It should be no surprise that standards-setting bodies are not the place for developers to push the envelope. Great ideas are neither created nor evangelized by committees, no matter how expert. The result? Compare and contrast the utility of Enterprise JavaBeans (EJB) 1.0 entity beans versus Hibernate, or the EJB container versus Spring to name just two.

The reason why open source projects are innovation engines is inherent in the processes used by those communities. The transparency of open source requires that both ideas and their tangible implementations are exposed to the never-ending scrutiny and criticism of a broad-based cohort of developers attempting to build and deploy working systems. It is Darwinism at its finest, where weak ideas and shoddy implementations are quickly relegated to the CVS attics of the world. But just as importantly, open source is where great ideas implemented gracefully inspire and excite developers to use and evolve them quickly.

Another important facet of great ideas is that they inspire controversy. One of my favorite blogs is "Creating Passionate Users," where Kathy Sierra regularly makes the point that if a new idea is met with consensus approval, it's probably uninteresting. Great ideas and innovations change things, and change inevitably meets with resistance. In other words, if you're not at least occasionally pissing people off, you're probably not trying.

What are some of the key Java innovations that were born in open source? There are too many to list in the space here, but a small sampling of my personal favorites would include Struts, Spring, Hibernate, Matisse, and the Standard Widget Toolkit (SWT).

Apache Struts delivered a working Model-View-Controller (MVC) pattern implementation to Java Web development. The Spring framework is most popular among the lightweight containers, and it allows developers to focus on the business logic rather than expending effort on working with containerisms. Hibernate is the practical alternative to EJB persistence, and it allows developers to develop complex applications with persistent POJOs.

By all reports, Matisse is a slick GUI builder for Java that introduces its own LayoutManager (GroupLayout) that is distinct from those provided by the JDK. An interesting illustration of this article's premise is that even Sun has turned to its NetBeans open source project to create innovation. Probably the poster child for a great idea that inspires controversy, SWT gives Java developers the freedom to create first-class native applications on many platforms. Say what you want about the Swing versus SWT religious war. Enabling the freedom to build a type of application not previously possible with Java is a useful innovation for the platform and the community.

I am sure that there are no surprises in that list. Everyone has heard of those frameworks, and most have at least tried them out. The real point is that none of those highly useful tools could have possibly been brought into this world through a standards process. The processes of reasonable negotiation, of compromise, and of reconciling competing corporate agendas serve to smooth the rough edges and dull the brilliance of great ideas. Every one of those examples is ultimately the work of either a single person or a very small group of people striving to solve a difficult problem with style and grace.

If open source is clearly where innovation is occurring, does that mean that the JCP has no role? Not at all. There are good reasons to create standards. They provide a very important element of investment protection for the companies that adopt Java technology for their products and/or internal enterprise systems. However, in a perfect world, we would start to see the JCP consciously working with the broader Java community to attract the projects and ideas that have been clearly shown in the marketplace to be successful. Innovate first, demonstrate utility and adoption second, and then standardize.

The inclusion of many of the best ideas from Hibernate in EJB 3.0 is a demonstration of this process in action. There are signs that some day GroupLayout may migrate from Matisse to the JDK. Yet in many cases the JCP ignores the open source alternatives, or worse yet, in cases like JSR 198 (versus Eclipse) and JSR 277 (versus Apache Felix and Eclipse Equinox), views them as competitors that must be avoided—to the detriment of Java supporters everywhere.

About the Author
Mike Milinkovich is executive director of the Eclipse Foundation Inc.

Back to top

Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home