openide

The Loaders API describes how to use cookies in conjunction with data objects, including creating new cookie interfaces, creating new cookie support implementations, and reusing existing supports. The Nodes API also permits use of cookies to add behavior to nodes.

NetBeans itself implements two filesystems: a local filesystem, which encapsulates access to the operating system's normal files; and a JAR filesystem, which allows users to mount Java Archive Files as if they were read-only directories.

Using the Filesystems API, third parties may add support for access to file-like objects stored in some different manner - for example, in a database or proprietary object storage system. More commonly, module authors should use this API whenever they need access to files; then their module should work automatically with any filesystem supported by NetBeans.

Other capabilities provided by the Filesystems API include locking files during write operations; listening for changes in a file's status, so that another part of NetBeans may reflect that change; and providing support for including the filesystem in the runtime class path of an external compiler or executor.

These nodes are used extensively for building the UI, especially the Explorer. Using the Nodes API, it is possible to create a variety of custom nodes and entire subhierarchies, and manipulate and search existing nodes. In conjunction with the Datasystems API, nodes may also represent persistent data and can present the user interface to this data. Cookies may also be attached to nodes.

Each option is a singleton class defined by its Bean properties. These properties are displayed to the user in special nodes in the Explorer, so that they may be examined and modified, possibly triggering live changes.

Special support is provided for "safe" serialization (with better failure modes than the default) for writing options to disk; hierarchical option clusters; and veto-aware options.

Using the Editor API, it is possible to get access to the Swing-based editor which is being used to edit an open file of whatever content type. This would permit you to test what the user was doing with this file; mechanically retrieve and modify text from the open buffer; prevent certain areas of a textual file from being modified by the user; set annotations in the gutter; and so on.

This API also permits a module implementor to add a custom editor for some or all (probably textual) content types. Essentially, any editor implementation may be used which is capable of being embedded as a Swing EditorKit; handling guarded blocks; and handling breakpoints and the like (for Java source).

• The clipboard supports Java Events for content changes.
• Convertors may be used to externally add support for additional data flavors to a transferable.
• It is possible to transfer multiple objects (of different types) at once using a special transfer type.

The Window System API provides the ability for modules to create window-like components which can, among other things:

1. Be docked as tabs into a container window.
2. Provide popup menus in their window icon or tab.
3. Handle activation and node selections.
4. Provide the ability to be cloned, and the clones monitored.