• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Specification Leads
	Jose Cronembold	Oracle
Expert Group
	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.	Red Hat	SAP SE
	SAS Institute Inc.	Sun Microsystems, Inc.	TmaxSoft, Inc.
	Zero G Software

Original Java Specification Request (JSR)

Identification | Request | Contributions

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

Fax Number:

Specification Lead: Jose R. Cronembold

E-Mail Address: Jose.Cronembold@oracle.com

Telephone Number: +1 650 506 6459

Fax Number:

Initial Expert Group Membership:

Sun, Macromedia

Supporting this JSR:

Sun, Macromedia, JetBrains

Section 2: Request

2.1 Please describe the proposed Specification:

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.)
6. Preferences
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.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java^TM 2, Standard Edition

2.3 What need of the Java community will be addressed by the proposed specification?

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.

2.4 Why isn't this need met by existing specifications?

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.

2.5 Please give a short description of the underlying technology or technologies:

J2SE, AWT, Swing

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.ide.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

No

2.9 Are there any internationalization or localization issues?

The delivered API will feature support for I18N.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.11 Please describe the anticipated schedule for the development of this specification.

EG selected : December 15, 2002

First working draft : March 15, 2003

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

Email, phone conference, etc. (TBD)

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI & TCK will be stand-alone and based off of J2SE 1.4 or higher.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

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:

1. 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." or their equivalents in any subsequent naming convention adopted by Sun through the JCP), or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required by the spec; and (c) pass the TCK.
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

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

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.

3.2 Explanation of how these items might be used as a starting point for the work.

N/A