Introduction

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.nodes > 1.20

Changes by affected class

org.openide.actions.AbstractCompileAction

org.openide.nodes.AbstractNode

org.openide.actions.AddWatchAction

org.openide.cookies.ArgumentsCookie

org.openide.nodes.BeanChildren

org.openide.nodes.BeanInfoSearchPath

org.openide.nodes.BeanNode

org.openide.actions.BuildAction

org.openide.actions.BuildAllAction

org.openide.actions.BuildProjectAction

org.openide.nodes.ChildFactory

org.openide.nodes.Children

org.openide.explorer.propertysheet.editors.ChoicePropertyEditor

org.openide.actions.CleanAction

org.openide.actions.CleanAllAction

org.openide.actions.CompileAction

org.openide.actions.CompileAllAction

org.openide.actions.CompileProjectAction

org.openide.cookies.CompilerCookie

org.openide.loaders.CompilerSupport

org.openide.options.ControlPanel

org.openide.nodes.CookieSet

org.openide.loaders.DataObjectFilter

org.openide.cookies.DebuggerCookie

org.openide.actions.DebugProjectAction

org.openide.nodes.DefaultHandle

org.openide.DialogDisplayer

org.openide.explorer.propertysheet.editors.DirectoryOnlyEditor

org.openide.cookies.ElementCookie

org.openide.explorer.propertysheet.editors.ElementFormatEditor

org.openide.cookies.ExecCookie

org.openide.loaders.ExecSupport

org.openide.actions.ExecuteAction

org.openide.actions.ExecuteProjectAction

org.openide.loaders.ExecutionSupport

org.openide.loaders.ExtensionListEditor

org.openide.explorer.propertysheet.editors.ExternalCompiler

org.openide.explorer.propertysheet.editors.FileEditor

org.openide.explorer.propertysheet.editors.FileOnlyEditor

org.openide.filesystems.FileUtil

org.openide.nodes.FilterNode

org.openide.actions.FinishDebuggerAction

org.openide.actions.GoAction

org.openide.actions.GoToCursorAction

org.openide.actions.HelpAction

org.openide.awt.HtmlBrowser

org.openide.explorer.propertysheet.editors.IconEditor

org.openide.explorer.propertysheet.editors.IdentifierArrayEditor

org.openide.modules.IllegalModuleException

org.openide.nodes.Index

org.openide.nodes.IndexedCustomizer

org.openide.nodes.IndexedNode

org.openide.explorer.propertysheet.InplaceEditor

org.openide.windows.InputOutput

org.openide.windows.IOProvider

org.openide.LifecycleManager

org.openide.modules.ManifestSection

org.openide.explorer.propertysheet.editors.MethodParameterArrayEditor

org.openide.explorer.propertysheet.editors.ModifierEditor

org.openide.modules.ModuleDescription

org.openide.nodes.Node

org.openide.nodes.NodeMemberEvent

org.openide.nodes.NodeOp

org.openide.nodes.NodeOperation

org.openide.nodes.NodeReorderEvent

org.openide.actions.OpenProjectAction

org.openide.windows.OutputEvent

org.openide.windows.OutputListener

org.openide.windows.OutputWriter

org.openide.Places

org.openide.cookies.ProjectCookie

org.openide.util.actions.ProjectSensitiveAction

org.openide.nodes.PropertyEditorRegistration

org.openide.nodes.PropertyEditorSearchPath

org.openide.explorer.propertysheet.PropertyEnv

org.openide.explorer.propertysheet.PropertySheet

org.openide.explorer.propertysheet.PropertySheetSettings

org.openide.loaders.RepositoryNodeFactory

org.openide.actions.SaveProjectAction

org.openide.cookies.SourceCookie

org.openide.actions.StartDebuggerAction

org.openide.awt.StatusDisplayer

org.openide.actions.StepOutAction

org.openide.explorer.propertysheet.editors.StringArrayCustomEditor

org.openide.explorer.propertysheet.editors.StringArrayCustomizable

org.openide.explorer.propertysheet.editors.StringArrayEditor

org.openide.actions.ToggleBreakpointAction

org.openide.TopManager

org.openide.actions.TraceIntoAction

org.openide.actions.TraceOverAction

org.openide.explorer.propertysheet.editors.TypeEditor


Details of all changes by API and date


Nodes API

Adding @BeanInfoSearchPath annotation

Nov 22 '12; API spec. version: 7.32; affected top-level classes: NodeOp BeanInfoSearchPath; made by: jhorvath; issues: #210323

Adding @BeanInfoSearchPath annotation to allow convenient way of registering BeanInfo search path.

Adding @PropertyEditorRegistration and @PropertyEditorSearchPath annotations

Sep 12 '12; API spec. version: 7.30; affected top-level classes: NodeOp PropertyEditorRegistration PropertyEditorSearchPath; made by: jhorvath; issues: #218300

Adding @PropertyEditorRegistration and @PropertyEditorSearchPath annotations to allow convenient way of registering property editors.

ChildFactory.createKeys better supports incremental display

Jan 3 '12; API spec. version: 7.27; affected top-level classes: ChildFactory; made by: jglick; issues: #206556

An implementation of ChildFactory.createKeys may now use List.add a number of times and return true at the end, while still displaying keys incrementally.


Compatibility:

Existing factories which returned false from createKeys may continue to do so with the same behavior, but should consider just producing all keys within the body of the loop instead.

A way to show a custom editor dialog for a property

Aug 31 '11; API spec. version: 7.24; affected top-level classes: NodeOperation; made by: tpavek; issues: #201223
Added NodeOperation.showCustomEditorDialog method that shows a modal dialog for given property just like when the [...] button in property sheet is pressed.

A mechanism to provide node's children lazily.

Sep 9 '10; API spec. version: 7.18; affected top-level classes: Node; made by: mentlicher; issues: #190115

Children have a new createLazy(Callable<Children> factory) method, that can be used to provide a lazy children implementation. Callable.call() is called just when node's children are really needed.

New constructor of IndexedNode

Apr 16 '10; API spec. version: 7.16; affected top-level classes: IndexedNode; made by: jtulach; issues: #163258

IndexedNode has new constructor that accepts Lookup.

Support for declarative Node registrations

Apr 1 '09; API spec. version: 7.9; affected top-level classes: NodeOp; made by: jtulach; issues: #161286

NodeOp.factory is new layer based factory method to allow declarative definition of a root node into the UI.

Adding ChildFactory.Detachable to allow ChildFactory implementations to attach and detach listeners more easily

Nov 25 '08; API spec. version: 7.7; affected top-level classes: ChildFactory; made by: tboudreau; issues: #153347
ChildFactory is useful for creating node children lazily on a background thread, and for simplifying working with Children.Keys. One oversight in the original API was providing for notification that the ChildFactory is no longer in use and should clean up any resources and detach any listeners it can.

ChildFactory.Detachable is an abstract class which adds addNotify() and removeNotify() methods to ChildFactory. addNotify() is called immediately before the first call to createKeys() after creation or a call to removeNotify().

Adding public int Children.getNodesCount(boolean optimalResult), protected Children.Keys(boolean lazy), Children.snapshot(), NodeMemberEvent.getSnapshot(), NodeReorderEvent.getSnapshot()

Aug 4 '08; API spec. version: 7.7; affected top-level classes: Children NodeMemberEvent NodeReorderEvent; made by: t_h; issues: #121913
Children.Keys with lazy behavior can be created by using Children.Keys(boolean lazy). Children.getNodesCount(boolean optimalResult) can be used instead of Children.getNodes(boolean optimalResult) for children "initialization". While keeping same behavior as Children.getNodes(boolean optimalResult) for "default" (non-lazy) implementation it allows full initialization without need to create all nodes. Children.snapshot() creates an immutable snapshot representing the current view of the nodes in this children object. Such snapshots are available in NodeMemberEvent and NodeReorderEvent via getSnapshot() and provide information about state of nodes in time when events were emited.

Children.getNodeAt is changing to public

Jun 2 '08; API spec. version: 7.5; affected top-level classes: Children; made by: t_h; issues: #121913
Adding possibility to get node at specific position rather than whole array of nodes.

API for Children objects that asynchronously compute keys/child nodes and simplifies implementation of Children.Keys usages

Jun 1 '07; API spec. version: 7.1; made by: tboudreau; issues: #91529
Added the class ChildFactory and the method Children.create(ChildFactory factory, boolean asynchronous) to the API. This simplifies creation of Node children which need to be computed on a background thread for performance reasons. Anyone wishing to do this can simply extend ChildFactory and pass that to Children.create() to automatically get a Node that will display a Please Wait child node when first expanded. A ChildFactory can either compute all child nodes, or batch them in multiple passes.

ChildFactory can also be used to implement synchronous children, by setting the asynchronous parameter passed to Children.create() to false. This could replace most common usages of Children.Keys, and make it easy to switch to asynchronous child computation if that is determined to be necessary for performance reasons.

CookieSet can hold any objects and not just cookies

Nov 6 '06; API spec. version: 7.0; affected top-level classes: CookieSet; made by: jtulach; issues: #62707
New method CookieSet.createGeneric has been added. It allows to create an instance of CookieSet that can contain any object, not just Cookies. This addition change is accompanied with two additional changes: CookieSet now implements Lookup.Provider and thus has a method getLookup to allow queries for of its content. Also there is a new method assign(clazz, instances) that allows to add/remove plain old java objects to the CookieSet.

BeanNode constructor allows passing Lookup instance

Aug 18 '06; API spec. version: 6.9; affected top-level classes: BeanNode; made by: pnejedly; issues: #67098
Adding a new constructors to BeanNode, allowing subclasses to pass context Lookup.

AbstractNode allows using different icon extensions

Jul 14 '05; API spec. version: 6.5; affected top-level classes: AbstractNode; made by: pnejedly; issues: #53461
Adding possibility for AbstractNode to use PNG files as icons. Adding new final method setIconBaseWithExtension(String baseExt) which replaces the original method for manipulating icon base, setIconBase(String). The original (now deprecated) method stil works the same way, using ".gif" as extension The original method setIconBase(String) delegates to the new one, using the default extension.

FilterNode allows controlling delegation of getValue/setValue calls

Feb 13 '04; API spec. version: 4.25; affected top-level classes: FilterNode; made by: pnejedly; issues: #31006
From this version, the FilterNode by default delegates all getValue(String) and setValue(String, Object) calls the to the original node. Also, FilterNode now exports two new constants, FilterNode.DELEGATE_SET_VALUE and FilterNode.DELEGATE_GET_VALUE, which can be used to control the delegation of the above mentioned methods.

InplaceEditor interface added to APIs, some deprecations in property sheet rewrite

Jul 16 '03; API spec. version: 4.9; affected top-level classes: Node org.openide.explorer.propertysheet.InplaceEditor org.openide.explorer.propertysheet.PropertyEnv org.openide.explorer.propertysheet.PropertySheet org.openide.explorer.propertysheet.PropertySheetSettings; made by: tboudreau; issues: #29447
New interface that allows a property editor to supply an inline editor for the new property sheet added, as part of merging the new property sheet. A method, registerInplaceEditorFactory() has been added to PropertyEnv to allow modules to supply an inplace editor globally for all properties of a given type; also, Node.Property objects may supply a custom inplace editor instance via the hint "inplaceEditor" in getValue(String).

PropertySheetSettings is an old SystemOption subclass that offers settings that affect the display of the property sheet. These settings are irrelevant to the new property sheet.

In order to provide some performance optimizations, it was necessary to un-final the class PropertyEnv. However, it should be treated as final outside the package - there should never be a need to subclass it. A note has been added to its javadoc to this effect.

A non-normative hint may now be supplied by instances of Node.PropertySet to return a localized display name for a tab which the property sheet should use for displaying that and any other property sets which share the name: "tabName".

New FilterNode constructor that takes Lookup

Apr 7 '03; API spec. version: 4.4; affected top-level classes: FilterNode; made by: jtulach; issues: #32470
Allows users of FilterNode to provide own specific lookup.

Returning value of NodeOp.findActions method refined

Feb 26 '03; affected top-level classes: NodeOp; made by: pzavadsky; issues: #31476
The utility method NodeOp.findActions(Nodep[]) is changed the way it returns an empty array instead of null (for the cases there are no actions found). Also javadoc is refined in that sense.
Compatibility: In fact this is just a slight refinement of the API intoduced by 3.29 change.

Added method Node.Property.isDefaultValue

Nov 8 '02; API spec. version: 3.19; affected top-level classes: Node; made by: dstrupl
Method public boolean isDefaultValue() has been added to class Node.Property. The idea behind this is to visually mark modified properties in the property sheet. If the method returns false it means that the value has been modified by the user and visual feedback will be shown. The reason why the default impl is returning true is to make the old properties (properties using previous version of the API) look the same as they did before the change.

Node implements Lookup.Provider

Oct 3 '02; API spec. version: 3.11; affected top-level classes: Node; made by: jtulach; issues: #26790
Node has been extended to provide method getLookup that allows better querying possibilities than the old Node.getCookie method. New constructors have been provided to allow to pass a Lookup instance to newly created node. In such case Node.getCookie delegates to the provided instance, otherwise Node.getLookup delegates to Node.getCookie content.

New method setChildren() in Node

Jul 15 '02; API spec. version: 3.1; affected top-level classes: Node; made by: phrebejk
Node has new method setChildren(Children) which allows to change the Children of given Node. Node also fires new PropertyChangeEvent(PROP_LEAF) whenever changing children from non-LEAF to LEAF and vice-versa.

Added Children.getNodes(boolean optimalResult)

May 2 '02; API spec. version: 2.17; affected top-level classes: Children; made by: pnejedly
Added an additional getNodes() method when the API user can specify whether he need the most right result. The method is needed for code-based navigation through nodes, like scripting, and for testability. SPI implementors can implement it better.

Nodes can be declared through layers, manifest declaration deprecated

Apr 24 '02; API spec. version: 2.16; made by: dsimonek; issues: #19609
Added possibility to define Environment, Runtime and Root nodes through layer instead of manifest declaration. Manifest declaration is now deprecated.

It is impossible to remove CookieSet.Factory from CookieSet

Feb 28 '02; API spec. version: 2.6; affected top-level classes: CookieSet; made by: dstrupl; issues: #15373
The API for CookieSet was not symmetrical. You could add factories but there was no way to remove them.

Method changing original Node added into FilterNode and FilterNode.Children

Oct 16 '01; API spec. version: 1.39; affected top-level classes: FilterNode; made by: phrebejk; issues: #12048
Method protected final void changeOriginal( Node original, boolean ) and protected final void changeOriginal( Node original added to the class FilterNode and FilterNode.Children. The methods allow to change the Node resp. Children the FilterNode resp. FilterNode.Children delegates to. For more detailed information please see the Javadoc of the methods.

Added Index.Support.showIndexedCustomizer

Oct 11 '01; API spec. version: 1.37; affected top-level classes: Index IndexedCustomizer; made by: jglick; issues: #9323
The static method Index.Support.showIndexedCustomizer(Index) was added to provide a simpler way of displaying a dialog to reorder a set of nodes based on an index cookie. Unlike direct use of the IndexedCustomizer dialog, it interacts smoothly with the IDE's window system.
Compatibility: Code using IndexedCustomizer directly (as a dialog) should consider using the new method instead.

Method for checking PropertyChangeListeners on Node added

Oct 8 '01; API spec. version: 1.36; affected top-level classes: Node; made by: phrebejk; issues: #15495
Method protected final boolean hasPropertyChangeListeners() added to the class Node. Method returns true if at least one PropertyChangeListener is attached to the Node. At the same time changes were made to optimize the number of attached listeners so calling this method should have some information value.

AbstractNode.cookieSet protected, not public

May 19 '01; affected top-level classes: AbstractNode; made by: jglick
getCookieSet now protected, not public. Logically it should never have been public, since each object is responsible for providing its own set of cookies as it sees fit, and making it possible for anyone to retrieve and modify its cookie set without its explicit permission violates this modularity. Also setCookieSet deprecated.
Compatibility: Subclasses of the node should have the responsibility of adding or removing cookies. See further notes under MultiDataObject .
Binary-compatible

Children.Keys.createNodes can be null

Mar 15 '01; affected top-level classes: Children; made by: jtulach
createNodes(Object key) can now return null if the key should have no nodes to represent it. The purpose is to reduce the number of useless created objects.

Index.KeyChildren.createIndex protected

Mar 13 '01; affected top-level classes: Index
Method createIndex made protected.

May provide special lock for index implementations

Mar 6 '01; affected top-level classes: Index
Added method protected Index.KeyChildren.lock() which returns an object that is used as a synchronization lock when working the the list object provided in constructor.

Properties and property sets may have help

Jan 30 '01; affected top-level classes: Node; made by: jglick
Node.PropertySet and Node.Property may now have the FeatureDescriptor property helpID set on them (to a String) help ID) which may be used in the property sheet.

Creation of popup menus handle duplicate actions

Aug 9 '00; affected top-level classes: NodeOp
Changed method findContextMenuImpl. In case of constructing menu from node which for some reason has more than one occurrence of the same SystemAction no menu item was created. Now one menu item will be created for such an action, where the first occurrence is taken into account.

BeanChildren changed superclass

Jun 23 '00; affected top-level classes: BeanChildren
Changed superclass from Children.Map to Children.Keys.
Compatibility: Any subclasses which used the following methods will be broken: There were no known subclasses of BeanChildren (it is rarely used at all).

Added Index.KeyChildren

May 2 '00; affected top-level classes: Index
New class that should simplify displaying and reordering of nodes representing java.util.List. Automatically provide implementation of Index to reorder content of the list.

NodeOp.setDefaultActions removed

May 2 '00; affected top-level classes: NodeOp
setDefaultActions deprecated.
Compatibility: First removed, later re-added but deprecated in trunk and boston. Only technically incompatible: could always only be called once, otherwise a SecurityException would be thrown.

Default node handle stores only direct parent

Mar 9 '00; affected top-level classes: DefaultHandle; made by: jglick
DefaultHandle rewritten. Now stores just handle of direct parent, so that intervening nodes have the opportunity to supply their own handles.
Compatibility: It never actually worked before anyway; no module could have successfully used the previous behavior and be broken by the change.

Uncategorized changes

API separation, phase II

Nov 1 '02; API spec. version: 3.17; affected top-level classes: org.openide.actions.AbstractCompileAction org.openide.actions.BuildAction org.openide.actions.BuildAllAction org.openide.actions.CleanAction org.openide.actions.CleanAllAction org.openide.actions.CompileAction org.openide.actions.CompileAllAction org.openide.actions.ExecuteAction org.openide.cookies.ArgumentsCookie org.openide.cookies.CompilerCookie org.openide.cookies.ExecCookie org.openide.filesystems.FileUtil org.openide.loaders.CompilerSupport org.openide.loaders.ExecutionSupport org.openide.windows.IOProvider org.openide.windows.InputOutput org.openide.windows.OutputEvent org.openide.windows.OutputListener org.openide.windows.OutputWriter; affected packages: org.openide.compiler org.openide.execution; 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:


Compatibility:

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.


Binary-compatible

API separation, phase I

Oct 15 '02; API spec. version: 3.14; affected top-level classes: org.openide.DialogDisplayer org.openide.LifecycleManager org.openide.Places org.openide.TopManager org.openide.actions.AddWatchAction org.openide.actions.BuildProjectAction org.openide.actions.CompileProjectAction org.openide.actions.DebugProjectAction org.openide.actions.ExecuteProjectAction org.openide.actions.FinishDebuggerAction org.openide.actions.GoAction org.openide.actions.GoToCursorAction org.openide.actions.HelpAction org.openide.actions.OpenProjectAction org.openide.actions.SaveProjectAction org.openide.actions.StartDebuggerAction org.openide.actions.StepOutAction org.openide.actions.ToggleBreakpointAction org.openide.actions.TraceIntoAction org.openide.actions.TraceOverAction org.openide.awt.HtmlBrowser org.openide.awt.StatusDisplayer org.openide.cookies.DebuggerCookie org.openide.cookies.ElementCookie org.openide.cookies.ProjectCookie org.openide.cookies.SourceCookie org.openide.explorer.propertysheet.editors.ChoicePropertyEditor org.openide.explorer.propertysheet.editors.DirectoryOnlyEditor org.openide.explorer.propertysheet.editors.ElementFormatEditor org.openide.explorer.propertysheet.editors.ExternalCompiler org.openide.explorer.propertysheet.editors.FileEditor org.openide.explorer.propertysheet.editors.FileOnlyEditor org.openide.explorer.propertysheet.editors.IconEditor org.openide.explorer.propertysheet.editors.IdentifierArrayEditor org.openide.explorer.propertysheet.editors.MethodParameterArrayEditor org.openide.explorer.propertysheet.editors.ModifierEditor org.openide.explorer.propertysheet.editors.StringArrayCustomEditor org.openide.explorer.propertysheet.editors.StringArrayCustomizable org.openide.explorer.propertysheet.editors.StringArrayEditor org.openide.explorer.propertysheet.editors.TypeEditor org.openide.loaders.DataObjectFilter org.openide.loaders.ExecSupport org.openide.loaders.ExecutionSupport org.openide.loaders.ExtensionListEditor org.openide.loaders.RepositoryNodeFactory org.openide.modules.IllegalModuleException org.openide.modules.ManifestSection org.openide.modules.ModuleDescription org.openide.nodes.NodeOperation org.openide.options.ControlPanel org.openide.util.actions.ProjectSensitiveAction org.openide.windows.IOProvider; affected packages: org.openide.debugger org.openide.src org.openide.src.nodes; 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.


Compatibility:

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.


Binary-compatible

Built on October 31 2014.  |  Portions Copyright 1997-2014 Oracle. All rights reserved.