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.
release41 branch was made on Apr 03 '05 for use in the NetBeans 4.1 release.
Specification versions: 6.0 begins after this point.
release40 branch was made on Nov 01 '04 for use in the NetBeans 4.0 release.
Specification versions: 5.0 begins after this point.
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.
ModuleInstall lifecycle
FileObject
OnStart and OnStop
Places
ModuleInstall lifecycle
InstalledFileLocator.locateAll
@PatchedPublic
FileObject
openide.jar is gone, update your module dependencies!
ModuleInfo.getClassLoader()
InstalledFileLocator
Thread.contextClassLoader defaults to TopManager.systemClassLoader
ModuleDescription constructor may specify a classloader
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
OnStart and OnStop
Places
ModuleInstall lifecycle
InstalledFileLocator.locateAll
@PatchedPublic
FileObject
openide.jar is gone, update your module dependencies!
ModuleInfo.getClassLoader()
InstalledFileLocator
org.openide.modules.ConstructorDelegate
org.openide.modules.Dependency
org.openide.modules.InstalledFileLocator
InstalledFileLocator.locateAll
InstalledFileLocator
org.openide.modules.ModuleInfo
ModuleInfo.getClassLoader()
org.openide.modules.ModuleInstall
ModuleInstall lifecycle
org.openide.modules.Modules
org.openide.modules.OnStart
OnStart and OnStop
org.openide.modules.OnStop
OnStart and OnStop
org.openide.modules.PatchedPublic
@PatchedPublic
org.openide.modules.PatchFor
org.openide.modules.Places
Places
org.openide.modules.SpecificationVersion
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
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.
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).
Modules; made by: jtulach; issues:
#225582
New findCodeNameBase(String) method returning
ModuleInfo
or null.
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.
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
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.
Places
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.
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.
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.
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.
ModuleInstall lifecycle
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).
InstalledFileLocator.locateAll
InstalledFileLocator; made by: jglick; issues:
#36701
You can now locate multiple variants of an installed file path from different clusters.
Dependency; made by: jtulach; issues:
#160390
Dependency now implements Serializable
@PatchedPublic
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.
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:
com.sun.javadoc com.sun.source com.sun.tools.javac com.sun.tools.javadoc javax.annotation javax.jws javax.lang.model javax.tools javax.xml.bind javax.xml.soap javax.xml.stream javax.xml.ws
FileObject
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.
org.openide.modules.os.Linux and
org.openide.modules.os.Solaris.
For more details read here.
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.
Dependency; made by: jtulach
OpenIDE-Module-Needs: token which is slightly
less restrictive than usual
OpenIDE-Module-Requires: token as
explain in the documentation.
Dependency; made by: jtulach
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.
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!
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:
lib/boot.jar contains what it used to have
together with module system runtime independent of other NetBeans APIs.
lib/org-openide-util.jar is next to boot.jar to provide
the basic infrastructure used by boot.jar.
lib/org-openide-modules.jar provides the APIs that the
boot.jar implements.
core/core.jar is loaded dynamically
by the boot.jar and contains most of the startup code and the
NetBeans dependentpart of module system. For its implementation it needs filesystems which are along as well.
core/org-openide-filesystems.jar the filesystems API is needed
for the standard launch code to read module config files and listen to changes in their
amount or content.
modules/org-openide-nodes.jar and other openide libraries
are now turned into real modules.
modules/org-netbeans-core.jar is also a module
and contains the rest of original core.jar. It is likely that this one is going
to be split even more, as the UI could be separated to core/ui, etc.
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.
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.
ModuleInfo.getClassLoader()
ModuleInfo; made by: jglick; issues:
#38330
ModuleInfo.getClassLoader() making it
possible to find a Java class loader associated with an enabled module.
ModuleInfo.
ModuleInfo; made by: jtulach; issues:
#36064
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 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.
InstalledFileLocator
InstalledFileLocator; made by: jglick; issues:
#28683
netbeans.home and netbeans.user should be
replaced with calls to the new supported API.
OpenIDE-Module-Deprecated
and localized attribute OpenIDE-Module-Deprecation-Message
may be used to warn clients of an obsolete API module.
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
Dependency ModuleInfo; made by: jglick; issues:
#18781
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.
Dependency; made by: jglick; issues:
#19714
JavaHelp support is now in a separate module,
org.netbeans.modules.javahelp/1. This module includes the
javax.help.** 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
javax.help.** 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 javax.help.**, 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.
ModuleInfo; made by: jpokorsky
owns(Class) to determine if the provided class was
loaded as a part of the module.
ModuleInfo; made by: jglick
OpenIDE-Module-Module-Dependency-Message and
OpenIDE-Module-Package-Dependency-Message.
ModuleInfo Dependency SpecificationVersion ModuleInstall; made by: jglick
ModuleDescription, ManifestSection, and
IllegalModuleException deprecated. ModuleInfo,
Dependency, SpecificationVersion, and
ModuleInstall.validate added. Module information available
from lookup. Localized properties may be stored in bundles.
getSectionClass().
getLongDescription and
TAG_LONG_DESCRIPTION.
getDescriptionResource. Retrieving as URL deprecated.
getDisplayCategory and TAG_CATEGORY.
getShortDescription and
TAG_SHORT_DESCRIPTION.
getLayerResource() added. Thus all locale variants of a layer
may be merged together. Retrieval as URL is deprecated.
PackageAccessibleClassLoader added to make it
easier to check package dependencies. Package dependencies which include
sample classes are now permitted.
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.
getClassLoader, setClassLoader and
getBadClasses.
ModuleDescription constructor may specify a classloader
Three sections of the Open APIs were split into new autoload modules.
The module org.openide.compiler (version 1.0) contains
the Compiler API and some other classes directly related to it.
The module org.openide.execution (version 1.0) contains
the Execution API and some other classes directly related to it.
The module org.openide.io (version 1.0) contains
InputOutput and related classes (formerly part of the
Window System API, and still physically in the
org.openide.windows package).
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:
org.openide.compiler.CompilationEngine, in order to
call CompilationEngine.getDefault(), or safely use
AbstractCompileAction or one of its subclasses, or
call CompilerJob.start(), or use
BeanInfos for Compiler API classes, etc.
org.openide.execution.ExecutionEngine, in order to
call ExecutionEngine.getDefault(), or safely use
ExecuteAction, or call
Executor.execute(...), or use BeanInfos
for Execution API classes, etc.
org.openide.windows.IOProvider, in order to call
IOProvider.getDefault().
Other minor changes:
Registration of URL stream handler factories using
NbfsStreamHandlerFactory.register(...) is deprecated.
Simply create an instance of URLStreamHandlerFactory
and add it to Lookup instead.
The method FileUtil.nbfsURLStreamHandler was added,
but is not intended for use by modules.
All uses of ExecInfo are deprecated as they abuse the
distinction between Filesystems and the user classpath. Use and
override only Executor.execute(DataObject). Similarly,
ThreadExecutor is deprecated for the time being
because it suffers from similar problems.
Direct use of NbfsURLConnection is deprecated in favor
of the more general URLMapper from the Filesystems
API.
Package dependencies on
org.netbeans.lib.terminalemulator must be replaced
with module dependencies on a new autoload module
org.netbeans.lib.terminalemulator (version 1.0).
Several static convenience methods have been added to
AbstractCompileAction. Of most interest is
prepareJobFor. Module code should no longer assume
that DataFolder has a CompilerCookie
which recursively compiles the folder and subfolders (according to
depth); while it is still true, for reasons of compatibility, new
code should use prepareJobFor to create a compiler job
from a folder.
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, org.openide.io > 1.0
OpenIDE-Module-Requires: org.openide.compiler.CompilationEngine,
org.openide.execution.ExecutionEngine, org.openide.windows.IOProvider
And any package dependencies from old modules on
org.netbeans.lib.terminalemulator will be converted to
module dependencies.
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.