NetBeans API List

Version 8.0.1

25 Aug 2014

This document provides a list of NetBeans APIs with a short description
of what they are used for, and a table describing different types of interfaces
(see What is
an API? to understand why we list DTDs, file formats, etc.) and with
a stability category (stable and official,
under development,
deprecated,
friend or private;
see API
stability for more info).
The aim is to provide as detailed a definition of NetBeans module
external interfaces as possible and give other developers a chance to decide
whether they want to depend on a particular API or not.

Some of these APIs are part of the
NetBeans Platform
(for example lookup,
loaders, utilities, nodes, explorer, window systems, multiview, etc.), some of them
are specific to
NetBeans IDE
(projects, javacore, diff, etc.) and some
are not included in the release at all and are just provided for download
(usually via autoupdate). Basically when building an application based on
NetBeans one is free to choose the set of modules and their APIs
to satisfy one's needs.

This is a list of APIs for NetBeans 8.0.1 version, if you want to see
a list of APIs for a particular version, you may want to go to:

Ant-Based Project Support -
Provides the basic infrastructure by which Ant-based projects can be created, read and write configuration parameters and properties from/to disk, satisfy common queries and interfaces, etc.

Datasystems API -
In summary, the LoadersAPI is responsible for scanning files in a directory on disk, weeding out irrelevant files of no interest to the IDE, and grouping the rest into logical chunks, or just determining what type of data each represents.

Editor Library 2 -
The Editor Library 2 module is a set of official APIs and SPIs, designed to replaces the original Editor Library with legacy APIs that are not properly structured and do not conform to the rules implied on the current NB APIs.

Editor Settings -
The legacy settings system in the editor module is complicated, error prone and hard to use.

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

Explorer & Property Sheet API -
The
ExplorerAPI is build around Explorer - solely a user-interface device: it has no particular knowledge of the structure of the IDE.

External Execution API -
Provides common APIs to execute external process in the IDE to handle its streams and present the output to the user.

External Libraries -
Permits libraries to be defined, customized, and stored by the user for reuse in multiple projects.

File System API -
The Filesystems API provides a common API to access files in a uniform manner.

Module System API -
The Modules API lies at the core of NetBeans and describes how plug-in modules are added and managed.

MultiView Windows -
Multi views are general mechanism for displaying several perspectives, or views of data, which will be used consistently across whole IDE window system.

Navigator API -
Navigator module is a base API module which provides:
A place for modules to show structure/outline of their documents
Ability for modules to show their view only when special document(node)
is active in the system
UI for switching between multiple views available for currently active document(node)
Coalescing of fast coming selected node changes to show content for
.

Nodes API -
Nodes API serves as the main aparatus for visualisation of objects in NetBeans.

Quick Search API -
QuickSearch API and its implementations provides way for end user to learn system earlier and easier and also to find various things in the system more quickly, conveniently and in standard way.

Search API -
This project is good for implementators of nodes to define how files under this node should be searched.

Settings API -
Settings are persistent objects with a set of properties, that should be available via lookup.

Task List API -
This module provides SPI for third parties that want to display some sort information for the user in the Task List / Problems window.

Text API -
The EditorAPI is used for accessing editor-related functionality from within the IDE for use by other modules and the core IDE itself.

TreeTableView Model -
The debuggercore/ViewModel module (View Model) allows to share one TreeTableView among different modules.

Running named targets in specified Ant scripts. Can be used
by modules which provide a different UI for initiating Ant
execution. ActionUtils provides a more convenient
wrapper around this functionality.

The Java Support APIs provides basic facilities for getting or supplying
information about Java-language source files. It is based on the query pattern
so implementations can be supplied from other modules or projects.

The ClassPath APIs provides java classpath like ordered collection of (source)
roots with ability to listen on changes and helper methods like finding the file
under the roots, returning a path from root to given file. It also provides a
registry where projects register their classpaths to make them visible to languages
infrastructure.

This project is good for implementators of nodes to define how files
under this node should be searched. For example, if you implement a
custom project type, you can define which folders should be searched
when the project is in the current search scope.
It is also good for people who want to add a custom tab into the
"Search in projects" dialog. For example, implementators of platform
applications can add form with criteria for searching in a database.

The Visual Library 2.0 is the next generation of the original Graph Library 1.0.
It is designed for a general visualization with a support for graph-oriented modeling.
Its focus is to become a part of the NetBeans platform and unify the visualization (UI and API) used in NetBeans-Platform-based applications.
See http://graph.netbeans.org/ web-site for details.
See documentation for complete set of use-cases and code-snippets.

Usage:

No. Just set a normal project dependency on org.netbeans.api.visual (spec no.: 2.0) module.

The API provides a set of reusable pieces - widgets. By composing them you are creating a visualization.
Each widget has various properties including layout, border, assigned actions, ... The library contains a set of pre-defined widgets that can be extended.
All pluggable pieces are declared as interfaces or abstract classes - WidgetAction, Anchor, AnchorShape, PointShape, Animator, Border,
GraphLayout, LookFeel, Layout, SceneLayout, Router, CollisionsCollector.
Also they all have their built-in implementation.

Multi views are general mechanism for displaying several perspectives, or views of data,
which will be used consistently across whole IDE window system. Using multi views
will enable modules to visually represent data document or object in unified manner
at one specific place in the system, yet still allowing for different perspectives
of data viewing.

You modules can use the AutoUpdateUI API directly (of course
you almost certainly need also
Autoudate Services), just be aware that this module comes with a UI.
It is not always practical to depend on modules that provide a UI from
low level infrastructure modules - if that is your case, consider separating
calls to AutoUpdateUI into separate
bridge module.

this module exposes bits of its UI and user related workflow actions
(related to installing, upgrading, etc.) by providing an API calls
for other modules to invoke bits of here-in available functionality.

The diff module provides the ability to visualize differences between source files.
It also has a graphical conflicts resolver tool and built-in patch algorithm.
List of the main features:
Simple APIs, that provide access to registered diff and merge engines and visualizers.
Built in and external diff engines defined.
Graphical diff vizualizer and conflicts resolver.
Extensible with additional diff and merge engines and vizualizers.
Patch algorithm implemented for UNIX-style, unidiff and contextual diff formats.

Code Templates allow to paste various code snippets by using parametrized text.
The parameters of the same name will share the same default value and if that value
gets changed by user's typing the new value gets replicated into all the parameter's
occurrences.
Code Templates replace the original abbreviations functionality.
Code template's example
for (Iterator ${iterator} = ${collection instanceof="java.util.Collection"}.iterator(); ${iterator}.hasNext();) {
${cursor}${iterator}.next();"
}
Each parameter can have additional hints of what values
can be assigned to it.
The hint has a form
${param hint=value}
or just
${param hint}
which translates to
${param hint="true"}
If necessary the value of the hint can be enclosed
in quotes to allow to write whitespace or { or }
into the value. The quote can be written by using \".
Reserved parameter names
${cursor} defines position where the caret will be located
after the editing of the code template default values will finish.
Reserved hint names
${param editable=false} can be used to make the parameter to be skipped
from user's editing. This may be useful e.g. with using java-specific type
hint (described below).
Java:
${ind index} defines that the default value of the parameter
should be an unused variable in the given context named i.
If i is already used then j is attempted
or then k etc. until z.
Then i0, i1 etc. are attempted.
${param type="java.util.Collection"} defines
java type that the parameter must be instance of.
Besides class names there can be array e.g. String[]
or generics java.util.List<String>
${param array} defines parameter of array type (including
arrays of primitive data types).
${param type="java.util.Iterator"} defines
that the parameter has the given java type. The template processing infrastructure
will use short name Iterator and import java.util.Iterator.

Code Completion provides users with a list of suggested completions for partially typed texts in the editor and various dialog input fields.
The Code Completion module was created to replace
the original legacy editor code completion which
lacked several key requirements:
Support for multiple independent code completion content providers.
Implied requirement for ordering and prioritization of the completion items.
Direct support for asynchronous completion result computation.
Missing separation to the API and SPI and implementation parts.

The Guarded Sections module is supposed to operate over the Swing's StyledDocument.
It allows clients to manipulate named guarded sections that prevents user to
modify the content. So if you like to create, modify or delete guarded sections the GuardedSectionManager is the best place where to start.

The Editor Library 2 module is a set of official APIs and SPIs, designed to
replaces the original Editor Library with legacy APIs
that are not properly structured and do not conform to the rules
implied on the current NB APIs.
The APIs currently offered in Editor Library 2 module include:
editor-code-generatoreditor-highlightingeditor-typing-hooks

Each editor provides an EditorKit which controls the policy of specific MIME content type.
The policy of content type should be easily registered and found via some lookup mechanism,
that will provide convenient way of using it either for kit provider or base
editor infrastructure. In addition to this, the policy can be inherited, (e.g. in case of embeded
kits like JSP) and the content types need to be merged in this case. MIME Lookup API should
provide all mentioned requierements via easy lookup query, so content type policy
user need not to solve this searching and merging on its own side.

The legacy settings system in the editor module is complicated, error prone
and hard to use. It'd been created spontaneously over the years to support
immediate needs at that time without paying enough attention to extensibility
and interoperability. Historically any module providing editor settings needed
to depend on the whole editor module.
The main purpose of this project is to define API for editor settings, that
is lightweight and easily extensible. The API relies on MimeLookup
to provide a way of registering and looking up settings.
The aim is NOT to provide an implementation of a storage for editor settings,
but to define an interface between this storage and clients
like <mime-type> editors, externaleditor, etc.

Many Java-based project types need to be able to configure the version and
location of Java to be used when building and running the project. This
API/SPI permits these platforms to be registered and queried, and any
customizations made in an appropriate GUI and persisted to disk.

The Java Platform API permits access to installed Java platforms (for example,
the J2SE JDK, or various mobile-device emulators for J2ME). Particular platform
types are registered by modules and can store customized information about the
platform to disk.

The JavaHelp integration API wraps the standard JavaHelp extension
library. It also provides a small additional API for NetBeans modules to
supply help sets to the system, add GUI menu items, and request that
particular help topics be displayed.
JavaHelpIntegrationAPI

Provides the basic infrastructure by which Ant-based projects can be created,
read and write configuration parameters and properties from/to disk, satisfy
common queries and interfaces, etc. See Javadoc and build system design
document.

Mostly an SPI for creating project types centered around the Ant build tool.
Permits Ant-based project types to be registered and supplies various support
implementations to help satisfy the contract of Project and
various optional interfaces.

Permits libraries to be defined, customized, and stored by the user for
reuse in multiple projects. For example, a Java JAR library has a classpath
(usually one JAR), and an optional source path and Javadoc path that may be
used for development-time features.

The Project Libraries API permits definitions of libraries to be
registered and persisted. Library type providers may be registered and can
construct memory objects corresponding to persistent library definitions.

The Project API defines abstract projects. These are groupings of files built and
manipulated as units. It is used for Ant-based projects but could support
other scenarios such as makefiles. Modules can plug in project types which can
recognize certain folders as being projects, and define their behaviors.
Besides the visible Javadoc, this module permits a project to add implementations
of org.netbeans.spi.queries.FileBuiltQueryImplementation,
org.netbeans.spi.queries.SharabilityQueryImplementation and
org.netbeans.spi.queries.FileEncodingQueryImplementation
into the project lookup (rather than global lookup).
The implementations will be consulted only in the case the relevant file
belongs to that project (according to org.netbeans.api.project.FileOwnerQuery).
This helps avoid the need to consult irrelevant query implementations.

The Project UI API provides some miscellaneous APIs and SPIs relating to the
appearance and UI behavior of generic projects. Most importantly, it permits
the customizer and logical view of a project to be defined.

General kinds of queries between modules.
Queries are one way of solving the
intermodule communication problem when it is necessary for some modules to
obtain basic information about the system (e.g. whether a particular file is
intended for version control) without needing direct dependencies on the
module providing the answer (e.g. the project type which controls the file).
Details are covered in the Javadoc.

The General Queries API provides generic queries, or sources of
concrete information, useful throughout the build system and perhaps
elsewhere. Each query is split into an API component intended for clients to
find the answer to a particular question without knowledge of the underlying
structure or origin of the answer; and an SPI interface (using lookup)
permitting answers to be provided from any source. These queries currently
pertain to VCS and compilation status and user visibility of files.

Settings are persistent objects with a set of properties, that should be available via lookup.
Properties are expected to be changed. Implementation of setting doesn't care about persistence issues, which
is responsibility of settings infrastructure. XML persistence support is provided in a standalone autoload module core-settings.jar.
Also service types must be mentioned here.
Service type can be desribed as typed a named settings.
SettingsAPIServicesAPIXmlSettingsPersistence

Modules may use functionality of this module either by depending on its presence
and registering callback interfaces
provided by its API. Or the modules do not need to depend on this module at all,
and just generate log records
to the UI_LOGGER_NAME_VALUE+".someloggername" logger. These records are
then going to be consumed by this module, if enabled.

Navigator module is a base API module which provides:
A place for modules to show structure/outline of their documents
Ability for modules to show their view only when special document(node)
is active in the system
UI for switching between multiple views available for currently active document(node)
Coalescing of fast coming selected node changes to show content for

The project implements a new component palette that will be reused by other
projects. The new palette should provide a common look and feel for Form editor,
Mobility, J2EE and possible other modules as well.
UI draft specification is available at http://ui.netbeans.org/docs/ui/palette/index.html

QuickSearch API and its implementations provides way for end user to learn
system earlier and easier and also to find various things in the system more
quickly, conveniently and in standard way.
Main project page is on nb wiki, http://wiki.netbeans.org/QuickSearch

This module provides SPI for third parties that want to display some sort information for
the user in the Task List / Problems window. A typical example are Java errors, warnings, TODOs etc.
Part of the integration are several implementation modules that provider task list user interface,
TODO task scanning, Java integration.

The
DialogsAPI
allows creating a user notification, a dialog's description
and also permits it to be displayed. The wizard framework allows create a sequence
of panels which leads a user through the steps to complete any task.
This API is part of package org.openide.

The IDE uses a small interface to describe the execution of Java-based
classes together with arguments. The
ExecutionAPI
controls the execution
of user-level classes. The system may have several different types
of executors simultaneously installed. By default we provide so called
External Execution for running a user code by an external process and
Internal Execution for running the user code in the same virtual machine
as the IDE.

The
ExplorerAPI
is build around Explorer - solely a user-interface device: it has no particular knowledge
of the structure of the IDE. Rather, it provides the physical user interface for
the Node hierarchy, as described in the
NodesAPI.
A given Explorer instance will be some visual component (such as a Swing panel)
displaying some representation of a subtree of the complete Node hierarchy;
the topmost node being displayed is said to be the root of the Explorer.
Be careful not to confuse the root of a particular Explorer instance, which is
selected according to what the user wishes to see, with the root(s) of
the entire Node hierarchy, which generally are fixed.

In summary, the LoadersAPI
is responsible for scanning files in a directory on disk,
weeding out irrelevant files of no interest to the IDE,
and grouping the rest into logical chunks, or just determining
what type of data each represents. It does this scanning by asking each registered
data loader whether or not the given file(s) should be handled. The first
loader to recognize a file takes ownership of it, and creates a matching data object to represent it to the rest of the IDE.

Nodes API serves as the main aparatus for visualisation of objects
in NetBeans. Nodes augment objects with standard aspects used for
visualisation (e.g. name, displayName, icons, set of proerties,
subnodes hierarchy, etc.) Once a Node is defined for given object
it can be visualised using diferent views e.g. trees, lists, tables etc.
Descripion of nodes can be found
here.

In order to speedup, or remove the load of initialization of kit in AWT during startup,
there is a special API that allows to ask the kit to pre-initialize. If the kit
implements Callable interface from JDK, it is called in non-AWT thread.
This works since version 6.18 and can be disabled by property oldInitialization.