In my last editorial (Vol. 8, issue 6), I argued that we, as an industry, have too much innovation. We have solutions pouring out our ears, stuff we often don't need, yet we use it anyway. This month, I'd like to clarify that somewhat: we need more innovation.

The seeds for innovation are already present: new projects are fertile ground. The problems are often unique, so the solutions that present themselves are individual as well. What's more, sometimes there's a better solution that's simply waiting for the right viewpoint in order to become obvious.

New solutions often imply new technology. Without innovation, we'd be using batch programs to generate paper results overnight. Instead, we had online transactions, the Web, CGI, then mechanisms to improve even that in various ways. All are necessary steps in innovation, and I don't think we've seen the end of online transactions or information presentation yet.

To judge whether we need to create a new solution, we first have to investigate what already exists. We must be willing to accept investigation, especially at a local level, and accept what the results are, even if they go against what we want. We may want to create a new invocation framework; it could be fun to write! However, the costs in terms of development and implementation might not justify the creation of yet another solution.

Once we've accepted that existing solutions aren't going to be enough, it's time to start thinking about how it should be done. This is where the creative juices start flowing, and new ideas wend their way into the light. This is where old ways of doing things die out in a Darwinian survival of the fittest. We need to be willing to kill bad solutions in favor of better, more flexible ones.

Java, as a community, needs to be prepared to do the same - Java itself is susceptible to being outmoded by new technology. If we want "Java" to survive as a name and brand, we must encourage innovation and accept honest evaluation of its strengths and weaknesses in the market - official approval in the form of the JCP isn't enough to keep Java alive. The technology that the JCP puts out needs adherents, adherents in the real world and not just JSR participants or yea-sayers.

It's hard to understate that last point. The JCP tends to foist new standards on an industry that's often watching the rank and file moving in different directions. Look at JDO: some companies were using fairly popular JDO implementations before the JCP started their JDO specification, and the resulting specification ended up invalidating the prior art, even though the prior implementations didn't need as much repair as the specification might have implied.

Standards are best generated from what people are using, not from what people in a boardroom think should be used. The market moves faster than a standards document can. The open source community understands this. So does Microsoft, who tends to flood the market with new products if only to make sure that they're perceived as innovators. As a result, you see the most impressive things from open source initiatives, which can move faster than Sun seems to want to. Some of these will end up working against Sun's vision of Java, and that's all right.

The key is when to innovate and when not to. Innovation should be spurred by fresh, clear ideas about how things might be done better, while acknowledging that industry momentum isn't something to ignore. You shouldn't be creating another solution that duplicates the weaknesses of one that already exists - try to repair the existing one instead.

Therefore, a larger problem is indicated: How do we learn what solutions are out there? There are sites like http://freshmeat.net and others, but those aren't enough; they only echo data that's pushed to them.

If you're working on a project, you should be talking about it, even prematurely. Create an RSS feed, and let various aggregators like http://technews.n-ary.com and http://javablogs.com know about it. Watch these sites and participate in the overall community as much as your time permits. Eventually you learn which way the wind blows, and how to leverage all that information to your benefit.