|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 14
Messages: 14
Messages: 14
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
JSR 198, IDE Extension API, voted on: passes with abstentions
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?
|
Threaded replies
| · |
sga
by
li lim
on Fri Jun 26 23:31:21 EDT 2009
|
|
|
Message #201674
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR 198, IDE Extension API, voted on: passes with abstentions
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.
|
|
|
Message #201680
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Very good news...
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
|
|
|
Message #201681
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Corporate Politics
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.
|
|
|
Message #201682
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BEA is quoted false
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.
|
|
|
Message #201683
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR 198, IDE Extension API, voted on: passes with abstentions
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!
|
|
|
Message #201685
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BEA is quoted false
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.
|
|
|
Message #201742
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR-198 is needed
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.
|
|
|
Message #201753
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Eclipse vs. the rest
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.
|
|
|
Message #201756
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR 198, IDE Extension API, voted on: passes with abstentions
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.
|
|
|
Message #201775
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This is what I was waiting for
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!
|
|
|
Message #201981
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This is what I was waiting for
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!
|
|
|
Message #202014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This is what I was waiting for
Now, you can target your plugin at JSR 198 and nothing will run it!
:))
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
