JSR 198 IDE extension API still alive: Early Draft Review Posted

Discussions

News: JSR 198 IDE extension API still alive: Early Draft Review Posted

  1. JSR 198 was first proposed by Oracle in 2002, as way to level the IDE marketplace by creating a standard API and programming model for building IDE plugins, since currently all the major IDE's have their own plugin mechanism, with Eclipse being the market leader.

    Little has been publically said or published about this effort in recent years, until yesterday, when the spec team published an early draft review of the Java programming model.

    There is also a Java One session scheduled called JSR 198: Standardizing the IDE Extension Architecture (TS-7774).

    The progress might be a little too late, since Borland recently recognized Eclipse as the defacto standard by announcing that they will be basing future versions of JBuilder on Eclipse.

    Does this release really mark industry consensus or could this release be an Oracle & Sun partnership aimed at creating an official "non-eclipse" plugin ecosystem? Should Eclipse implement this JSR as well? We will certainly know once the spec reaches EC public review ballot.

    Threaded Messages (3)

  2. Finally....[ Go to top ]

    I spent the last year checking its JSR page for see any news.

    I really was loosing my hope until I saw the Java One session.


    I think it is a big step futher for allow non mainstream IDEs to survive.

    Cheers
     JD
  3. some light...[ Go to top ]

    i also asked myself whats wrong with this spec and have written a blog entry about it. In the comments you can see a quote from one of the EC members.

    http://www.logemann.org/blojsom/blog/default/2005/04/04/JSR_198_no_future_for_unified_IDE_plugin_architecture.html

    This was of course before Borland joined Eclipse.

    Marc
  4. Nothing new[ Go to top ]

    I think that the overall goal is good but out of reach. Each single IDE is currently implementing the same ideas in different way: be able to handle different language within the same IDE and exposing the same user experience, incremental build, project management etc - with more or less success. This so far means that as a plugin provider (commercial or open source) you have to choose one horse (which is sad), wether pay the cost of porting your plugin as you can (which often you cannot afford).

    IntelliJ EAP (upcoming v5) has already most of the things proposed in this JSR - f.e. an AST to represent the source code for all kind of language, a virtual file system, a build listener etc. The whole on top of PicoContainer.
    Eclipse as much of it as well in very different forms though, the whole on top of OSGi things.
    There is a JSR for dealing with the compiler as well (JSR-199) and have an easy way to gets its output in a rich format.
    There is also the Java 5 APT and the JSR 269 that defines an AST as well (though not complete, method body structures are not exposed in the AST f.e.).

    So that sounds to me yet another JSR. I 'd rather have someone write a good book on writing plugin for IntelliJ 5 or NetBeans and have the community draw best practices on how to do the common things, instead of locking everyone in a common API that would enforce the IDE folks to redo what they already have (in all cases, plugin folks have to rewrite..)

    I have learned a lot in this area for the http://backport175.codehaus.org plugins that I wrote for Eclipse and IntelliJ. I am sure each IDE community has to learn from the other, but I am not sure we all need a JSR for that.
    By the way will there be a RI for that JSR ?
    Alex