NetBeans API List
Version 8.2
20 Dec 2016
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.2 version, if you want to see
a list of APIs for a particular version, you may want to go to:
-
Dev - Javadoc as released for development version
-
8.1 - Javadoc as released for NetBeans IDE 8.1
-
8.0.1 - Javadoc as released for NetBeans IDE 8.0.1
-
8.0 - Javadoc as released for NetBeans IDE 8.0
-
7.4 - Javadoc as released for NetBeans IDE 7.4
-
7.3.1 - Javadoc as released for NetBeans IDE 7.3.1
-
7.3 - Javadoc as released for NetBeans IDE 7.3
-
7.2.1 - Javadoc as released for NetBeans IDE 7.2.1
-
7.2 - Javadoc as released for NetBeans IDE 7.2
-
7.1.2 - Javadoc as released for NetBeans IDE 7.1.2
-
7.1.1 - Javadoc as released for NetBeans IDE 7.1.1
-
7.1 - Javadoc as released for NetBeans IDE 7.1
-
7.0.1 - Javadoc as released for NetBeans IDE 7.0.1
-
7.0 - Javadoc as released for NetBeans IDE 7.0
-
6.9.1 - Javadoc as released for NetBeans IDE 6.9.1
-
6.9 - Javadoc as released for NetBeans IDE 6.9
-
6.8 - Javadoc as released for NetBeans IDE 6.8
-
6.7 - Javadoc as released for NetBeans IDE 6.7
-
6.5 - Javadoc as released for NetBeans IDE 6.5
-
6.1 - Javadoc as released for NetBeans IDE 6.1
-
6.0 - Javadoc as released for NetBeans IDE 6.0
-
5.5.1 - Javadoc as released for NetBeans IDE 5.5.1
-
5.5 - Javadoc as released for NetBeans IDE 5.5
-
5.0 - Javadoc as released for NetBeans IDE 5.0
To get the API of your module listed here, see the documentation for the
Javadoc building
infrastructure.
Additional Sources of Information
FAQ and Mailing List
Can't find what you're looking for? Try the FAQ
and then dev@platform.netbeans.org.
Content
javadoc | download
| architecture
| usecases
Provides common annotations serving as a documentation element and for
static code analysis.
javadoc | download
| architecture
| usecases
This module provides a contract between API clients that can express
some intention to invoke an operation and SPI providers that can
handle that intention.
This is useful in client-server environments, where the intention
can be constructed on server-side, but handled on client-side. The
objects that describe the intention should be easy to construct,
transfer and interpret.
Usage:
Standard module dependency is sufficient.
javadoc | download
| architecture
| usecases
The Input/Output API and SPI is a small module
which contains InputOutput and related interfaces used in
driving the Output Window.
The normal implementation is org.netbeans.core.output2.
Usage:
Normal module dependency is enough.
Availability of some implementation of the SPI is guaranteed by
"OpenIDE-Module-Needs: org.netbeans.spi.io.InputOutputProvider" in
the manifest of this module.
javadoc | download
| architecture
| usecases
The progress API is good for tracking progress of long lasting tasks in the IDE.
javadoc | download
| architecture
| usecases
XXX no answer for arch-what
Usage:
XXX no answer for deploy-dependencies
javadoc | download
| architecture
| usecases
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.
Usage:
No extra declaration is required.
Interface Name | Stability Classification | Specified in What Document? |
SearchInfoSPI | Stable | org-netbeans-api-search/org/netbeans/spi/search/package-summary.html
Defines abstract classes
SearchInfoDefinition ,
SearchFilterDefinition ,
SubTreeSearchOptions
and a factory class
SearchInfoDefinitionFactory
|
SearchProviderSPI | Stable | org-netbeans-api-search/org/netbeans/spi/search/provider/package-summary.html
Defines abstract classes that need to be implemented when
creating custom providers:
SearchProvider ,
SearchProvider.Presenter ,
SearchResultsDisplayer ,
SearchComposition
and relative classes.
|
SearchProviderAPI | Stable | org-netbeans-api-search/org/netbeans/api/search/provider/package-summary.html
Classes usually used by search providers.
Contains class SearchInfo ,
that defines which files should be searched (it can be retrieved from methods in
SearchInfoUtils ,
or UI component controller ScopeController ),
SearchListener
that you should inform about events that happen during searching, and helper classes
SearchInfoUtils
(getting SearchInfo objects for nodes) and
FileNameMatcher
(filtering files by file name).
|
SearchProviderUIAPI | Stable | org-netbeans-api-search/org/netbeans/api/search/ui/package-summary.html
Several UI components that can be used in presenters of search
providers, and factory method for creating them.
|
SearchAPI | Stable | org-netbeans-api-search/org/netbeans/api/search/package-summary.html
Contains classes for controlling search, passing search
criteria, and some helper classes.
|
|
javadoc | download
| architecture
| usecases
This utility standardizes the process to use files as blueprints to create new files.
Usage:
No specific deploy dependencies.
javadoc | download
| architecture
| usecases
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.
Interface Name | Stability Classification | Specified in What Document? |
VisualLibraryAPI | Official |
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.
|
|
javadoc | download
| architecture
| usecases
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.
javadoc | download
| architecture
| usecases
XXX no answer for arch-what
Usage:
XXX no answer for deploy-dependencies
Interface Name | Stability Classification | Specified in What Document? |
UIGestureCollectorLibrary | Devel |
Library with utilities for UI Gesture Collector module as well as
for the server processing the results.
|
|
javadoc | download
| architecture
| usecases
org.netbeans.api.autoupdate
org.netbeans.spi.autoupdate
javadoc | download
| architecture
| usecases
AutoUpdateUI
Usage:
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.
Interface Name | Stability Classification | Specified in What Document? |
AutoUpdateUI | Stable |
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.
|
Set of property APIs | Individual | table with definitions |
|
javadoc | download
| architecture
| usecases
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.
javadoc | download
| architecture
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
javadoc | download
| architecture
| usecases
XXX no answer for arch-what
Usage:
XXX no answer for deploy-dependencies
Interface Name | Stability Classification | Specified in What Document? |
Keyring-API | Official |
Other modules can access the keyring, or add implementations.
|
|
javadoc | download
| architecture
| usecases
This module contains implementation of Options Panel and simple SPI.
javadoc | download
| architecture
| usecases
Provides print functionality in NetBeans.
Interface Name | Stability Classification | Specified in What Document? |
PrintAPI | Stable | |
|
javadoc | download
| architecture
| usecases
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.
Interface Name | Stability Classification | Specified in What Document? |
GeneralQueriesAPI | Official |
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.
|
Set of preferences APIs | Individual | table with definitions |
|
javadoc | download
| architecture
| usecases
GetOpts like infrastructure to parse command line arguments with the cooperative
participation of various modules.
javadoc | download
| architecture
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.
SettingsAPI
ServicesAPI
XmlSettingsPersistence
javadoc | download
| architecture
| usecases
XXX no answer for arch-what
Usage:
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.
javadoc | download
| architecture
| usecases
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
Usage:
Nothing, regular depencency is enough.