Skip navigation links


What do the Dates Mean?

The supplied dates indicate when the API change was made, on the CVS trunk. From this you can generally tell whether the change should be present in a given build or not; for trunk builds, simply whether it was made before or after the change; for builds on a stabilization branch, whether the branch was made before or after the given date. In some cases corresponding API changes have been made both in the trunk and in an in-progress stabilization branch, if they were needed for a bug fix; this ought to be marked in this list.

Index of APIs

Incompatible changes by date

Fuller descriptions of all changes can be found below (follow links).

Not all deprecations are listed here, assuming that the deprecated APIs continue to essentially work. For a full deprecation list, please consult the Javadoc.

All changes by date

Changes by version

These API specification versions may be used to indicate that a module requires a certain API feature in order to function. For example, if you see here a feature you need which is labelled 1.20, your manifest should contain in its main attributes the line:

OpenIDE-Module-Module-Dependencies: org.openide.modules > 1.20

Changes by affected class













Details of all changes by API and date

Modules API

Better support for constructor invocation

Sep 26 '14; API spec. version: 7.45; affected top-level classes: ConstructorDelegate; made by: sdedic; issues: #243561

Allows the generated constructor to call any constructor, signature is derived from specified static method parameters. See javadoc for @ConstructorDelegate

Support for binary compatibility patches

Apr 11 '14; API spec. version: 7.44; affected top-level classes: PatchFor ConstructorDelegate; made by: sdedic; issues: #243561

Special annotation @PatchFor allows to require that a class should serve as a superclass of some other class. See @PatchFor javadoc for further constraints.

To support removing obsolete constructors, @ConstructorDelegate has been created to mark moved initialization code. See @ConstructorDelegate javadoc for more details.

JavaFX Library Wrapper

Dec 23 '13; API spec. version: 7.41; made by: jtulach; issues: #237973

Most of JDK installations come with additional JavaFX JAR. Alas the location of the JAR is different on JDK7 and JDK8, moreover on some operating systems (think of Solaris) the JAR is not present at all. To hide the differences and allow smooth consumption of JavaFX APIs NetBeans provide following conventions.

If you want to code against JavaFX APIs, add dependency on org.netbeans.libs.javafx library. Then you'll be able to compile and run while using the API.

If you want to depend on presence of JavaFX JAR inside of JDK installation structure, use:

OpenIDE-Module-Needs: org.openide.modules.jre.JavaFX

This token is made available by the module system, if the JavaFX module is present in the JDK. Btw. the org.netbeans.libs.javafx library has such dependency and as a result, all modules that depend on it will be disabled on Solaris or on OpenJDK (if installed without JavaFX).


Find ModuleInfo by code name base easily

Feb 12 '13; API spec. version: 7.37; affected top-level classes: Modules; made by: jtulach; issues: #225582

New findCodeNameBase(String) method returning ModuleInfo or null.


Less restrictive check of code names of modules and OSGi bundles

May 24 '12; API spec. version: 7.32; affected top-level classes: Dependency; made by: jtulach; issues: #212364

Dependency.create now allows code name base where dot is followed by number (like org.apache.servicemix.specs.jsr303_api_1.0.0). This increases the inter-operability with OSGi bundles using such naming style.


By default each module provides its code name base as a token

Apr 20 '12; API spec. version: 7.30; affected top-level classes: ModuleInfo; made by: jtulach; issues: #201695

Each module provides by default a token composed from its code name base and fixed prefix: "cnb." + getCodeNameBase() from its getProvides() method.


Unless accidental clash in the name of the token with cnb. prefix, the change is compatible.

OnStart and OnStop

Mar 31 '12; API spec. version: 7.29; affected top-level classes: OnStart OnStop; made by: jglick; issues: #200636

New, more efficient way to execute code on start and on shutdown of your module.


Modules using ModuleInstall are encouraged to switch to these new annotations.

Added Places

Sep 1 '11; API spec. version: 7.26; affected top-level classes: Places; made by: jglick; issues: #57798

Introduced a structured API for accessing well-known file locations.


Modules using system properties such as netbeans.user should use this new API instead.

Module names can contain Java keywords

Jul 22 '10; API spec. version: 7.20; affected top-level classes: Dependency; made by: jtulach; issues: #188686

Naming rules for module code name bases are now relaxed. The name of a module can contain a Java keyword like org.mysite.import.something, etc.

Quicker way to find owner of a class

Jul 19 '10; API spec. version: 7.19; affected top-level classes: Modules; made by: jglick; issues: #157828

Class Modules introduced, initially with the ability to find the owner of a given class directly without iterating through all known modules.

New native library lookup mechanism

May 17 '10; API spec. version: 7.17; made by: pnejedly; issues: #186000

You can now distribute native libraries into architecture and OS specific directories under modules/lib; see the documentation. The functionality is actually provided by the org.netbeans.bootstrap module as of version 2.33.

Simplified ModuleInstall lifecycle

Jan 6 '10; API spec. version: 7.15; affected top-level classes: ModuleInstall; made by: jglick; issues: #113341

The ModuleInstall methods installed and updated, while previously deprecated, will no longer be called at all. ModuleInstall instances will also no longer be serialized to disk. Versioning-related attributes are no longer stored in config/Modules/*.xml files.


Modules relying on ModuleInstall externalization should be using NbPreferences (or similar) instead. Use restored rather than installed or updated (which have long been unreliable anyway).

Added InstalledFileLocator.locateAll

Jan 6 '10; API spec. version: 7.15; affected top-level classes: InstalledFileLocator; made by: jglick; issues: #36701

You can now locate multiple variants of an installed file path from different clusters.

Dependency class made serializable

Apr 6 '09; API spec. version: 7.10; affected top-level classes: Dependency; made by: jtulach; issues: #160390

Dependency now implements Serializable

Added annotation @PatchedPublic

Jan 6 '09; API spec. version: 7.9; affected top-level classes: PatchedPublic; made by: jglick; issues: #155796

Added @PatchedPublic to request that the module system treat binary references to a method as public even if in source is is not public.

Ability to hide JRE packages from the module classpath

Feb 23 '08; API spec. version: 7.6; made by: jglick; issues: #96711

Packages supplied in a module which overlap those in the JRE or its extensions will normally be ignored (as usual, the JRE takes precedence). Modules which wish to specifically suppress loading of some packages from the classpath can now request the class loader to do so by specifying:

OpenIDE-Module-Hide-Classpath-Packages: javax.lang.model.*, com.sun.source.**

(The syntax is analogous to that of OpenIDE-Module-Public-Packages.)

Such a declaration affects not just this module, but any other modules declaring a direct dependency on it (OpenIDE-Module-Module-Dependencies). The module is now free to bundle its own versions of these classes and be sure they will be used by it and its clients. Be aware that as with all changes to the normal class loading scheme, careless usage could result in LinkageErrors.


To guarantee that the new tag will be honored you should also:

OpenIDE-Module-Requires: org.openide.modules.ModuleFormat2

Several JRE packages used to be hidden automatically but are not any more; while these were never documented, modules which relied on being able to override these packages could be broken by having the JRE classes exposed instead. Specifically, the following packages (or package prefixes) were in NetBeans 6.0 not loaded from the classpath, but now will be unless otherwise requested:


No longer possible to obtain a module JAR entry as a FileObject

Feb 15 '08; API spec. version: 7.5; made by: jglick; issues: #127268

Modules used to be able to obtain their own entries as file objects, e.g.:

FileObject f = URLMapper.findFileObject(ThisClass.class.getResource("something.xml"));

This is no longer supported. Client code should either use module classpath entries directly as URLs; or register files of interest in the XML layer and refer to them using the system filesystem.

Enhanced support for OS specific modules (part II)

Jul 18 '07; API spec. version: 7.3; made by: jglick; issues: #109288
Modules can now express dependencies on org.openide.modules.os.Linux and org.openide.modules.os.Solaris. For more details read here.

An option to revert user's modifications to XML layer files

Aug 1 '06; API spec. version: 7.2; made by: saubrecht
FileObjects created on XML layer now support a new attribute "removeWritables" returning an instance of Callable which removes the local writable version of the given FileObject thus reverting the folder or file to its initial state as defined in XML layers. Please note that is *not* possible to reset FileObject's attributes.

Requires/Provides and Needs

Jul 19 '06; API spec. version: 7.1; affected top-level classes: Dependency; made by: jtulach
It is possible to require some implementation using OpenIDE-Module-Needs: token which is slightly less restrictive than usual OpenIDE-Module-Requires: token as explain in the documentation.

Generified Interfaces

Mar 22 '06; API spec. version: 7.0; affected top-level classes: Dependency; made by: jtulach
Rewritten to use Java5 features, especially generics. Affects internal code and one public signature.

Enhanced support for OS specific modules

Jul 7 '05; API spec. version: 6.3; made by: jtulach; issues: #50943
Modules can now express dependency on more operating system types than those that were available previously. Now there is org.openide.modules.os.PlainUnix token for all unixes but MacOSX and org.openide.modules.os.OS2 for OS/2. For more details read here.

Branding files used during startup have new location

Jun 7 '05; API spec. version: 6.2; made by: jtulach
Due to split of openide.jar some important branding files used during startup change their location. Especially the to splash screen picture, location and color of progress bar and the application icon are now in org.netbeans.core.startup package. Here is an example of the branding as used by NetBeans IDE.

openide.jar is gone, update your module dependencies!

Jun 4 '05; API spec. version: 6.2; made by: jtulach; issues: #58258

The monolithic openide.jar has been split into many small JAR files and most of them were made autoload modules. That means they are loaded only on demand, which is going to simplify end of life of parts that are no longer needed.

The layout of files on disk changed and their content as well, but these changes shall have no effect on classes from org.openide packages during runtime. Modules using them will run unmodified. Althrough there will be printed warnings about upgraded module dependencies - one is adviced to use ant fix-dependencies in his projectized module to modify the nbproject/project.xml. The manifest's OpenIDE-Module-IDE-Dependencies attribute is deprecated and shall no longer be used. Enumerate the individual split submodules instead, as is done by the fix-dependencies task. Moreover one can depend on OpenIDE-Module-Requires: org.openide.modules.ModuleFormat1 to express that it requires current format of module manifests - this tag is automatically inserted when running in projectized system.

The current layout of platform cluster directory is:

Friend Modules

Apr 11 '05; API spec. version: 6.1; made by: jtulach; issues: #54123
A module can now restrict the list of modules that can access its public packages, by enumerating their code names in manifest.

Allow a module to be run only on some class of operating systems

Aug 11 '04; API spec. version: 4.44; made by: jtulach; issues: #46833
Modules can now declare that they run only on a specific version of operating system by requesting a presence of org.openide.modules.os.MacOSX, org.openide.modules.os.Unix or org.openide.modules.os.Windows token in their manifest:
                OpenIDE-Module-Requires: org.openide.modules.os.Unix
Such a module will then be enabled only on specified class of operating systems. See also the modules api description.

Removed compatibility handling of deprecated manifest sections

May 7 '04; API spec. version: 4.48; made by: jglick

Previously, a number of module manifest sections (e.g. OpenIDE-Module-Class: FileSystem) had been deprecated in favor of XML-layer-based installation, but a compatibility layer was left in place to permit old modules to still function as before. This layer has been removed.

Manifest-based installation of JavaHelp help sets was also removed.


Modules which did not remove these manifest sections before must do so for NetBeans 4.0.

Added method ModuleInfo.getClassLoader()

Dec 25 '03; API spec. version: 4.21; affected top-level classes: ModuleInfo; made by: jglick; issues: #38330
Added a new method ModuleInfo.getClassLoader() making it possible to find a Java class loader associated with an enabled module.
Compatibility: Note that although the new method is effectively abstract, this is a compatible change insofar as no one outside of the core module system should be subclassing ModuleInfo.

Added ModuleInfo.getBuildVersion()

Dec 18 '03; API spec. version: 4.18; affected top-level classes: ModuleInfo; made by: jtulach; issues: #36064
The implementation version and the build number of modules can now be different. One can keep OpenIDE-Module-Implementation-Version unchanged to allow implementation dependencies and still identify the actual build version by specifying OpenIDE-Module-Build-Version. If omited the build version is equal to implementation version.

Modules can declare their own dependency transformations

Jan 27 '03; API spec. version: 3.33; made by: jglick; issues: #30161

Modules may now declare their own transformations of module dependencies using a declarative XML syntax in the folder ModuleAutoDeps/ in the system filesystem. This is useful for being able to manage major refactorings of functionality in a manner that will retain binary compatibility.

Added InstalledFileLocator

Nov 13 '02; API spec. version: 3.21; affected top-level classes: InstalledFileLocator; made by: jglick; issues: #28683
This new service permits modules to find disk files associated with their installation. For example, files packed into an NBM alongside the module could be found in this way. Using the locator is both safer and more convenient than checking undocumented system properties or resorting to other tricks. Note that the NBM format is still not specified by the Open APIs; however, if there is a packaging format in use, then there should be a matching locator implementation that locates files bundled by it.
Compatibility: Existing module code which searches system properties such as netbeans.home and netbeans.user should be replaced with calls to the new supported API.

Possible to deprecate an entire module

Oct 16 '02; API spec. version: 3.15; made by: jglick
The new manifest attribute OpenIDE-Module-Deprecated and localized attribute OpenIDE-Module-Deprecation-Message may be used to warn clients of an obsolete API module.

Module dependencies no longer considered transitive for purposes of classloading

Oct 7 '02; API spec. version: 3.12; made by: jglick; issues: #27853
Prior to this change, if module B depends on module A, where A provides some public packages (implicitly or explicitly), and module C depends on module B, then module C could use public packages from A. Now it cannot, unless it also declares an explicit dependency on A.
Compatibility: Modules which fail to declare an API dependency on IDE/1 > 3.12 or above will behave according to the old semantics: they may load classes and resources from undeclared indirect parent modules. But if they declare an API dependency on 3.12 or higher, the new semantics apply.

Modules can declare their public packages

May 16 '02; API spec. version: 2.19; made by: jglick; issues: #19621

Modules which provide Java-level APIs to other modules can now specify which packages should be considered part of the public API. Other packages are blocked from client modules.

Utilizing this feature for already released modules is very dangerous. See issue #31637 for details.

Thread.contextClassLoader defaults to TopManager.systemClassLoader

May 8 '02; made by: jglick; issues: #20663
The context class loader for all threads now defaults to the system class loader, capable of loading from modules and their extensions as well as the startup classpath. This is especially useful for modules bundling NetBeans-independent libraries such as JAXP which use the context class loader as a default whenever no particular class loader is specified to some registration mechanism.

Provides-requires semantics for module dependencies

Jan 29 '02; API spec. version: 2.3; affected top-level classes: Dependency ModuleInfo; made by: jglick; issues: #18781
The manifest attributes OpenIDE-Module-Provides and OpenIDE-Module-Requires were introduced. These permit modules to depend on capabilities offered by other modules, without explicitly naming who the provider will be.

Ranged major release version dependencies

Jan 29 '02; API spec. version: 2.3; affected top-level classes: Dependency; made by: jglick; issues: #19714
Module dependencies may now specify a range of major release versions, to indicate that the dependency is valid for all mentioned major releases. Though the API-providing module may have had some incompatible changes, none of them were found to be relevant to the depending module.

JavaHelp split into a separate module

Jan 22 '02; API spec. version: 2.2; made by: jglick; issues: #19620 #27776

JavaHelp support is now in a separate module, org.netbeans.modules.javahelp/1. This module includes the** packages, and it provides the token org.netbeans.api.javahelp.Help which signifies the ability to display help, for example using TopManager.showHelp, or by querying Lookup for an instance of Help.

New modules (declaring a dependency on APIs after 2.2) which wish to provide a helpset should continue to do so via XML layer, and need only require the token org.netbeans.api.javahelp.Help. New modules wishing to display help can either require this token and use TopManager.showHelp, or depend on the org.netbeans.modules.javahelp/1 API module, require the token, query Lookup for an instance of Help, and use its methods directly. New modules wishing to use the** packages directly should declare a dependency on the org.netbeans.modules.javahelp/1 module rather than using a package dependency.


Existing modules (with an API dependency earlier than 2.2, or none at all) for compatibility are given an automatic dependency on the org.netbeans.api.javahelp.Help token. Additionally, if they declared a package dependency on**, they are given an automatic dependency on the org.netbeans.modules.javahelp/1 module.

(Note: the automatic conversion of the package dependency is implemented by issue #27776, which was not fixed for the NetBeans 3.4 release, but will be for NetBeans 3.4.1. NetBeans 3.4 did, however, add automatic dependencies on the token, by far the more common case.)

Both layer- and manifest-based installation of help sets continue to be supported; manifest-based installation is still deprecated.

Format of modules XML folder defined

Aug 17 '01; API spec. version: 1.31; made by: jglick; issues: #13921
Some aspects of the contents of the system Modules/ folder and its XML files are now defined. Additionally, certain kinds of changes (module enablement or disablement) are now permitted to these XML files.

Can determine which module owns a given class

Jul 31 '01; API spec. version: 1.28; affected top-level classes: ModuleInfo; made by: jpokorsky
Added owns(Class) to determine if the provided class was loaded as a part of the module.

Can supply localized messages for failed dependencies

Jul 20 '01; API spec. version: 1.26; affected top-level classes: ModuleInfo; made by: jglick
Permitting main attributes OpenIDE-Module-Module-Dependency-Message and OpenIDE-Module-Package-Dependency-Message.

New module installer API

Jul 16 '01; API spec. version: 1.24; affected top-level classes: ModuleInfo Dependency SpecificationVersion ModuleInstall; made by: jglick
New module installer and corresponding API enhancements. ModuleDescription, ManifestSection, and IllegalModuleException deprecated. ModuleInfo, Dependency, SpecificationVersion, and ModuleInstall.validate added. Module information available from lookup. Localized properties may be stored in bundles.

JavaHelp may be registered via layer

Apr 29 '01; API spec. version: 1.6; made by: jglick
Added ability to specify JavaHelp help sets and links from layer, or generally XML file.

Can get the class implementing a manifest section

Mar 8 '01
Added method getSectionClass().

Added long description for modules

Feb 9 '01; made by: jglick
Added getLongDescription and TAG_LONG_DESCRIPTION.

Can get JavaHelp help set reference as resource rather than URL

Jan 22 '01; made by: jglick
Added getDescriptionResource. Retrieving as URL deprecated.

Display category for modules

Jan 18 '01; made by: jglick
Added getDisplayCategory and TAG_CATEGORY.

Short description for modules

Dec 21 '00; made by: jglick
Added getShortDescription and TAG_SHORT_DESCRIPTION.

Get layer as a resource, not URL

Nov 23 '00; made by: jglick
getLayerResource() added. Thus all locale variants of a layer may be merged together. Retrieval as URL is deprecated.

Permit abbreviated sample class names in package dependencies

Nov 22 '00; made by: jglick
Slight extension to package dependency syntax to allow abbreviated sample name.

Package-accessible classloader

Nov 12 '00; made by: jglick
Inner interface PackageAccessibleClassLoader added to make it easier to check package dependencies. Package dependencies which include sample classes are now permitted.

Support layer specification in a module manifest

Nov 2 '00; made by: jglick
Now also understands OpenIDE-Module-Layer tag that can specify a resource path to XMLFileSystem that is provided by the module. Also added method getLayer() that returns the URL of XML filesystem if provided.

Manipulation of classloader used by a module

Aug 27 '00; made by: jglick
Added methods getClassLoader, setClassLoader and getBadClasses.

ModuleDescription constructor may specify a classloader

Mar 28 '00; made by: jglick
Constructors may now specify a classloader to use rather than setting it later.

Uncategorized changes

API separation, phase II

Nov 1 '02; API spec. version: 3.17; made by: jglick; issues: #19443

Three sections of the Open APIs were split into new autoload modules.

New modules wishing to use these APIs must declare regular module dependencies on them. Future changes in these APIs will be documented separately.

Furthermore, modules wishing to use certain services must OpenIDE-Module-Require them if appropriate:

Other minor changes:


Module authors using the now-separated APIs will need to adjust their compilation classpaths to include the new JAR files. Modules wishing to use recent APIs and declaring a current openide specification version dependency will need to explicitly declare dependencies on these new APIs if there are any.

For compatibility, modules with no declared Open APIs dependency, or declared on a version prior to 3.17, will have their dependencies automatically refined as if to include the declarations:

OpenIDE-Module-Module-Dependencies: org.openide.compiler > 1.0,
  org.openide.execution > 1.0, > 1.0
OpenIDE-Module-Requires: org.openide.compiler.CompilationEngine,

And any package dependencies from old modules on org.netbeans.lib.terminalemulator will be converted to module dependencies.


API separation, phase I

Oct 15 '02; API spec. version: 3.14; made by: jglick; issues: #19443 #20898

Many classes were moved to a separate module, openide-deprecated.jar, not available to modules by default. Uses of these classes in modules should be cleaned up whenever possible.

Additionally, the entire contents of org.openide.src.* and org.openide.src.nodes.*, as well as org.openide.cookies.SourceCookie and some associated property editors, were moved to a separate module.

The most common apparent symptom for module authors will be the absence of TopManager. Most methods in this class have been replaced by newer utility classes in a straightforward manner. See the Upgrade Guide.


The deprecated classes continue to be available in the module org.openide.deprecated which you may depend on it you cannot remove uses of the deprecated APIs. In order for TopManager.getDefault() to work, you must also require the token org.openide.TopManager, which is provided by an unspecified module. The deprecated API module and its implementation module are autoloads, meaning they will not be loaded unless some module still requires them.

Similarly, the Java Hierarchy API was moved to the module org.openide.src which you should depend on in order to use this API.

For compatibility, the above three dependencies are added to your module automatically in case it either requests no specific API version at all, or requests an API version prior to 3.14. Modules requesting APIs 3.14 or higher must declare these dependencies explicitly if they in fact need them.