Discussions

News: JSR 198, IDE Extension API, voted on: passes with abstentions

Bookmark and Share Get thread feed

  1. JSR 198, IDE Extension API, voted on: passes with abstentions (14 messages)

    JSR 198, the Extension API for Java IDEs, passed its Final Approval ballot, with ten "yes" votes, four abstentions, and two members not voting at all. What's really interesting about this is the justification behind some of the abstentions: primarily, that the extension API isn't going to be adopted widely enough to matter.

    From Intel:
    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?
    Reply to this

    Threaded Messages (14)

  2. JSR 198, IDE Extension API, voted on: passes with abstentions[ Go to top ]

    I'd say it would be better to standardise on a container like OSGI and then define a bunch of standard service interfaces that can be looked up and hooked into.

    Of course, as unlikely that all the IDE vendors will buy into a standard container as all of them implementing this JSR.
    Reply to this Reply to original

  3. Very good news...[ Go to top ]

    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?

    I think that JSR came a little too late, but even so, I think it will give a chance to the less adopted IDEs to have more plug-ins.

    I don't think that Eclipse will bother to implement it, but some 3rd party could and would it be possible to write an Eclipse plug-in that adds JSR 198 support to eclipse?? ;-)

    Is there a final decision about the RI license?

    Cheers
     JD
    Reply to this Reply to original

  4. JCP Corporate Politics[ Go to top ]

    This demonstrates in a blindingly obvious way that the corporate dominated JCP process has goals beyond open technical specifications.

    To see members stating that they do not see the point given the "momentum" behind Eclipse is ridiculous. If momentum were a factor in the market place, we would only be using Microsoft products at this point.

    What this JSR needed was the smaller, and hopefully less arrogant, tool vendors coming together to define the spec rather IDE vendors. Sun, Oracle, BEA and IBM need to get off the JCP high horse and start letting some recognized members of the larger development community play a more active role in the process.
    Reply to this Reply to original

  5. BEA is quoted false[ Go to top ]

    BEA and Intel are the same in this news, but BEA said this:

    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.
    Reply to this Reply to original

  6. BEA is quoted false[ Go to top ]

    Georg, you're right - I pulled the quote from a paste buffer that still had the Intel pull quote in it. The post has been fixed, and thank you.
    Reply to this Reply to original

  7. JSR 198, IDE Extension API, voted on: passes with abstentions[ Go to top ]

    The standard is good for sure.

    I think NetBeans (Sun) will do it. There are fewer plug-ins
    on Netbeans than Eclipse. NetBeans wants to catch up. What about Eclipse? Does Eclipse want to do it?

    IBM maybe have 50% of power to influence Eclipse to do so.
    Oracle, jBoss may have some power... If these members of
    Eclipse really want it, Eclipse will do it.

    If both Netbeans and Eclipse do it, others will follow.

    Wei Jiang
    Perfecting Java EE!
    Reply to this Reply to original

  8. JSR-198 is needed[ Go to top ]

    Do you think JSR-198 will be adopted seriously by any of the leading IDEs, which have no real reason to do so

    There is only one IDE that has no reason to adopt this JSR - Eclipse. It already has a monopoly hold on extension developers, and why would they want to open the market in a way that will allow extensions to be used on other IDEs?

    I know many people who use Eclipse just because the tools for their favorite open-source framework (think spring or hibernate) are only available as Eclipse plug-ins. If they were availble on other IDEs, these users would have switch from Eclipse.
    I'm guessing the developers of these plug-ins, be them open-source or commercial, would have been delighted at the possibility to develop the plug-in once and have it run on all the Java IDEs.

    I think that if Netbeans and IDEA will join JDeveloper and implement this JSR for their tool, they'll have a valid alternative to offer to anyone who considers developing an extension. This is their motivation for implementing the JSR.

    And maybe someone will just implement the JSR on top of the Eclipse API and then sell the implementation to any interested plug-in vendor. This way the plug-in vendor doesn't have to choose the IDE he is going to develop for, and the community doesn't need to wait for the Eclipse.
    Reply to this Reply to original

  9. Eclipse vs. the rest[ Go to top ]

    If all the Swing based IDEs (IntelliJ, NetBeans, JDevelper, ...) implement JSR 198, plugin developers would only have to write two types of plugins:

    - 1 for Eclipse + SWT/JFaces
    - 1 for JSR-198 + Swing

    If this happens it might actually result in more plugins being developed for the non-Eclipse IDEs? Anyway Eclipse is a bit special, at it doesn't use Swing, so writing plugins, that works well for Eclipse and the Swing-based IDEs migth not be easy / reasonable, even if Eclipse implements JSR-198.
    Reply to this Reply to original

  10. JSR 198, IDE Extension API, voted on: passes with abstentions[ Go to top ]

    I agree it would be very nice but their concerns about extensions is valid. It can be very hard to standardise plugins API especially since Eclipse come with so many frameworks : UML, GEK, EMF, ... wich you can't find in other IDE. From a technical point of view, I can understand their concerns but I do realize there were also strong econimocal motivations behind this vote.
    Reply to this Reply to original

  11. This is what I was waiting for[ Go to top ]

    for a long time I wanted to write some open source modules, but I couldn't choose which platform, netbeans or eclipse, now can I write my module compatible with this JSR and rest in peace!
    Reply to this Reply to original

  12. This is what I was waiting for[ Go to top ]

    You're not the only one that was waiting.

    There's a whole industry of Java tools vendors that were frustrated for years by the need to write different plugins for each IDE.

    PJ Murray, CodeFutures
    Java Persistence for Data Access Objects and Service Data Objects
    Reply to this Reply to original

  13. This is what I was waiting for[ Go to top ]

    for a long time I wanted to write some open source modules, but I couldn't choose which platform, netbeans or eclipse, now can I write my module compatible with this JSR and rest in peace!

    It's a great step forward indeed. You could target your plugin at Eclipse, but NetBeans won't run it. Or you could target your plugin at NetBeans, and Eclipse won't run it. Now, you can target your plugin at JSR 198 and nothing will run it!
    Reply to this Reply to original

  14. This is what I was waiting for[ Go to top ]

    Now, you can target your plugin at JSR 198 and nothing will run it!

    :))
    Reply to this Reply to original

  15. sga[ Go to top ]

    GOOD LIFE GODO WORK! ............................................. .............................................
    Reply to this Reply to original