Printed: Aug 3, 2015
|Apache Software Foundation||BEA Systems||Boeing|
|Borland Software Corporation||Dearle, Fergal||IBM|
|IOPSIS Software Inc.||Lawson Software||Metrowerks|
|Novell, Inc.||Oracle||Pramati Technologies|
|Quest Software Inc.||RedHat||SAP AG|
|SAS Institute Inc.||Sun Microsystems, Inc.||TmaxSoft, Inc.|
|Zero G Software|
Original Java Specification Request (JSR)
Original Summary: JSR 198 is a proposal to create a standard interface for adding extensions to Java Integrated Development Environments (IDEs). This will allow vendors to write an IDE extension once, and have it work on any J2SE-compliant IDE.
Section 1. Identification
Submitting Member: Oracle Corporation
Name of Contact Person: Ted Farrell
E-Mail Address: Ted.Farrell@oracle.com
Telephone Number: +1 650 506 9812
Specification Lead: Jose R. Cronembold
E-Mail Address: Jose.Cronembold@oracle.com
Telephone Number: +1 650 506 6459
Initial Expert Group Membership:
Supporting this JSR:
Sun, Macromedia, JetBrains
Section 2: Request
There are a diverse set of IDE products that are designed from the ground up to be extensible platforms where third parties can plug-in new addins to enhance an IDE with additional features. In general, these third party modules are only compatible with the integration API of single IDE. Examining the IDE-Tool integration layer that typical IDE platforms provide it can be observed that:
1. It is a very thin layer of code (compared to the amount of code generally written by the third party to implement a useful tool),
2. There are many areas of similarity between the integration layers of the different IDEs.
This proposed specification has the goal of defining a standard IDE extension API that allows developers to implement IDE addin modules once and have their feature run with any IDE supporting the standard specification.
Where there are many areas of integration that could be addressed in this JSR, for purposes of the first scope, viability and time, this JSR will focus on the following IDE addin integration points:
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.)
7. Log Window - The addin will be able to write to the IDE log window
In conclusion, the Extension API specification defines interfaces that standardize each of the integration points listed above. The proposed Extension API is fully based on the Java 2 platform and does not introduce any proprietary components. Also note that it is up to the individual IDEs to determine how to support these interfaces.
JavaTM 2, Standard Edition
The need for a standard IDE extension API that allows developers to implement IDE addins once and have their feature work on any IDE supporting this specification.
Currently, there are no standards addressing this need. Currently all vendors, include Sun Forte (fka: NetBeans) and Eclipse have competing, proprietary technology for IDE integration. While all of these technologies are good, viable solutions for each particular vendor, without a standard interface the industry is still left with having to write addins multiple times to support each vendor's envionrment.
J2SE, AWT, Swing
The delivered API will feature support for I18N.
EG selected : December 15, 2002
First working draft : March 15, 2003
Email, phone conference, etc. (TBD)
The RI & TCK will be stand-alone and based off of J2SE 1.4 or higher.
It is Oracle's intention to create open source licenses that are as similar as possible to an "Apache"-style license. Additions or changes to this basic open source format will be limited to those terms required to comply with the JSPA, or which explain terms or limitations of the licenses granted under the JSPA. Currently intended terms are as follows:
Oracle will grant a royalty-free source code license to use, modify and distribute the Reference Implementation.
2. Oracle will grant a royalty-free license to use the Specification to create a compliant implementation of the Specification, which may be distributed to third parties.
3. Because of requirements in the JSPA, the Specification license will require that implementations of the Specification must (a) fully implement the specification including all of its required interfaces and functionality; (b) not modify, subset, superset or otherwise extend the Licensor Name Space (defined as the public class or interface declarations whose names begin with "java", "javax", "com.sun", or "com.
4. As part of the licenses, Oracle will grant an associated patent license under Oracle patent rights, but solely to the extent that such patent rights are essential to implement the Specification. As appropriate, Oracle may indicate in the licenses that under the JSP contributors other than Oracle may be allowed to require an additional patent license for implementations on "fair and reasonable terms" (which may include royalties).
5. Oracle may condition the license grants on the licensee's commitment to offer a license to those of the licensee's patent rights that are essential to implementing the Specification to other licensees on reasonable and non-discriminatory terms.
6. Although Oracle will place no restrictions on modifications that may be made by or license terms given to "downstream" licensees, it is Oracle's intention to clarify in the licenses, that under the JSPA, no copyright or patent licenses are granted for any non-compliant implementation made by downstream licensees, whether independent or based on the reference implementation.
7. Oracle will grant a royalty-free license to use the TCK to determine if an implementation is compliant.
8. Oracle makes no warranties with respect to the Specification, Reference Implementation, Test Suites or other distributed materials, and all liability is excluded.
9. A licensee's rights and licenses terminate in the event the licensee brings or threatens suit against Oracle or any other licensee based on a claim of infringement of intellectual property rights as a result of use of the Specification, Reference Implementation, or Test Suites.
Section 3: Contributions
Because all vendors currently have different IDEs, APIs and functionality, it is considered best to wait and let the initial EG determine the initial draft and APIs for this JSR.