NetBeans Open APIs

This document set describes the APIs used in the NetBeans IDE.

See:
Description

Modules API

org.openide.modules

The IDE is capable of being extended by pluggable modules providing additional functionality.

TopManager, ServiceType, WizardDescriptor, ...

org.openide

Jumping-off points for all the rest of the IDE's functionality.

Services & Lookup API

org.openide.util.lookup

Useful implementations of the lookup system used to register functionality and objects in the APIs.

FileSystems API

org.openide.filesystems

The IDE internally uses the concept of a virtual filesystem.

DataSystems API

org.openide.cookies	Cookies are a design pattern used to add behaviors to existing data object and nodes, or to separate implementation from the main object.
org.openide.loaders	DataSystems are the logical layer between a filesystem and the regular functions of the IDE.
org.openide.util.datatransfer	The IDE uses special extensions to data transfer.

Nodes API

org.openide.nodes

The IDE uses nodes to represent JavaBeans or other property containers, formed into a hierarchical tree.

Explorer API

org.openide.explorer	Many different UI components of the IDE are actually Explorer views of nodes.
org.openide.explorer.propertysheet	The exact properties of a node may be displayed and edited with the Property Sheet.
org.openide.explorer.view	The Explorer is really an abstraction that needs a view to actually display the nodes.

Actions API

org.openide.actions	There are a number of standard system actions available for use in the IDE.
org.openide.util.actions	There are several types of standard actions that should be used for many user interactions with the IDE.

Compiler API

org.openide.compiler

Different compiler implementations may be plugged into the IDE to build files from source.

Execution API

org.openide.execution

The IDE uses a small interface to describe the execution of Java-based classes together with arguments.

Debugger API

org.openide.debugger

The IDE can support plugged-in implementations of an abstract debugger interface.

Editor API

org.openide.text

The IDE is able to integrate multiple editors for different content types and mechanically access their content.

Window System API

org.openide.windows

Most parts of the IDE do not manipulate windows directly, but use special top components.

Options API

org.openide.options

System options provide an easy-to-use mechanism for persistent storage of user-settable options.

Java Hierarchy API

org.openide.src	The parsing results of Java sources and the result of Java Reflection may be uniformly accessed as source elements.
org.openide.src.nodes	Source elements can be represented by default element nodes.

Utility Classes

org.openide.awt	A set of utility classes pertaining to the visual appearance of the IDE.
org.openide.util	A set of utility classes covering a few general infrastructure points in the Open APIs.
org.openide.util.enum	A set of utility classes providing convenient forms of Java Collections enumerations.
org.openide.util.io	A set of utility classes providing extensions to the Java I/O system.
org.openide.xml	A set of utility classes assisting in the manipulation of XML documents in the IDE.

This document set describes the APIs used in the NetBeans IDE. It also applies to compatible distributions such as Sun's Forte for Java and any other applications which keep the APIs intact.

The API set allows application creators and power users to extensively customize the IDE and integrate substantial external applications into the IDE's operation. It also is self-contained and permits the implementation to be inserted into it at runtime.

Available API sets as of December 12 2001:

• The Modules API provides a way to insert pluggable JAR-based modules into the IDE, in a user-controllable fashion, which may extend its operation using any of the other APIs. Based heavily on the Java Extension Mechanism, features include module versioning and cross-compatibility checks; Web-based download and installation of modules into a running IDE; and the capability to specify a variety of standard additions (such as new menu items) descriptively in the module's manifest file.
• The TopManager is the starting point for the functionality of the other APIs--it provides access to important system objects, for example the Control Panel, the standard classloader, logging streams, etc. The Places API provides shortcuts to well-known places in the Explorer hierarchy--for example, the user Repository.
• The Services & Lookup API describes a general way of permitting executors, debugger types, and compiler types to be uniformly created, installed, configured, selected, and saved. It also covers the lookup mechanism: how to register objects to lookup, find them, and present them to a user, including settings.
• The FileSystems API describes how to access and monitor files used in the IDE, and even to create custom virtual filesystems.
• The DataSystems API permits access to the representation of typed data in the IDE. Implementors would primarily use this API to cause the IDE to recognize new data types (e.g. UML files), add user-visible actions to nodes representing a custom or standard type, implement templates, and so on. Data objects may also represent logical groupings of physical files where appropriate.
• The Explorer API gives access to the Explorer in its various views--not only the usual Explorer window, but other views such as the Component Palette (driven from the same underlying objects). Module authors may drop an Explorer view of some part of the IDE into a custom UI component. The API also allows an implementor to create new Explorer views for custom data representation, and make them interoperable with the existing ones.
• The Nodes API permits access to the provided features of nodes such as those used in the Explorer window; and allows third parties to create their own hierarchical nodes to display wherever they wish, including operations such as browsing of nodes; cut/copy/paste and reordering; display characteristics, both icon and available properties; and actions which may be taken on the node (e.g. in a context menu), both custom actions and standard actions such as "Compile" or "Open".
• The Actions API provides an interface to such IDE elements as toolbars, menus, and keyboard shortcuts--allowing third parties to create actions which are sensitive to context and are invokable in more than one way.
• The Window System API controls the overall functioning of the desktop, including standard and custom workspaces and the dynamic interaction of windows during various stages of the user experience, as well as XML-based persistence and configuration.
• The Options API provides the ability for a module to have richly structured and persistent user-level options accessible in the Control Panel, including custom option editors and context help.
• The Compiler API allows an implementor to run the standard IDE Java compiler and check its progress; or, an unusual sort of compiler interface beyond the scope of the External Compiler control panel may be created.
• The Execution API controls the running of user code, whether applets, applications, or non-standalone components such as JPanels. The API permits execution of user classes (including handling classloader issues), or allows a custom execution engine (say for profiling) to be integrated.
• The Debugger API specifies how a Java debugger should interact with the IDE. It may be used to create a module implementing a custom debugger, or to interact with the default system debugger.
• The Editor API provides access to the basic functionality of the Editor and its support for different content types; and the ability to insert custom editors conforming to the Swing Editor Kit conventions.
• The Java Hierarchy API encapsulates the result of either parsing Java source documents, or introspecting on Java classes--a structured representation of the Java class objects and their members. Anything which can be run in a JVM (e.g. a NetRexx program) can thus be made available to the Explorer and other components for browsing and possible editing of class, interface, and member attributes.
• Utility Classes providing support functionality for the primary APIs.
• HtmlBrowser for modules to provide an alternate web browser, and HttpServer for an alternate web server (which must be internal so as to handle serving of pages from the Repository).

Sections marked with a blue bar are non-normative and should not be considered part of the formal specification of the APIs.

Supplementary specifications:

1. Threading Models used in the Open APIs.
2. API Change List (online).
3. General notes explaining conventions and assumptions made in the IDE.

Some informational pages which module authors will also want to look at:

1. Upgrade Guide describing changes made in the APIs between NetBeans 3.2 and 3.3 that typical module developers should be aware of.
2. APIs FAQ.
3. X-Ray Spex Tutorial to see how a real user IDE session (here, excerpts from the standard NetBeans tutorial) actually works in terms of the APIs and modules acting in concert.
4. Tips and Tricks for writing modules, including how to compile the sources against the Open API library, building the module JAR, testing and debugging modules.
5. Philosophy of FileSystems API (online).
6. Typical uses showing how the APIs would be used for common applications.

For more information about the APIs, including source code access and mailing lists, see openide.netbeans.org.