JSR 198: A Standard Extension API for Integrated Development Environments

Look in Section 1. Identification

> Supporting this JSR:
>
> Sun, Macromedia, JetBrains

Bas

Norris Shelton wrote:

Is this on JetBrains radar?

http://www.logemann.org/day/archives/000114.html

http://jcp.org/en/jsr/detail?id=198

Correct, however the JSR shows a Finish date of 2002.

Norris Shelton
Sun Certified Java Programmer




Bas Leijdekkers wrote:

Look in Section 1. Identification

>

Supporting this JSR:

>

Sun, Macromedia, JetBrains

>

Bas

>

Norris Shelton wrote:

>
>> Is this on JetBrains radar?
>>
>> http://www.logemann.org/day/archives/000114.html
>>
>> http://jcp.org/en/jsr/detail?id=198
>>

Not the full JSR finish date. The JSR Review Ballot finished on 25 Nov, 2002 with the current status for the JSR being "In Progress".

That being said, if you ask me, JSR198 was doomed to fail from the start. There's just no way to standardize on something so complex (and everchanging) as development environments, and if that ever happened, every vendor would provide their own "extensions", killing the whole point.

Pre: This post got longer than intended, if you take the time to read it and have comments please also take the time to comment :)
To JetBrains: I hope one of you guys reads this, I've put quite some work into this essay ;)

But they could at least standardize on a "least common": Sure, this API may not expose all capabilities of the IDE's native API, not even in such simple areas as message display, and yes, using this "common" API will probably be slower than using the IDE's native one (for message showing, neglectible, but for parsed Java source access (AST access), well... since IDE's are established the "new" API will probably be implemented as wrapper to the native ones) BUT it would help "serious" plugins (i.e. plugins which required a lot of effort to create) a sort of "jumpstart" to support multiple IDEs.
This would allow plugin vendors to use the same codebase for "simple" things like message display, providing a "wizard" for something and son on but it would even help them save quite a bit of effort for "more complex" things like:
Acquiring an "editor space" in the IDE (e.g. UMNL tools not specifically created for the IDE like Together, Visual Paradigm, Magic Draw UML, ...).
Providing AppServer plugins: Most, if not all, IDEs could profit very much of it; IDEA supports very few and only WebLogic and JBoss (thanks to Martin Fuhrer, again... keep up the good work!) are really convenient to use, no IDE but NB supports SunAS 8 (won't discuss this further, but would have preferred it over JBoss for development mainly because its more strict about J2EE conformance, JBoss will run everything thats closer to an EJB than to a bowl of froot loops).
Basic Version Control plugins (for tighter integration, may need to add IDE-native API usage) or base for VCS plugins. What a pity that these plugins are not portable between IDEs, I wonder how many cool features could have been created if there was only a single one CVS plugin developed for all vendors instead of everyone creating their own (similar) one (and, AFAIK, all of Borland, Oracle, JetBrains, Sun/NetBeans and IBM/Eclipse Foundation have created at least two implementations of it (or at least put significant effort into enhancements/rewrite) b/c the first version was lacking).
Metrics and Inspections: Only basic common access to parsed java source (or e.g. bytecode-based trees in JBuilder, whatever) is necessary. From here on, vendors will need to also use the IDE's native API but that's ok. Everything from here on is probably IDE specific from a user's point of view nonetheless and may only make sense in a specific IDE (e.g. advanced refactorings for IDEA).

Above kinds of plugins that are only "loosely" integrated with the IDE but require quite a bit of effort to integrate with each and every IDE could benefit a lot; sure, more complex and tightly integrated ones don't work this way and still, Eclipse plugins won't easily be portable (who again did vote for SWT???).
Portable plugins, especially "without" Eclipse, i.e. IDEA, NetBeans, JBuilder, JDeveloper, ... will only benefit these vendors to compete with Eclipse. Neither of these IDEs has an advantage because of the masses of plugins available (closest is probably JBuilder) but because of inherent advantages in the IDE (JB IDEA is the best example here), all lose versus Eclipse (probably the most serious enemy for all of them) in this area, so ...
I'm not involved with the JSR, so I cannot really say, but could it be it was too ambitious and wanted to standardize too much? Maybe even take some differentiation from vendors? Probably involved parties should re-think it and quickly create a first release for at least the basic APIs to be offered by all/most IDEs. You can still add advanced functionality in the next step.

regards,

Messi

P.S.: Sorry for the long post, just wanted to comment quickly but than it got more and more ;)

As a plugin author, I have to wonder if there are any valuable IDEA or Eclipse plugins that would work under the competition's IDE. Had Eclipse gone with Swing rather than SWT I could see the potential advantage of this, but otherwise it seems kind of fruitless to me (or "fruit-loops" as my 3-year-old daughter says). Bar a few editor hacks I'm not sure just what even a perfect JSR 198 implementation would enable. If it has a visible GUI, it can't be shared, and that's sadly the state of the world.

--Dave Griffith

I haven't read the JSR in a while, but doesn't it include a common API for interacting with the code like with Idea's PSI? If so, then a common API for just that alone would be enough to create a lot of shared code for plugins.

I think SWT can host Swing components.

As a plugin author, I have to wonder if there are any valuable IDEA
or Eclipse plugins that would work under the competition's IDE. Had
Eclipse gone with Swing rather than SWT I could see the potential
advantage of this, but otherwise it seems kind of fruitless to me (or
"fruit-loops" as my 3-year-old daughter says). Bar a few editor hacks
I'm not sure just what even a perfect JSR 198 implementation would
enable. If it has a visible GUI, it can't be shared, and that's
sadly the state of the world.

--Dave Griffith

It does, but this kills the whole point about using SWT in the first place. I can already see an eclipse user screaming aloud and twitching on the ground after noticing one of the the plugins are using Swing.

I wonder, I mentioned some examples above, would you say they would not be able to share more code for IDE-versions. I don't say you could use anything but the very simple plugins (with another IDE as first designed for) without modifying the sources for it, so "true" WORA is probably impossible to achieve (I fear they tried with JSR 198 and therefore didn't come up with something for such a long time. Someone may even speculate that, because Eclipse definitely got the wealthiest plugin-community over time, IBM was, at some point, no more interested, maybe even hindered the JSR...) but there is lots of benefit when plugins developers would be able to share more of the sources for different IDEs.
Regarding the UI, well, some plugins (probably UML tools) only need an editor space (so probably a JPanel) and this could be cross-"platform"; also, the UI components may be shared at a low level (taking out eclipse) but probably plugins that really "integrate well" with the IDE (so don't use their own UI but tries to mimic the IDE as good as possible) will need their own UI for each IDE even it was possible to use the same API everywhere (it is, to a certain degree: Swing, just add the hooks) - unless the JSR provides a more abstract UI-API (in a second revision maybe) like "registerWizard()" as a very simple example
Still, the more "interesting" APIs are abstract ones, like (maybe only readonly) accessing parsed sources. A non-abstract common UI API may still provide a Jumpstart for integrating a plugin with another IDE.
Think about an UML tool: The UI is easily integrateable are, on the one hand only a few menuitems to add, and on the other hand, the tool only needs a JPanel to display (e.g. SimpleUML, VP SDE).
Still, there is a major problem: All sourcecode will be parsed (and kept in RAM as such) TWICE, once by IDEA and another time by the UML tool (and a third time by the compiler, but that will be freed again); isn't it strange to parse the same sources multiple times within the same IDE? Someone can see this very well with e.g. JBuilder and Together. Use the Together plugin and RAM consumption (which is already high) nearly doubles (in this case the std-API would not help of course).
Sure, current vendors probably won't give up on their own engines, but new UML tools will emerge using the source-API of the IDE and concentrating on drawing - which they will then do better as a side effect, I think; additionally, sources are not parsed multiple times, only in RAM once etc. I think e.g. UML Theresa for IDEA (don't remember exact name) uses IDEA's own API (not sure though, as it doesn't support JDK 1.5 yet, which was long supported by IDEA); they could improve it much faster and sell it cheaper (well...) when they could sell for multiple IDEs, everyone would benefit (yes, I know its not THAT easy in business :)
Myself, I always have two (or three, depends on counting, see above) IDEs running, IDEA for "normal" work and JBuilderTogether for UML (somehow it seems the 2005 version of Together only supports JDK 5 within JBuilder). Sure, it could be that Borland has no interest to port Together to IDEA, but I don't think so, they behave like (and even said so) "The Switzerland of Development Tools". I probably could use IDEATogether in a single IDE with JDK 5 support this way. Just dreaming of a bright devtools future...
As already said, this would also create a "counterpart" to Eclipse and, as stated above, would more likely allow us to match and mix (IDEA is really the best code-editing IDE, but it lacks quite a few fetures and not for eveything a plugin exists); I really think this common API is feasible (they said they would release something soon, right?) and would ease plugin-developers' jobs a lot, disagree that no unified API that has sufficient functionality can be created.

regards,

Messi

It seems SWT somehow creates a l33t ;) community again. Sure, quite a few using it as "right tool for the job" but they wouldn't complain for a good Swing plugin in Eclipse - many (most?) Eclipse users will.
My god, such "communities" are really a pity, don't help anyone.

Messi

Absolutely correct. And besides making life easier for plugin-devs it will also eliminate the double-parsing of sourcecode in many cases (1. IDE 2. e.g. UML tool).

Messi