JSR-198, the Standard Extension API for Integrated Development Environments, has been finalized. The specification is available for download from the JCP.

The specification covers all of the following points, which is... something to consider:

Where there are many areas of integration that could be addressed by this specification, for purposes of the first scope, viability, and time, this version of the ESDK covers integration points that allow extension writers to:

• Extend the IDE with new menus and commands
• Extend the IDE data model with additional document types
• Extend the IDE with new document creation wizards
• Extend the IDE with new editor types
• Extend the IDE new log pages
• Extend the IDE preferences and project settings with new property pages
• Define extension specific extension points
• Access the IDE Environment information
• Access extension registration information
• Access project information
• Access the Java structure model
• Access the XML structure model
• Access textual data
• Manipulate documents through a virtual file system
• Listen for data model change events
• Listen for IDE events
• Interact with the compiler
• Interact with the debugger
• Use IDE utilities such as message, warning, and error dialogs

The question remains: which IDEs will implement this specification, and why?

I would love for this specification to be a success, but frankly I just don't see it happening. I'm an IntelliJ IDEA user. I use it because I think it's the best IDE out there.

IMHO the only advantage Eclipse has (other than price - but $500 for increased productivity is cheap) is the wealth of plugins. If all the plugins that are available for Eclipse were available for all IDEs then I think Eclipse would see it's market share slip.

But it's a chicken and egg situation. Folks won't start writing to the standard extension API instead of the Eclipse API until Eclipse supports it. And why would Eclipse support it when most plugins are already written (and tied to) Eclipse? This is of course assuming that any technical challenges related to SWT/AWT plugins can be resolved.

I hope I'm wrong and that the Eclipse folks step up and do what's best for the whole community here, but I sincerely doubt it's going to happen.

-Tim Fennell
Stripes: Because web development should just be easier.

I don't see the standard extension API as being practical for Eclipse until there's a Swing/SWT bridge that produces components that look native to SWT. One of the things that I find irritating is plugins that are just a thin layer of code interfacing to a program that uses Swing and significantly different click behaviors.

I think the idea is great. Very ambitious so yeah, it remains to be seen what the net result would be. But I'd sure like to be able to write plugins once and run them in several IDEs. Even if it would work for, say, 30% of common plugins, it would be a win.

Btw, I think Eclipse is supporting open development quite ok. Look at what they do for/ with OSGi. Great stuff if you ask me.

Tim,

This is not a problem of Eclipse being obstructive to an otherwise well-supported Java standard. Eclipse will implement JSR 198 if there is a clear market demand for it.

The problem is this: who will develop their plugins against the JSR 198 model, when they could achieve much better integration by using each IDE's own API? This is the case even if all the major IDEs were to support 198.

Take a look at the comments that BEA, SAS, Intel and Hani Suleiman attached to their Abstain votes - they all make exactly this point.

Regards,
Neil

Tim,This is not a problem of Eclipse being obstructive to an otherwise well-supported Java standard. Eclipse will implement JSR 198 if there is a clear market demand for it.The problem is this: who will develop their plugins against the JSR 198 model, when they could achieve much better integration by using each IDE's own API? This is the case even if all the major IDEs were to support 198.Take a look at the comments that BEA, SAS, Intel and Hani Suleiman attached to their Abstain votes - they all make exactly this point.Regards,Neil

No, I understand. The standard has to some degree force a lowest-common-denomenator, which means that plugins written to the new standard will never have access to the complete range of things the IDE provides.

I think a perfect analog here is Swing vs. Native GUIs (let's not talk about SWT - I'm a mac user and SWT is still 2nd class on my desktop). There are things you give up by writing a GUI in Swing, but you gain cross-platform support.

The way I see it there is simply no incentive for the Eclipse Foundation to maintain a top-quality implementation of the standard, or to work to improve the standard. As another poster pointed out anyone could write a bridge-plugin. I was merely stating that I'd like to see this standard succeed, but I think the deck is stacked against it.

-Tim Fennell
Stripes: Because web development should just be easier.

yes it is!
after many years and a couple of opensource IDEs available,this spec does not provide enough functionality to write real world plugin
from the begining:
it does not support a well defined plugin lifecycle and notification mechanism,versioning is poor,inter-plugin communication and dependency is not well defined
the editor api is really primitive,you cannot write a code formatter with it
it is ties to swing/AWT(yes,look at the api)it should have been more generic
concentrate on the java model,no generic model,or even abstract element is defined for extension to b able to support new languages(even a jsp implementation will b a nightmare)
is this enough......if not, u can c for yourself and find dozens of shortcomings in it(i just have no more time to write on a bad spec,i wasted enough in investigating it)
i hope this may change soon ,BUT the sloooooow jcp cycle and the rapid market shift to eclipse make me stste that the board and the jcp easted a very crucial time to deliver a vey incomplete api
sorry for being tough and apologies to the expert group(it's not personal)
joe

The question remains: which IDEs will implement this specification, and why?

Well Oracle JDeveloper already supports this JSR.
I think it will be in the best of intrest of both Netbeans and IntelliJ to implement the JSR as well if they want to fight Eclipse.

And as far as Eclipse implementing it - it doesn't have to come from the Eclipse org... What if someone writes a JSR-198 to Eclipse bridge and sell it to companies developing plug-ins? seems like a nice little startup.... or even an open-source project.
Any takers?