Many feel the best approach is to create extensions directly for particular IDEs in order to utilize the full power of each IDE. There seems to be a healthy competition of competing popular IDEs and no consensus on the desirability of a single standard for IDE extensions.BEA, SAS, and SAP AG all had comments that Eclipse either didn't need it, or plugin vendors would write to a specific IDE's API anyway, with the following comment (from SAP) being representative:
Cross-IDE APIs may be useful for certain classes of plug-ins when support of many IDEs is the topmost concern. Nevertheless, many plug-in developers choose a specific API such as Eclipse in order to fully exploit the capabilities of the underlying IDE. Which way to go is a trade-off decision that needs to be consciously made. Even though JSR 198 will advance to an optional Java standard, it will be one of many possible IDE plug-in architectures and will need to prove itself in the market.BEA also echoed the sentiment that an Extension API might not have the industry momentum to actually matter with this abstension:
Consider this a mild protest vote, since there are more than enough votes to pass this ballot and there is no technical reason why this API could not be implemented in Eclipse (no change from my previous position), but I doubt that it will be, given current industry momemtum and most people will see that as confrontational. Hopefully the market will sort it all out in time.The JSR passed its final ballot, as mentioned, despite having the logical points here being made. Why didn't the reasons offered before serve as justification for legitimate "no" votes instead of mere absentions? Do you think JSR-198 will be adopted seriously by any of the leading IDEs, which have no real reason to do so and many technical barriers serving as reasons not to implement the spec?