Oracle to Support Eclipse - Submits Standard IDE Extension JSR

Discussions

News: Oracle to Support Eclipse - Submits Standard IDE Extension JSR

  1. Oracle announced today (at Oracle World) that it is intending to support Eclipse in its JDeveloper tool, and has submited a JSR 198, a Standard Extension API for IDE's, to the JCP process. JSR 198 is a proposal to create a standard interface for adding extensions to Java IDEs, allowing the creation of IDE-portable plugins/addon tools.

    You can read about JSR 198 here.

    The story about the Oracle support is still not fully published, but it has appeared on the conference newspaper.

    Threaded Messages (20)

  2. I like the intentions of JSR. The standard would make it easier for tool vendors to build effective, universally useable plug-ins, as well as force the IDE vendors to differentiate themselves with innovations other than plugin API's.

    However, I'd be really impressed if this JSR can actually be pulled off into a spec. Imagine how difficult it will be for major tool vendors to agree on standards for even a few of the following (from the JSR page):

    1. Menus - The addin will be able to add menu items to the IDE
    1. Menubar menus
    2. Context menus
    3. Toolbar items
    4. New Gallery items (if present)
    2. Project Tree - The addin will be able to add nodes and node types to the tree or similar component that manages the project files. This is often called the navigator.
    1. Editor - The addin will be able to register an editor for a particular navigator node type
    3. Wizards - The addin will be able to add custom wizards to the IDE
    4. Source File
    1. Listeners - The addin will be able to listen for changes on the in-memory source file
    2. Buffer - The addin will be able to get/set the contents of a source file buffer
    5. Data Model - The addin will have access to the metadata model for a source file (Class, method, members, etc.)
    6. Preferences
    7. Log Window - The addin will be able to write to the IDE log window
  3. oh well.. hope there will be something as easy to use as visual studio..
  4. From the JSR..
    </>2.5 Please give a short description of the underlying technology or technologies:
    J2SE, AWT, Swing </>

    I personally use Eclipse and like SWT. Hopefully they wont set standards that would restrict anyone to use AWT/Swing

    regards,
    Khadar
  5. I saw a quote somewhere from an Oracle spokesperson who said one of the things they want to do is to try to steer Eclipse onto a more "standards-based" course. I take this to mean that they're going to push for deprecating SWT in favor of AWT/Swing.

    I personally think this would be a huge mistake, because one of SWT's major advantages, although it is not 100% Pure Java, is that interfaces built in SWT are more performant, and performant interfaces are more likely to keep users engaged.
  6. <Q>oh well.. hope there will be something as easy to use as visual studio..
    </Q>
    I use VS, VS.Net and Eclipse/WSAD. No need to hope. There is something.
  7. I think this is a very good idea, but it will need the support of Borland and IBM, in addition to the three IDE vendors mentioned in the JSR.

    <Quote from the JSR>
    Supporting this JSR:

    Sun, Macromedia, JetBrains
    </Quote from the JSR>

    (JetBrains is the vendor of IntelliJ IDEA 3.0, which now has an extension API for plugins.)
  8. Borland also have their OpenTools API which you can use to extend their IDE on all 14 points.
  9. Eclipse, NetBeans, JBuilder, JDeveloper ... have
    thay own API, aim of JSR 198 is to create !ONE! API.
  10. Acutally, the announcement is that Oracle will join Eclipse to ensure that Eclipse users can be productive when building applications for the Oracle runtime platform.

    Oracle is still committed to building and deliverying Oracle9i JDeveloper. JDeveloper will not be ported, moved or integrated with Eclipse. It will continue to be the most productive IDE for the Oracle runtimes. (as well as a kick-a*s IDE for non-Oracle runtimes as well! :)

        -ted

    Ted Farrell
    Oracle Corporation
  11. Oh cool for a moment we thought Oracle is licensing Eclipse and selling it for $10,000 :-)
  12. Oracle JDeveloper is 995$
  13. Hi Mr. Farrell,

    (a) Why did Oracle propose this? Is Oracle planning to make its Oracle/J2EE tools available on NetBeans? Will I be able to get a BC4J module for NetBeans? I like NetBeans and I think it would be great if I could developer BC4J applications inside of it. Unless JDeveloper's GUI builder is going to get major improvements soon, I'd rather use NetBeans' UI builder for my BC4J projects. But I am using JDeveloper only because of the BC4J "module". Maybe Oracle is planning to provide all its J2EE tools as modules for other major IDE's and try to beat its competitors in their own back yards? (Since its competitors seem to only differentiate their free vs. enterprise editions by the J2EE tools and support).

    (b) I'm curious about why Oracle doesn't create a JSR for BC4J? Do you want to keep it proprietary? Is there resistence from the rest of the JCP? Is it not stable enough yet? Are you worried that JCP would butcher it?

    Reply in private if you'd rather not reply in public: brian-l-smith at uiowa dot edu

    Thanks,
    Brian
  14. Hey Brian,

    The JSR is to help third-parties, ISVs or individual users of the IDEs be able to write their extension to the IDE once, and have it work with any IDE that complies with the JSR 198 spec. So someone writing an extension to NetBeans, for example, could also run that extension in Oracle9i JDeveloper, and visa-versa.

    As far as BC4J goes, we are glad you like it. We think it is a very powerful framework to help users build applications. We don't have any plans to port the BC4J design-time technology to any other IDE right now, but you can use the BC4J runtime without the design-time. You will see some nice improvments coming to BC4J and the rest of our framework (both runtime and design-time) in the next 6-9 months.

    As far as the BC4J JSR goes, we do plan to start working to standardize some of this. The industry has already started to standardize some of the framework technology with Java Server Faces, but we believe there is much more on the model side as well. We are currently working through some of the next generation of designs for where we are taking the frameworks. Once that is complete, we will be submitting some of the technology to try and get the industry standarizing framework metadata as well.

    Hope this answers your questions. Thanks for the support.

    (and yes I think Oracle9i JDeveloper is a kick-a*s IDE! :)

       -ted
  15. From Ted (Oracle)(...as well as a kick-a*s IDE for non-Oracle runtimes as well! :)

    Do you really mean JDeveloper is a kiss-a*s IDE ?

    Tieu Chu
  16. Hi,

    I like standards, but I don't think that standards are always a plus.
    Sometimes standards will stop innovations. One of the biggest criterias for choosing an App.Server is its J2EE certification. So neither WebSphere nor Weblogic (or others) will make big moves and new concepts if therfore they wouldn't get the certification. The only possibility is to add some features to the standard but not to go new ways. But for AppServers I think the benefit of the standard is much bigger than the lost of innovation.
    For IDEs I like companies that go new concepts (e.g. IntelliJ, Eclipse). Look at the different kinds of IDEs TogetherJ vs Eclipse vs vi...I don't want standards for IDEs - let them all innovate!

    Grüße,
    Mirko
    :wq
  17. I think this is a good thing and in no means slows or stops innovation. I think it is quite the opposite. Now anyone can build a plugin that fits all IDEs supporting the standard. I think this will make plugins even more popular and will add quality commercial offerings. You can still use the IDE you like the best, or on the other hand, you can use the same plugin you like with any of the IDEs.
  18. This could be helpful[ Go to top ]

    Because such a standard API was not in place, we had to develop our own over the past few years for use with our ObjectAssembler product. Our API is called the Virtual IDE (or VIDE), and it allows us to support any IDE that has a fairly complete open API without making changes to ObjectAssembler itself. It is internally programmed to the set of interfaces that make up the VIDE, and only a small adaptor is necessary to "plug in" to an IDE.

    A standard interface-based API would have allowed us to concentrate on other things. It would be nice to see vendors of all popular Java IDEs get involved in this effort to save others the trouble.

    Regards,
    Bill Willis
    ObjectVenture Inc.
  19. <quote>
    I like standards, but I don't think that standards are always a plus.
    </quote>
    I agree with you on this. While it would be nice for plugins to work seamlessly across IDE's ,I doubt whether this is acheivable. I have a feeling that at the end of this exercise this JSR would end up being ignored.
    The IDE's are radically different in their approaches to plugins. My fear is the output of this JSR will be a large, impractical and bloated API which will be difficult to work with.
  20. I can certainly understand your fear, but our experience tells us otherwise. Our equivalent to what this JSR is trying to accomplish is actually small in size. Each IDE's plugin API is hidden beneath our abstraction layer, and it has worked very well with a number of different IDEs. Of course, this was not done in the "design-by-committe" environment that will be likely for this JSR.

    In reality, all IDEs need to supply the same basic set of services to plugins. The set of APIs may be different, but that is mostly a cosmetic issue. Hiding these proprietary APIs under a standard one isn't that big of a deal. The only potential problems I see here are politics and possibly the Swing vs. AWT thing.

    Regards,
    Bill Willis
    ObjectVenture Inc.
  21. In the Eclipse universe, the IDE can be extended via
    "plugins"

    http://www.eclipse.org/pde/index.html

    http://dev.eclipse.org:8080/help/help.jsp