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: > 1.20

Changes by affected class



































































Details of all changes by API and date

Window System API

Allow Modes to be created directly from ModeConfig XML

Mar 18 '19; API spec. version: 6.6.81; affected top-level classes: Mode ModeUtilities WindowManager; made by: phipma

Plugin implementors can save and restore individual Modes providing scope for custom TopComponent layouts.

Allow to select Mode for opening a TopComponent instance

May 2 '17; API spec. version: 6.6.77; affected top-level classes: ModeSelector; made by: sdedic

Plugin implementors can direct to-be-opened TopComponents to appropriate Modes or prevent them to open in inappropriate Modes.

Added method afterRedirect(CloneableOpenSupport) to CloneableOpenSupport

Feb 20 '14; API spec. version: 6.70; affected top-level classes: CloneableOpenSupport; made by: vv159170; issues: #241991

The method is called when CloneableOpenSupportRedirector found another instance of CloneableOpenSupport to open instead the current. It is possible to override afterRedirect in derived classes and handle this situation.

Override window system branding properties

Feb 3 '14; API spec. version: 6.69; made by: saubrecht

It is possible to override boolean window system properties defined in resource bundle org/netbeans/core/windows/ with system properties prefixed with "NB.WinSys.". For example property Mix.Editors.And.Views.Enabled can be overriden with a command-line switch -J-DNB.WinSys.Mix.Editors.And.Views.Enabled=false.

Abstract class CloneableOpenSupportRedirector added

Aug 13 '13; API spec. version: 6.65; affected top-level classes: CloneableOpenSupportRedirector; made by: igor_nikiforov; issues: #230126

Version of CloneableEditorSupportRedirector which will be called only during opening of document when algorith tries to understand if file is in list of already opened TCs or not. SPI implementers to setup filter on specific requests only... This could minimize number of redirect() calls.

Added methods getLookup() and isShowing() in TopComponent.SubComponent.

Apr 17 '13; API spec. version: 6.63; affected top-level classes: TopComponent; made by: theofanis; issues: #228448

The new methods can be used in conjunction with split multiview window, where e.g. the pallette needs to know which two of the available subcomponents are showing and query their lookup.

Allow TopComponent's header to be permanently highlighted to draw user's attention.

Aug 31 '12; API spec. version: 6.58; affected top-level classes: TopComponent WindowManager; made by: saubrecht; issues: #217509

New method setAttentionHighlight(boolean) in TopComponent class can be used to permanently highlight TopComponent's tab until user activates it.

New API to check/modify the floating and minimize state of a TopComponent.

Jul 4 '12; API spec. version: 6.57; affected top-level classes: WindowManager; made by: saubrecht; issues: #214854

New methods in WindowManager class:

Easy to use replacement for invokeWhenUIReady

Mar 31 '12; API spec. version: 6.54; affected top-level classes: OnShowing; made by: jtulach; issues: #200636

In case you want to execute a code as soon as main window is visible, consider using OnShowing annotation.

New branding property to disable Ctrl+Tab window switching.

Mar 21 '12; API spec. version: 6.53; made by: saubrecht

There's a new branding property WinSys.CtrlTabSwitching.In.JTable.Enabled to disable Ctrl+Tab window switching when JTable or JTabbedPane has input focus.

Added method TopComponent.getSubComponents.

Mar 7 '12; API spec. version: 6.52; affected top-level classes: TopComponent; made by: saubrecht; issues: #209051

The new method can be used to access for example inner tabs in a multiview window.

Added method TopComponent.getShortName()

Mar 7 '12; API spec. version: 6.52; affected top-level classes: TopComponent; made by: saubrecht; issues: #209059

The new method can be used to retrieve a short version of TopComponent's display name, i.e. display name that does no include the name of activated Node.

Added method TopComponent.makeBusy(boolean).

Feb 14 '12; API spec. version: 6.51; affected top-level classes: WindowManager TopComponent; made by: saubrecht; issues: #208026

The new method can be used to inform user that some (possibly lengthy) process is being run in given TopComponent.

Added branding options to replace the custom TabbedContainer with plain Swing JTabbedPane.

Jan 25 '12; API spec. version: 6.50; made by: saubrecht; issues: #150393

By branding of module it is possible to use plain JTabbedPane component to display window tabs instead of the custom TabbedContainer. The property name is WinSys.TabControl.SimpleTabs.Enabled

Added a client property to turn copy drag and drop of clonable TopComponents off.

Nov 12 '11; API spec. version: 6.48; affected top-level classes: TopComponent; made by: saubrecht
Added a new boolean client property PROP_DND_COPY_DISABLED. When set to Boolean.TRUE on a CloneableTopComponent then it is not possible to perform copy drag and drop operation with it.

Added optional role parameter to TopComponent Registration annotation.

Oct 19 '11; API spec. version: 6.45; affected top-level classes: TopComponent; made by: saubrecht; issues: #199452
Since the window system now supports multiple window layouts - roles - the annotation for TopComponent registration needs an optional parameter to specify one or more roles the window should belong to. If no roles are specified, the TopComponent is registered in the default layout.

Added more attributes to Mode DTD to support new winsys features.

Jun 7 '11; API spec. version: 6.44; made by: saubrecht; issues: #199074
New window system features - sliding bar for minimized windows at the top of the main window, drag and drop of the whole window group and minimization of the whole window group - require small additions to Mode DTD.

Support multiple window system layouts.

Jun 6 '11; API spec. version: 6.43; affected top-level classes: WindowManager WindowSystemListener WindowSystemEvent; made by: saubrecht; issues: #198859
It is possible to define multiple window system layouts and switch between them either at startup or at runtime.

Allow custom painted background in the main IDE window.

Feb 15 '11; API spec. version: 6.38; made by: saubrecht
There's a new Boolean property NbMainWindow.showCustomBackground in javax.swing.UIManager. When the property value is TRUE then the window system will turn off opacity for most of the main window components - menu bar, toolbars, status bar, sliding bars and the main desktop area component. That means that the main window background will be showing through these components. It can be used to paint some watermark or logo or gradient on the main window background, especially when using custom main window implementation, see change id

Register default TopComponent location via annotations

Nov 30 '10; API spec. version: 6.37; affected top-level classes: TopComponent; made by: jtulach; issues: #191407
Use TopComponent.Registration, TopComponent.Description and TopComponent.OpenActionRegistration to register default location of a TopComponent, some of its properties and action to open it.

Reuse existing JFrame instance (if any) as IDE's main window.

Nov 23 '10; API spec. version: 6.36; made by: saubrecht
When window system loads it checks for existing Frames (java.awt.Frame.getFrames()) and if there is a JFrame whose name is "NbMainWindow" then it is reused as the main window. Main menu, toolbars and content pane will be put into this existing JFrame. If there isn't such a JFrame instance then a new empty JFrame is created and used for the main window - the same way as before this change.

Annotation to retain the location of non-persistent TopComponents if the user drags them to another location on the screen.

Jan 14 '10; API spec. version: 6.32; affected top-level classes: RetainLocation; made by: tboudreau; issues: #168060
Added an annotation, which can be applied to TopComponents whose persistence type is PERSISTENCE_NEVER. There has been a long-term problem that such components can be defined as singleton components, and the first time they are opened, they appear in the correct place. However, on restart or after the first time they are closed, their persistence information, including the containing Mode, is lost, and thereafter they open in the editor area.

This patch does not affect the current behavior of such components. However, if you add this annotation to the component, it will remember (storage in NbPreferences) the ID of its last known parent mode. A minor patch to the window system's code for deciding if a Mode should be persistent causes it to now interpret any Mode containing a TopComponent annotated with RetainLocation as being one it should persist, so that if the user creates a transient Mode by dragging the window to a new location on screen, the data about that location is not lost on shutdown.

New method to retrieve the list of TopComponents opened in a Mode.

Jul 15 '09; API spec. version: 6.28; affected top-level classes: WindowManager; made by: saubrecht; issues: #168060
Added new a method to WindowManager to retrieve the list of TopComponents opened in a given Mode. This method does not iterate through all the TopComponents in the Mode so it prevents already closed TopComponents from being deserialized from disk.

Window system customizations on TopComponent level

Jan 29 '09; API spec. version: 6.26; made by: saubrecht; issues: #156693
Added a group of client properties that modify TopComponent's behavior in window system. E.g. disable closing, sliding, undocking etc.


Jul 8 '08; API spec. version: 6.24; made by: jtulach; issues: #136636
Adding new factory method that creates an action to open a TopComponent.

Added a group of resource bundle properties for customization of window system behavior.

Jun 6 '08; API spec. version: 6.23; made by: saubrecht; issues: #136636

There is a set of new properties defined in resource bundle which platform developers can use to customize the behavior of NetBeans' window system:

The features above can be turned on/off simply by branding of module.

Changed behavior of TopComponent.close() and TopComponentGroup.close() for non persistent TopComponent

May 27 '08; API spec. version: 6.22; made by: saubrecht; issues: #135318
Added TopComponent client property which forces the window system to respect TopComponent's preferred size when it is slided-in from left/right/bottom sliding bar when set to Boolean.TRUE. Otherwise the slided-in TopComponent will fill the entire width/length of the IDE window (the default behavior). This switch is intended for tools/palette windows like e.g. color chooser, tool picker etc.

Changed behavior of TopComponent.close() and TopComponentGroup.close() for non persistent TopComponent

Mar 27 '08; API spec. version: 6.20; made by: mslama; issues: #121218
Add client property KeepNonPersistentTCInModelWhenClosed to TopComponent to control behavior of winsys when nonpersistent TopComponent is closed. As some TopComponent wants to keep their position in winsys ie. be able to reopen at the same place and some TopComponent wants to be removed from winsys model. We added client boolean property KeepNonPersistentTCInModelWhenClosed. When this property is not set nn persistent TopComponent is removed from model when closed - it is original behavior before fix of issue #101700. If client property is set (to Boolean.TRUE) then TopComponent is kept in model. It means that client must explicitly set this client property to get behavior requested by issue #101700.

Changed behavior of TopComponent.close() and TopComponentGroup.close() for non persistent TopComponent

Oct 23 '07; API spec. version: 6.18; made by: mslama; issues: #101700
Change behavior of winsys implementation when TopComponent.close() and TopComponentGroup.close() is called for non persistent TopComponent. So far if non persistent TopComponent was closed it was removed from Mode. It causes window system to forget TopComponent location so if TopComponent is reopened it is opened in default location. It is now changed so that window system keeps location of non persistent TopComponent during session. Of course this information is not stored between sessions as TopComponent is NOT persistent. So this change applies only to TopComponent with peristence type PERSISTENCE_NEVER.

Added command line boolean option 'netbeans.winsys.auto_iconify'.

Oct 9 '07; API spec. version: 6.17; made by: dsimonek; issues: #109427
Added command line boolean option 'netbeans.winsys.auto_iconify'. When system is run with option netbeans.winsys.auto_iconify=true, all separate frames will follow iconified state of main window automatically. So when main window is iconified, they all get iconified too and vice versa. Such behavior was default prior to this change, but now automatic iconification is disabled by default, to respect independency of separate frames and behave well with GNOME window managers such as default Metacity WM.

Added a method to check the TopComponent type - editor/view

May 3 '07; API spec. version: 6.16; affected top-level classes: WindowManager; made by: saubrecht; issues: #102174
Added method WindowManager.isOpenedEditorTopComponent(TopComponent) for checking of the TopComponent type - editor or view. The method returns true if the given TopComponent is opened and is docked into an editor-type Mode. It is safe to call this method outside the event dispatch thread.

Added methods for opening TopComponent at specified position

Apr 6 '07; API spec. version: 6.15; affected top-level classes: TopComponent WindowManager; made by: dsimonek; issues: #94604
Added method TopComponent.openAtTabPosition(int) for opening and inserting top component at specified position. For retrieving current position, method TopComponent.getTabPosition() was added.

Removal of and cmnd line option.

Mar 6 '07; API spec. version: 6.14; made by: dsimonek; issues: #81330 #50352
Command line option,sdi) used for starting the system either in sdi or mdi mode, was deleted. Support for sdi was dropped and replaced by floating windows support. System will now always start in mdi mode.

Added a method to check the type of a TopComponent - 'editor' or 'view'

Feb 22 '07; API spec. version: 6.13; affected top-level classes: WindowManager; made by: saubrecht; issues: #96338
Added method isEditorTopComponent( TopComponent tc) to WindowManager that returns true if there is a Mode that the TopComponent will be/is docked to and the Mode is of 'editor' kind (i.e. holds editor windows).


Nov 23 '06; API spec. version: 6.12; made by: saubrecht
Source level has been upgraded to 1.5 and all API use generics now.

Enhanced logic for maximized mode

Nov 10 '06; API spec. version: 6.11; made by: saubrecht; issues: #73766
When switching an editor TopComponent to maximized mode other components slide out while some components (e.g. palette) stay docked. It's also possible to maximize slided-in windows. Full description in

Slided-in windows remember their size

Oct 17 '06; API spec. version: 6.10; made by: saubrecht; issues: #87143
Each TopComponent in a sliding mode (left/right/bottom) can now have a different width/height when slided-in. These user defined sizes are stored in sliding mode's properties.

New constants PROP_TC_OPENED and PROP_TC_CLOSED in TopComponent.Registry

Oct 12 '06; API spec. version: 6.9; affected top-level classes: WindowManager; made by: dsimonek; issues: #87009
New constants PROP_TC_OPENED and PROP_TC_CLOSED was added to the TopComponent.Registry. When any instance of TopComponent is opened through its open() method, either by user or programmatically, property change event PROP_TC_OPENED is fired. Similarly, when TopComponent is closed by close() method, PROP_TC_CLOSED is fired. So clients listening to property changes of TopComponent.Registry can track opened and closed TopComponents easily.

New method to invoke code after main window is shown

Aug 23 '06; API spec. version: 6.8; affected top-level classes: WindowManager; made by: dsimonek; issues: #65431
New method WindowManager.invokeWhenUIReady has been added that can be used to execute a code that is supposed to run after main window is shown.

Added ExternalDropHandler abstract class.

May 30 '06; API spec. version: 6.7; affected top-level classes: ExternalDropHandler; made by: saubrecht; issues: #50129
When a file(s) or other objects are dragged over the editor aread of the IDE, the window system will use the global Lookup to get an instance of ExternalDropHandler class. If such an instance is available then it will be used to check whether the drop can be accepted (methods canDrop) and eventually to handle the dropped object(s) as well - method handleDrop - for example open dropped files in editor.
Note that some IDE components may have their own DropTargetListeners (for example Projects view or Files view) therefore the ExternalDropHandler will not be used when dragging over these components.

Added the TopComponent.getHtmlDisplayName, TopComponent.setHtmlDisplayName and WindowManager.topComponentHtmlDisplayNameChanged methods.

Oct 31 '05; API spec. version: 6.4; affected top-level classes: TopComponent WindowManager; made by: dsimonek; issues: #66777
The TopComponent.getHtmlDisplayName and TopComponent.setHtmlDisplayName methods was added to allow TopComponents to have display name that contains html tags differentiated from regular display name. Regular display name should be used for tasks like alphabetical sorting while html display name is used for labels and titles that support html, like editor tabs. WindowManager.topComponentHtmlDisplayNameChanged was also added to let window system implementation know about html display name change.

Added the TopComponent ability to bring their parent Window to front of other windows.

Mar 21 '05; API spec. version: 5.8; affected top-level classes: TopComponent WindowManager; issues: #56277
The TopComponent class has a new method toFront() that attempts to bring the parent Window of the TopComponent to front of other top-level windows. The method is implemented in the WindowManager class using AWT's java.awt.Window#toFront().

TopComponent can request attention

Nov 17 '04; API spec. version: 5.1; affected top-level classes: WindowManager TopComponent; made by: mkleint; issues: #48811

TopComponent.requestAttention(boolean) and TopComponent.cancelRequestAttention added to allow components to signal that they require user's attention or the attention is no longer required. It's up to the current TopComponent container to decide how to attract user's attention. If the user activates the attention-requiring component, the container assumes the goal was achieved and the action is cancelled. The methods are thread-safe.

For those implementing WindowManager class, there is an incompatible change where abstract methods topComponentCancelRequestAttention(TopComponent) and topComponentRequestAttention(TopComponent) were added.

Allow association of Lookup with TopComponent later than in constructor.

Jan 20 '04; API spec. version: 4.23; affected top-level classes: TopComponent; made by: jtulach; issues: #38475
Adding TopComponent.associateLookup to allow late (in middle of constructor) association of Lookup with component. This is especially useful in org.openide.explorer.ExplorerUtils.

Method TopComponent.getPersistenceType() is added to replace usage of client property PersistenceType.

Jan 7 '04; API spec. version: 4.20; affected top-level classes: TopComponent; made by: mslama; issues: #36916
Method to get TopComponent persistence type is added to API.

New constructor for better delegation

Dec 27 '03; API spec. version: 4.19; affected top-level classes: TopComponent; made by: jtulach; issues: #38185
Easier way for TopComponents to provide their own Lookup and still maintain their contract with getActivatedNodes.

Added method findTopComponent(String tcID) to WindowManager

Nov 25 '03; API spec. version: 4.15; affected top-level classes: WindowManager; made by: mslama; issues: #37199
This method is necessary to be able to retrieve TopComponent instance using unique TopComponent ID. Important mainly to access persistent singleton TopComponent instances.

New Window System implementation

Nov 12 '03; API spec. version: 4.13; affected top-level classes: CloneableTopComponent TopComponent TopComponentGroup WindowManager Workspace; made by: pzavadsky; issues: #29836
Provided implementation of new window system. It is a new major version of module core/windows. There also open API affected. There were added some new APIs, some older were deprecated and also some older APIs have adjusted their semantics. Look at the changes document which has the detailed information.

Removal of TopComponent(DataObject) constructor

Apr 2 '03; API spec. version: 4.3; affected top-level classes: TopComponent CloneableTopComponent; made by: jtulach; issues: #32143
Due to separation of openide-loaders.jar the TopComponent (DataObject) and CloneableTopComponent (DataObject) constructors have been removed. Instead of using the old behavior
        new TopComponent (dataObject);
please change the code to use TopComponent.NodeName:
        tc = new TopComponent ();
        NodeName.connect (tc, dataObject.getNodeDelegate ());

CloneableTopComponent.Ref.getArbitraryComponent method added

Feb 27 '03; API spec. version: 3.41; affected top-level classes: CloneableTopComponent; made by: pzavadsky; issues: #25824
The method getAnyComponent in CloneableTopComponent.Ref class uses NoSuchElementException as a mean indicating there is no component. Moreover the exception is runtime one (unchecked). It forces clients to use try-catch blocks, which doesn't follow rule, which says there shouldn't be used exception for controlling program flow. It is replaced by method getArbitraryComponent which returns null instead of throwing an exception.

New property "WizardPanel_errorMessage" for WizardDescriptor has been added

Feb 20 '03; API spec. version: 3.39; affected top-level classes: org.openide.WizardDescriptor; made by: dkonecny; issues: #28466
New property with name "WizardPanel_errorMessage" was added to WizardDescriptor class. It is String property and can contain description why the wizard panel is invalid. Non-null value of this property is automatically displayed at the bottom of the wizard panel.

Add new DTD 1.2 for wsmode configuration file

Jul 1 '02; made by: mslama; issues: #25268
Current frame state is now stored. Added attribute for restored frame state, valid only when frame state is maximized. (Restored frame state is state of frame when frame is not maximized, it can be normal or iconified.)

Add new DTD 1.1 for window manager configuration file

Jun 14 '02; made by: mslama; issues: #24451
Support for positioning main windom in MDI mode during first user start.

TopComponent shown state notification methods added to Winsys API

May 10 '02; API spec. version: 2.18; affected top-level classes: TopComponent WindowManager; made by: pzavadsky; issues: #21618
Four new methods has been added to Winsys API, i.e. TopComponent: protected void componentShowing(), protected void componentHidded(), protected void componentOpened(), protected void componentClose(). The last two replaces deprecated protected void openNotify() and protected void closeNotify() methods. Two methods were added also to WindowManager to handle the notifiction via its subclasses: protected void componentShowing(TopComponent) and protected void componentHidden(TopComponent).

Add List TopComponent.availableModes(List modes) method

Apr 23 '02; API spec. version: 2.14; affected top-level classes: TopComponent; made by: dsimonek; issues: #20153
Method availableModes(...) added to TopComponent to allow TopComponent to specify where can be docked.

Add WindowManager.getDefault() method

Mar 21 '02; API spec. version: 2.10; affected top-level classes: WindowManager; made by: dsimonek; issues: #20942
Method WindowManager.getDefault() added to loose coupling between Topmanager and winsys. Old method TopManager.getWindowManager() was deprecated.

Add new DTD 1.1 for workspace configuration file

Jan 6 '02; made by: dsimonek; issues: #19072
Added element for maximized desktop in MDI mode.

Make a top component visible without focus change

Jul 27 '01; affected top-level classes: TopComponent WindowManager
Added method to make component visible without change of focus or frames z-order. If it is not possible to make component visible without change of focus it works in the same way as requestFocus(). New methods:

OK button in notify dialog can be turned off

Apr 11 '01; affected top-level classes: org.openide.NotifyDescriptor
Added methods isValid and setValid, added property name String constant PROP_VALID. It can be used to change validity (enable/disable) of standard OK button in dialog.

Open and close notification for top components

Mar 7 '01; affected top-level classes: TopComponent WindowManager
Added open and close notification for top components. New methods:

Wizard panels can refuse to go forward

Jan 15 '01; affected top-level classes: org.openide.WizardDescriptor
WizardDescriptor.Panel.readSettings can throw IllegalStateException. This can be used to indicate that data provided by the previous panels are not OK and that the panel wants the wizard to go back one panel.

Both Swing client properties and descriptor properties checked for wizard steps/image/help

Jan 9 '01; affected top-level classes: org.openide.WizardDescriptor
Added new functionality without API change. Wizard descriptor creates wizard panel with list of steps/image/help on the left depending on the properties supplied by ((JComponent)WizardDescriptor.current().getComponent()).putClientProperty() or WizardDescriptor.putProperty().

Several members of InputOutput removed

Jun 16 '00; affected top-level classes:
Several members of this interface were technically public before and are now deprecated: In fact they were meant to be package-private and were only public due to a quirk of Java's syntax (default modifier inside interfaces is public).
Compatibility: First broken, later re-added but deprecated in trunk and boston. Any code referring to these members is erroneous and must be rewritten. The only useful related member, the InputOutput.NULL constant, is still public and accessible.

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; 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:


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; 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; 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.


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.