Overview

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

- The `release41` branch was made on Apr 03 '05 for use in the NetBeans 4.1 release. Specification versions: 6.0 begins after this point.
- The `release40` branch was made on Nov 01 '04 for use in the NetBeans 4.0 release. Specification versions: 5.0 begins after this point.

# Index of APIs

- Filesystems API
- Uncategorized changes

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

- (Oct 25 '05) The way how `IllegalArgumentException` is thrown from `FileUtil.toFileObject` was changed
- (Jul 21 '05) Removed most static MIME type mappings
- (Jun 1 '04) Almost all methods of Repository were deprecated.
- (May 7 '04) `FileObject.setImportant` deprecated
- (May 7 '04) Deprecation of various Filesystems API methods and classes
- (May 7 '04) `FileObject.toString()` not to be used for specific purposes
- (Nov 1 '02) API separation, phase II
- (Oct 15 '02) API separation, phase I
- (Aug 30 '02) `FileObject.getPath()` returns full resource path of file object
- (Jun 6 '02) URL -> FileObject mapping implementation
- (Aug 24 '01) FileAttributeEvent's methods getName (), getOldValue (), getNewValue () can return null
- (Jul 24 '01) Mounting new filesystem no longer works with filesystems providing `WizardDescriptor` as bean customizers
- (Jan 8 '01) `Repository` is not a cookie
- (Mar 27 '00) Filesystem implementation methods protected not public

# All changes by date

- (Oct 25 '05) The way how `IllegalArgumentException` is thrown from `FileUtil.toFileObject` was changed
- (Jul 21 '05) Removed most static MIME type mappings
- (Jan 7 '05) `FileObject.getFileObject` made not final.
- (Aug 4 '04) Added new method `FileUtil.createMemoryFileSystem ()`
- (Jul 30 '04) Added `FileUtil.preventFileChooserSymlinkTraversal(...)`
- (Jun 9 '04) Added FileUtil.getFileDisplayName
- (Jun 1 '04) Almost all methods of Repository were deprecated.
- (May 28 '04) Reused DefaultAttributes can use different name than .nbattrs
- (May 7 '04) Easier to work with ZIP/JAR archives
- (May 7 '04) `FileUtil.normalizeFile` added
- (May 7 '04) `FileObject.setImportant` deprecated
- (May 7 '04) Deprecation of various Filesystems API methods and classes
- (May 7 '04) `FileObject.toString()` not to be used for specific purposes
- (Apr 13 '04) There should exist just one FileObject for one resource (java.io.File or URL).
- (Dec 9 '03) Added API for finding file relatively to another file
- (Jan 10 '03) Method FileObject.isReadOnly was deprecated and replaced with methods canRead, canWrite
- (Jan 8 '03) URLMapper.findFileObjects returns empty array if not successful.
- (Nov 1 '02) API separation, phase II
- (Oct 22 '02) Added FileUtil.isParentOf
- (Oct 15 '02) API separation, phase I
- (Oct 1 '02) Changed javadoc to warn about improper use of methods
- (Aug 30 '02) `FileObject.getPath()` returns full resource path of file object
- (Jul 22 '02) Repository is not final
- (Jun 6 '02) URL -> FileObject mapping implementation
- (Apr 25 '02) Added support for better FileObject-URL mapping
- (Apr 24 '02) There exists possibility to refresh whole filesystem in one
- (Mar 11 '02) FileSystem provides FileChangeListener functionality
- (Mar 11 '02) Repository provides FileChangeListener functionality
- (Jan 17 '02) New property FileSystem.PROP_DISPLAY_NAME was added
- (Sep 21 '01) `FileEvent`s fired inside atomic actions can report from which atomic actions they were fired
- (Aug 30 '01) Method createWritableOnForRename in MultiFileSystem was added
- (Aug 24 '01) FileAttributeEvent's methods getName (), getOldValue (), getNewValue () can return null
- (Aug 17 '01) Discover which filesystem a FileStateInvalidException is associated with
- (Jul 31 '01) Find a disk file from a file object or vice-versa
- (Jul 24 '01) Mounting new filesystem no longer works with filesystems providing `WizardDescriptor` as bean customizers
- (Jun 27 '01) Create file object without extension
- (Jun 25 '01) Simplified file object deletion
- (Jun 1 '01) Can mark files as being virtual
- (Jun 1 '01) Can mark files as being important
- (Jun 1 '01) Test if a file object is virtual
- (Feb 7 '01) Get default `Repository` from within Filesystems API
- (Feb 5 '01) Find a MIME type for a file object using resolvers
- (Feb 5 '01) Added `MIMEResolver`
- (Jan 29 '01) Create expected file events
- (Jan 8 '01) `Repository` is not a cookie
- (Dec 6 '00) `MultiFileSystem` finds actions on a set of files specially
- (Nov 23 '00) Propagate masks flag for multi-filesystems
- (Nov 1 '00) Added `XMLFileSystem`
- (Sep 11 '00) MIME lookup by extension made friendlier for C/C++
- (Aug 22 '00) Customizable references to known file objects
- (Aug 22 '00) Find references to file objects by name
- (Aug 10 '00) Find known file objects starting from some point in the tree
- (Jun 25 '00) `RepositoryAdapter` added
- (Mar 27 '00) Filesystem implementation methods protected not public
- (Feb 24 '00) `AbstractFileSystem.refreshRoot` was of the wrong type

# 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: $codebase > 1.20

- (6.3) The way how `IllegalArgumentException` is thrown from `FileUtil.toFileObject` was changed
- (6.2) Removed most static MIME type mappings
- (5.3) `FileObject.getFileObject` made not final.
- (4.48) Easier to work with ZIP/JAR archives
- (4.48) `FileUtil.normalizeFile` added
- (4.48) `FileObject.setImportant` deprecated
- (4.48) Deprecation of various Filesystems API methods and classes
- (4.48) `FileObject.toString()` not to be used for specific purposes
- (4.43) Added new method `FileUtil.createMemoryFileSystem ()`
- (4.42) Added `FileUtil.preventFileChooserSymlinkTraversal(...)`
- (4.39) Added FileUtil.getFileDisplayName
- (4.36) Almost all methods of Repository were deprecated.
- (4.35) Reused DefaultAttributes can use different name than .nbattrs
- (4.29) There should exist just one FileObject for one resource (java.io.File or URL).
- (4.16) Added API for finding file relatively to another file
- (3.31) Method FileObject.isReadOnly was deprecated and replaced with methods canRead, canWrite
- (3.28) URLMapper.findFileObjects returns empty array if not successful.
- (3.17) API separation, phase II
- (3.16) Added FileUtil.isParentOf
- (3.14) API separation, phase I
- (3.7) `FileObject.getPath()` returns full resource path of file object
- (3.3) Repository is not final
- (2.22) URL -> FileObject mapping implementation
- (2.16) Added support for better FileObject-URL mapping
- (2.16) There exists possibility to refresh whole filesystem in one
- (2.8) FileSystem provides FileChangeListener functionality
- (2.8) Repository provides FileChangeListener functionality
- (2.1) New property FileSystem.PROP_DISPLAY_NAME was added
- (1.35) `FileEvent`s fired inside atomic actions can report from which atomic actions they were fired
- (1.34) Method createWritableOnForRename in MultiFileSystem was added
- (1.33) FileAttributeEvent's methods getName (), getOldValue (), getNewValue () can return null
- (1.30) Discover which filesystem a FileStateInvalidException is associated with
- (1.29) Find a disk file from a file object or vice-versa
- (1.17) Create file object without extension
- (1.15) Simplified file object deletion

# Changes by affected class

## `org.openide.actions.AbstractCompileAction`

- (Nov 1 '02) API separation, phase II

## `org.openide.filesystems.AbstractFileSystem`

- (Jan 10 '03) Method FileObject.isReadOnly was deprecated and replaced with methods canRead, canWrite
- (Jun 1 '01) Can mark files as being virtual
- (Jun 1 '01) Can mark files as being important
- (Aug 22 '00) Customizable references to known file objects
- (Aug 22 '00) Find references to file objects by name
- (Aug 10 '00) Find known file objects starting from some point in the tree
- (Feb 24 '00) `AbstractFileSystem.refreshRoot` was of the wrong type

## `org.openide.actions.AddWatchAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.cookies.ArgumentsCookie`

- (Nov 1 '02) API separation, phase II

## `org.openide.actions.BuildAction`

- (Nov 1 '02) API separation, phase II

## `org.openide.actions.BuildAllAction`

- (Nov 1 '02) API separation, phase II

## `org.openide.actions.BuildProjectAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.ChoicePropertyEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.CleanAction`

- (Nov 1 '02) API separation, phase II

## `org.openide.actions.CleanAllAction`

- (Nov 1 '02) API separation, phase II

## `org.openide.actions.CompileAction`

- (Nov 1 '02) API separation, phase II

## `org.openide.actions.CompileAllAction`

- (Nov 1 '02) API separation, phase II

## `org.openide.actions.CompileProjectAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.cookies.CompilerCookie`

- (Nov 1 '02) API separation, phase II

## `org.openide.loaders.CompilerSupport`

- (Nov 1 '02) API separation, phase II

## `org.openide.options.ControlPanel`

- (Oct 15 '02) API separation, phase I

## `org.openide.loaders.DataObjectFilter`

- (Oct 15 '02) API separation, phase I

## `org.openide.cookies.DebuggerCookie`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.DebugProjectAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.DefaultAttributes`

- (May 28 '04) Reused DefaultAttributes can use different name than .nbattrs

## `org.openide.DialogDisplayer`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.DirectoryOnlyEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.cookies.ElementCookie`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.ElementFormatEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.EnvironmentNotSupportedException`

- (May 7 '04) Deprecation of various Filesystems API methods and classes

## `org.openide.cookies.ExecCookie`

- (Nov 1 '02) API separation, phase II

## `org.openide.loaders.ExecSupport`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.ExecuteAction`

- (Nov 1 '02) API separation, phase II

## `org.openide.actions.ExecuteProjectAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.loaders.ExecutionSupport`

- (Nov 1 '02) API separation, phase II
- (Oct 15 '02) API separation, phase I

## `org.openide.loaders.ExtensionListEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.ExternalCompiler`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.FileAttributeEvent`

- (Aug 24 '01) FileAttributeEvent's methods getName (), getOldValue (), getNewValue () can return null
- (Jan 29 '01) Create expected file events

## `org.openide.explorer.propertysheet.editors.FileEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.FileEvent`

- (Sep 21 '01) `FileEvent`s fired inside atomic actions can report from which atomic actions they were fired
- (Jan 29 '01) Create expected file events

## `org.openide.filesystems.FileObject`

- (Jan 7 '05) `FileObject.getFileObject` made not final.
- (May 7 '04) `FileObject.setImportant` deprecated
- (May 7 '04) Deprecation of various Filesystems API methods and classes
- (May 7 '04) `FileObject.toString()` not to be used for specific purposes
- (Dec 9 '03) Added API for finding file relatively to another file
- (Jan 10 '03) Method FileObject.isReadOnly was deprecated and replaced with methods canRead, canWrite
- (Oct 1 '02) Changed javadoc to warn about improper use of methods
- (Aug 30 '02) `FileObject.getPath()` returns full resource path of file object
- (Jun 27 '01) Create file object without extension
- (Jun 25 '01) Simplified file object deletion
- (Jun 1 '01) Test if a file object is virtual

## `org.openide.explorer.propertysheet.editors.FileOnlyEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.FileRenameEvent`

- (Jan 29 '01) Create expected file events

## `org.openide.filesystems.FileStateInvalidException`

- (Aug 17 '01) Discover which filesystem a FileStateInvalidException is associated with

## `org.openide.filesystems.FileSystem`

- (May 7 '04) Deprecation of various Filesystems API methods and classes
- (Apr 24 '02) There exists possibility to refresh whole filesystem in one
- (Mar 11 '02) FileSystem provides FileChangeListener functionality
- (Jan 17 '02) New property FileSystem.PROP_DISPLAY_NAME was added

## `org.openide.filesystems.FileSystemCapability`

- (May 7 '04) Deprecation of various Filesystems API methods and classes

## `org.openide.filesystems.FileUtil`

- (Oct 25 '05) The way how `IllegalArgumentException` is thrown from `FileUtil.toFileObject` was changed
- (Jul 21 '05) Removed most static MIME type mappings
- (Aug 4 '04) Added new method `FileUtil.createMemoryFileSystem ()`
- (Jul 30 '04) Added `FileUtil.preventFileChooserSymlinkTraversal(...)`
- (Jun 9 '04) Added FileUtil.getFileDisplayName
- (May 7 '04) Easier to work with ZIP/JAR archives
- (May 7 '04) `FileUtil.normalizeFile` added
- (Apr 13 '04) There should exist just one FileObject for one resource (java.io.File or URL).
- (Dec 9 '03) Added API for finding file relatively to another file
- (Nov 1 '02) API separation, phase II
- (Oct 22 '02) Added FileUtil.isParentOf
- (Jul 31 '01) Find a disk file from a file object or vice-versa
- (Feb 5 '01) Find a MIME type for a file object using resolvers
- (Sep 11 '00) MIME lookup by extension made friendlier for C/C++

## `org.openide.actions.FinishDebuggerAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.GoAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.GoToCursorAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.HelpAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.awt.HtmlBrowser`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.IconEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.IdentifierArrayEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.modules.IllegalModuleException`

- (Oct 15 '02) API separation, phase I

## `org.openide.windows.InputOutput`

- (Nov 1 '02) API separation, phase II

## `org.openide.windows.IOProvider`

- (Nov 1 '02) API separation, phase II
- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.JarFileSystem`

- (Mar 27 '00) Filesystem implementation methods protected not public

## `org.openide.LifecycleManager`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.LocalFileSystem`

- (Mar 27 '00) Filesystem implementation methods protected not public

## `org.openide.modules.ManifestSection`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.MethodParameterArrayEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.MIMEResolver`

- (Feb 5 '01) Added `MIMEResolver`

## `org.openide.explorer.propertysheet.editors.ModifierEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.modules.ModuleDescription`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.MultiFileSystem`

- (Aug 30 '01) Method createWritableOnForRename in MultiFileSystem was added
- (Dec 6 '00) `MultiFileSystem` finds actions on a set of files specially
- (Nov 23 '00) Propagate masks flag for multi-filesystems

## `org.openide.nodes.NodeOperation`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.OpenProjectAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.windows.OutputEvent`

- (Nov 1 '02) API separation, phase II

## `org.openide.windows.OutputListener`

- (Nov 1 '02) API separation, phase II

## `org.openide.windows.OutputWriter`

- (Nov 1 '02) API separation, phase II

## `org.openide.Places`

- (Oct 15 '02) API separation, phase I

## `org.openide.cookies.ProjectCookie`

- (Oct 15 '02) API separation, phase I

## `org.openide.util.actions.ProjectSensitiveAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.Repository`

- (Jun 1 '04) Almost all methods of Repository were deprecated.
- (Jul 22 '02) Repository is not final
- (Mar 11 '02) Repository provides FileChangeListener functionality
- (Feb 7 '01) Get default `Repository` from within Filesystems API
- (Jan 8 '01) `Repository` is not a cookie

## `org.openide.filesystems.RepositoryAdapter`

- (Jun 25 '00) `RepositoryAdapter` added

## `org.openide.loaders.RepositoryNodeFactory`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.SaveProjectAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.cookies.SourceCookie`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.StartDebuggerAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.awt.StatusDisplayer`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.StepOutAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.StringArrayCustomEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.StringArrayCustomizable`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.StringArrayEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.ToggleBreakpointAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.TopManager`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.TraceIntoAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.actions.TraceOverAction`

- (Oct 15 '02) API separation, phase I

## `org.openide.explorer.propertysheet.editors.TypeEditor`

- (Oct 15 '02) API separation, phase I

## `org.openide.filesystems.URLMapper`

- (Apr 13 '04) There should exist just one FileObject for one resource (java.io.File or URL).
- (Jan 8 '03) URLMapper.findFileObjects returns empty array if not successful.
- (Jun 6 '02) URL -> FileObject mapping implementation
- (Apr 25 '02) Added support for better FileObject-URL mapping

## `org.openide.filesystems.XMLFileSystem`

- (Nov 1 '00) Added `XMLFileSystem`

# Details of all changes by API and date

## Filesystems API

### The way how `IllegalArgumentException` is thrown from `FileUtil.toFileObject` was changed

Oct 25 '05; API spec. version: 6.3; affected top-level classes: `FileUtil`; made by: rmatous

Because of performance reason piece of code checking whether file was properly normalized is called conditionally just in case that assertions are enabled. Then `IllegalArgumentException` can't be thrown if assertions are disabled.

### Removed most static MIME type mappings

Jul 21 '05; API spec. version: 6.2; affected top-level classes: `FileUtil`; made by: jglick

Previously, a number of file extensions were given hardcoded MIME types in the Filesystems API library (unless overridden by `MIMEResolver`s or `FileSystem` implementations). Most of these static mappings have been removed. The affected mappings were:

Extension | MIME type
`au` | `audio/basic`
`class` | `application/octet-stream`
`css` | `text/css`
`dtd` | `text/x-dtd`
`exe` | `application/octet-stream`
`htm` | `text/html`
`html` | `text/html`
`jar` | `application/x-jar`
`java` | `text/x-java`
`jsp` | `text/plain`
`mov` | `video/quicktime`
`pl` | `text/plain`
`properties` | `text/plain`
`ps` | `application/postscript`
`ra` | `audio/x-pn-realaudio`
`ram` | `audio/x-pn-realaudio`
`rm` | `audio/x-pn-realaudio`
`rpm` | `audio/x-pn-realaudio`
`sh` | `application/x-shar`
`snd` | `audio/basic`
`tar` | `application/x-tar`
`text` | `text/plain`
`txt` | `text/plain`
`uu` | `application/octet-stream`
`wav` | `audio/x-wav`
`xsd` | `text/xml`
`xsl` | `text/xml`
`zip` | `application/zip`

The mapping from `*.xml` to `text/xml` is retained as this may be central to processing of XML configuration files on the system file system.

Compatibility:

Clients which were relying on the existence of some of the former mappings may be broken. (Of course such clients were in violation of the API anyway, since these mappings were never documented or guaranteed.) For such cases, either avoid relying on MIME type, or add your own `MIMEResolver` giving the mapping you want.

### `FileObject.getFileObject` made not final.

Jan 7 '05; API spec. version: 5.3; affected top-level classes: `FileObject`; made by: rmatous; issues: #51551

Method `public final FileObject getFileObject (String relativePath)` in class `FileObject` isn't final anymore to let more freedom for implemetations.

### Added new method `FileUtil.createMemoryFileSystem ()`

Aug 4 '04; API spec. version: 4.43; affected top-level classes: `FileUtil`; made by: jtulach; issues: #46701

There is a new factory method `FileUtil.createMemoryFileSystem ()` to create an empty, writeable instance of a `FileSystem` with content completely stored in memory. This filesystem is the one that is by default returned from `Repository.getDefaultFileSystem()` so since now the standalone applications may expect the default file system to be writable.

### Added `FileUtil.preventFileChooserSymlinkTraversal(...)`

Jul 30 '04; API spec. version: 4.42; affected top-level classes: `FileUtil`; made by: jglick; issues: #46459
Added a new method `FileUtil.preventFileChooserSymlinkTraversal(...)` to help work around problems with symbolic links and `JFileChooser`.

### Added FileUtil.getFileDisplayName

Jun 9 '04; API spec. version: 4.39; affected top-level classes: `FileUtil`; made by: rmatous; issues: #37549
Get an appropriate display name for a file object. If the file corresponds to a path on disk, this will be the disk path. Otherwise the name will mention the filesystem name or archiv name in case the file comes from archiv and relative path. Relative path will be mentioned just in case that passed `FileObject` isn't root.

### Almost all methods of Repository were deprecated.

Jun 1 '04; API spec. version: 4.36; affected top-level classes: `Repository`; made by: rmatous; issues: #42273
All methods were deprecated except:

- `getDefault ()`
- `getDefaultFileSystem ()`

The previous semantics of Repository is broken. Replacement:

- ClassPath API
- `URLMapper` for providing `FileObjects`

### Reused DefaultAttributes can use different name than .nbattrs

May 28 '04; API spec. version: 4.35; affected top-level classes: `DefaultAttributes`; made by: rmatous; issues: #43180
Added new constructor to DefaultAttributes that takes file name as next additional parameter.

### Easier to work with ZIP/JAR archives

May 7 '04; API spec. version: 4.48; affected top-level classes: `FileUtil`; made by: jglick

There are now various methods in `FileUtil` that let you easily convert between archive files themselves and their entries. It is no longer necessary (or advisable) to explicitly construct `JarFileSystem`s to work with archives. A standard `URLMapper` implementation is present which handles `jar`-protocol URLs correctly.

### `FileUtil.normalizeFile` added

May 7 '04; API spec. version: 4.48; affected top-level classes: `FileUtil`; made by: jglick; issues: #40410

The method `FileUtil.normalizeFile(File)` was added as a refinement of `File.getCanonicalFile` that does not traverse symlinks on Unix. Used throughout the NetBeans 4.0 project system.

### `FileObject.setImportant` deprecated

May 7 '04; API spec. version: 4.48; affected top-level classes: `FileObject`; made by: jglick

In NetBeans 3.x, normally “compilation” or similar build steps would produce generated files kept in the user’s development folder alongside source files, and picked up as secondary files by a `MultiFileLoader`. To ensure that the VCS integration did not offer to version such files, `FileObject.setImportant` could be used to mark them as disposable.

In NetBeans 4.0, such disposable files should not be placed in a source folder. They should always be built to a separate build directory, typically defined by the containing project. In this case marking an individual file as unimportant is unnecessary, since the entire build tree is known to be disposable. Instead, the project (not data loaders) can use `SharabilityQueryImplementation` to indicate which subtrees contain build products.

Compatibility:

There is no direct replacement. Code using this method should be reëvaluated in the light of other changes in NetBeans 4.0.

### Deprecation of various Filesystems API methods and classes

May 7 '04; API spec. version: 4.48; affected top-level classes: `EnvironmentNotSupportedException` `FileObject` `FileSystem` `FileSystemCapability`; made by: jglick

Various parts of the Filesystems API which are no longer useful in NetBeans 4.0 were deprecated. The assumptions which are now invalid were:

- The root of a filesystem corresponds to a Java classpath root (if the appropriate capabilities were set). Now handled by the Classpath API.

- The user explicitly mounts and unmounts filesystems, either to control the classpath, for version control purposes, or simply to access some area of the disk; and so filesystem metadata is relevant to the GUI. Now obsoleted by the Classpath API and MasterFS.

- The IDE internally managed a list of mounted filesystems. Now only the default system filesystem is “mounted”; MasterFS transparently manages all “user-space” files.

- File objects are persisted by saving a reference to the containing filesystem, plus the relative path within the filesystem. Now done using URLs.

Specific deprecations:

1. `FileSystem.Environment` and `EnvironmentNotSupportedException`
2. `FileSystemCapability` (and its constants and subclasses), `FileSystem.getCapability` and `setCapability`, constructors taking `FileSystemCapability`
3. `FileSystem.PROP_HIDDEN`, `isHidden`, and `setHidden`
4. `FileSystem.PROP_SYSTEM_NAME`, `getSystemName`, and `setSystemName`
5. `FileSystem.find`
6. `FileObject` methods such as `getPackageName`
7. `FileSystem.isPersistent`

See also deprecations in `Repository` .

Compatibility:

In general, attempts to call the old methods will yield well-defined but useless results in NetBeans 4.0.

### `FileObject.toString()` not to be used for specific purposes

May 7 '04; API spec. version: 4.48; affected top-level classes: `FileObject`; made by: jglick; issues: #27640

`FileObject.toString()` no longer returns a predictable value; in particular, it will not be the same as `getPath()`. The new value is suitable for logging and debugging but otherwise cannot be relied upon.

There are two benefits to this change:

1. The new `toString()` is more useful for logging than the previous value. It is no longer necessary to separately include `fileObject.getFileSystem().toString()`, which was cumbersome (and required an extra catch clause).

2. Clients which were incorrectly using `toString()` to get a Java resource path will now be predictably broken, so they can be fixed to use `ClassPath`. (The paths would not have been usable in NetBeans 4.0 anyway.) Just deprecating `toString()` was not possible because it overrides a nondeprecated `Object` method, and is also inserted into code by the compiler without emitting any deprecation warning.

Compatibility:

Older Filesystems API clients which assumed that `FileObject.toString()` and `FileObject.getPath()` do the same thing will be broken.

### There should exist just one FileObject for one resource (java.io.File or URL).

Apr 13 '04; API spec. version: 4.29; affected top-level classes: `FileUtil` `URLMapper`; made by: rmatous; issues: #41506

- Added method FileUtil.toFileObject as replacement for current method FileUtil.fromFile which was deprecated.
- Added method URLMapper.findFileObject as replacement for current method URLMapper.findFileObjects which was deprecated .

### Added API for finding file relatively to another file

Dec 9 '03; API spec. version: 4.16; affected top-level classes: `FileUtil` `FileObject`; made by: rmatous; issues: #37445

- Added method FileUtil.getRelativePath which gets a relative resource path between folder and fo in folder's tree.
- Slightly modified semantic of FileObject.getFileObject in compatible way. This method retrieves file or folder relative to a current folder, with a given relative path.

### Method FileObject.isReadOnly was deprecated and replaced with methods canRead, canWrite

Jan 10 '03; API spec. version: 3.31; affected top-level classes: `FileObject` `AbstractFileSystem`; made by: rmatous
There was made changes in FileObject class. Added method: `public boolean canRead ()`. Method `public boolean isReadOnly ()` was deprecated and replaced with method: `public boolean canWrite ()`. This change can be considered as compatible. Newly added methods have default implementation. Also AbstractFileSystem was modified and two necessary method were added: method: `public boolean canRead ()` and method: `public boolean canWrite ()`.

### URLMapper.findFileObjects returns empty array if not successful.

Jan 8 '03; API spec. version: 3.28; affected top-level classes: `URLMapper`; made by: rmatous; issues: #28312
`URLMapper.findFileObjects` returns empty array if not successful. As far there was in documentation written, that null is returned.

### Added FileUtil.isParentOf

Oct 22 '02; API spec. version: 3.16; affected top-level classes: `FileUtil`; made by: vstejskal
FileUtil.isParentOf provides simple recursive check whether the FileObject is underneath some folder.

### Changed javadoc to warn about improper use of methods

Oct 1 '02; affected top-level classes: `FileObject`; made by: pzavadsky; issues: #27640 #27687
Changed Javadoc to warn about improper usage of the `FileObject.toString` (it was used as full path format), which is replaced by `FileObject.getPath` now. Explained correct purpose of that method. Also added those warnings to `findResource` and `findAllResource` of `Repository` class.

### `FileObject.getPath()` returns full resource path of file object

Aug 30 '02; API spec. version: 3.7; affected top-level classes: `FileObject`; made by: jglick; issues: #26904
It is commonly necessary to find the full resource path of a file object within its filesystem. Formerly you could do this the safe way by calling `getPackageNameExt('/', '.')`, but this is clumsy to write, potentially inefficient, and is prone to misinterpretation in the case of files without any extension (or files ending in a period, or folders with extensions). Calling `toString()` was more effective, but this suffered from the problem that for compatibility reasons, no assurance could be made that it would actually give a resource path - an old `FileObject` implementation could implement it in any way, since it was not originally documented what it should return. Therefore, the new method `getPath()` has been introduced.
Compatibility: Existing `FileObject` implementations ought to override the new method for efficiency. They should also cease to override `toString`. Subclasses of `AbstractFileSystem` (the normal case) need not be concerned, since the corresponding `FileObject` already implements this method correctly. Code assuming `toString` returns a resource path should be changed to use `getPath` instead.
Binary-compatible

### Repository is not final

Jul 22 '02; API spec. version: 3.3; affected top-level classes: `Repository`; made by: jtulach
Repository is not final anymore, so there can be subclasses of it. But all its methods has been made final. This was done in order to create Repositories that will follow the javabeans pattern (have public default constructor).

### URL -> FileObject mapping implementation

Jun 6 '02; API spec. version: 2.22; affected top-level classes: `URLMapper`; made by: rmatous
Two methods were added `public static FileObject[] findFileObjects (URL url)` and `public abstract FileObject[] getFileObjects (URL url)`.
Compatibility: Added abstract method `public abstract FileObject[] getFileObjects (URL url)` But there doesn`t exists any known subclass of URLMapper yet. And URLMapper was introduced recently 2.16 in 3.4 release.

### Added support for better FileObject-URL mapping

Apr 25 '02; API spec. version: 2.16; affected top-level classes: `URLMapper`; made by: rmatous
Added new class `URLMapper`. This class provides basic mapping for FileObjects from LocalFileSystem, JarFileSystem and MultiFileSystem and is intended as superclass for individual mappers.

### There exists possibility to refresh whole filesystem in one

Apr 24 '02; API spec. version: 2.16; affected top-level classes: `FileSystem`; made by: rmatous
Method: `public void FileSystem.refresh (boolean expected))` was added.

### FileSystem provides FileChangeListener functionality

Mar 11 '02; API spec. version: 2.8; affected top-level classes: `FileSystem`; made by: rmatous
Method: `public final void addFileChangeListener(FileChangeListener fcl)` and `public final void removeFileChangeListener(FileChangeListener fcl)` was added to maintain FileChangeListeners that should be notified if some change in FileSystem occures.

### Repository provides FileChangeListener functionality

Mar 11 '02; API spec. version: 2.8; affected top-level classes: `Repository`; made by: rmatous
Method: `public final void addFileChangeListener(FileChangeListener fcl)` and `public final void removeFileChangeListener(FileChangeListener fcl)` was added to maintain FileChangeListeners that should be notified if some change in Repository occures.

### New property FileSystem.PROP_DISPLAY_NAME was added

Jan 17 '02; API spec. version: 2.1; affected top-level classes: `FileSystem`; made by: rmatous
`FileSystem.PROP_DISPLAY_NAME` added to notify a change in the display name.

### `FileEvent`s fired inside atomic actions can report from which atomic actions they were fired

Sep 21 '01; API spec. version: 1.35; affected top-level classes: `FileEvent`; made by: rmatous
Method `boolean FileEvent.firedFrom(FileSystem.AtomicAction run)` returns true if this `FileEvent` was fired from `run`.

### Method createWritableOnForRename in MultiFileSystem was added

Aug 30 '01; API spec. version: 1.34; affected top-level classes: `MultiFileSystem`; made by: rmatous
Protected method `createWritableOnForRename` in `MultiFileSystem` was added. This method has the same meaning as `createWritableOn` but have two parameters: oldName, newName. This method is called from `MultiFileObject.rename`.

### FileAttributeEvent's methods getName (), getOldValue (), getNewValue () can return null

Aug 24 '01; API spec. version: 1.33; affected top-level classes: `FileAttributeEvent`; made by: rmatous
`FileAttributeEvent`'s methods `getName ()`, `getOldValue ()`, `getNewValue ()` can return `null`. If `getName ()` returns null then this means that one of attributes were changed. If `getName ()` returns `null` then there is supposed that all `FileAttributeEvent` fields will return `null` also.
Compatibility: Code previously assuming that all `FileAttributeEvent` fields were non-null may now be broken, and should check for `null`s.

### Discover which filesystem a FileStateInvalidException is associated with

Aug 17 '01; API spec. version: 1.30; affected top-level classes: `FileStateInvalidException`; made by: mschilling
Added method `public String getFileSystemName()`. This will return the name of the filesystem containing the file with invalid state if such information is available.

### Find a disk file from a file object or vice-versa

Jul 31 '01; API spec. version: 1.29; affected top-level classes: `FileUtil`; made by: rmatous
Added method `public File toFile(FileObject)`. Finds appropriate `java.io.File` to `FileObject` if possible. If not possible then `null` is returned. Also added method `public FileObject[] fromFile(File)`. Finds appropriate `FileObject`s to `java.io.File` if possible. If not possible then empty array is returned. More than one `FileObject` may correspond to one `java.io.File` so an array is returned.

### Mounting new filesystem no longer works with filesystems providing `WizardDescriptor` as bean customizers

Jul 24 '01; made by: jtulach

It used to be the case (NB 3.2) that a FileSystem implementation could in its BeanInfo specify a BeanDescriptor whose Customizer class extended WizardDescriptor. This would cause the wizard to be opened when the user tried to mount that filesystem type.

The situation now (from 3.3) is that this no longer opens the customizer and property sheet is presented in the second step of the mount wizard.

Compatibility: WizardDescriptor as bean customizer no longer opens the wizard while mounting. To achieve this use of a special iterator in Templates/Mount/ is now used (for modules 3.3+).

### Create file object without extension

Jun 27 '01; API spec. version: 1.17; affected top-level classes: `FileObject`; made by: rmatous
Added convenience method `public FileObject createData(String name) throws IOException`. Creates new data file in this folder with the specified name. Plainly calls `createData(name,"")`.

### Simplified file object deletion

Jun 25 '01; API spec. version: 1.15; affected top-level classes: `FileObject`
Added method `public final void delete()`. `FileObject` is locked before delete and finally this lock is released.

### Can mark files as being virtual

Jun 1 '01; affected top-level classes: `AbstractFileSystem`
Added new protected method `protected boolean checkVirtual(String name)`.Tests if file really exists or is missing. Some operation on it may be restricted if returns true.

### Can mark files as being important

Jun 1 '01; affected top-level classes: `AbstractFileSystem`
Added new protected method `protected void markImportant(String name, boolean important)`. Mark the file as being important or unimportant.

### Test if a file object is virtual

Jun 1 '01; affected top-level classes: `FileObject`
Added new method `public isVirtual`. Tests if file really exists or is missing. Some operation on it may be restricted. Return value true indicates that the file is missing.

### Get default `Repository` from within Filesystems API

Feb 7 '01; affected top-level classes: `Repository`
Added method `Repository.getDefault()` that allows standalone tools (using just filesystems library) without access to `TopManager` to get the default repository of the system.

### Find a MIME type for a file object using resolvers

Feb 5 '01; affected top-level classes: `FileUtil`
Added new public method `getMIMEType(FileObject)`. Resolves MIME type. Registered resolvers are invoked and used to achieve this goal. Resolvers must subclass `MIMEResolver` . If resolvers do not recognize MIME type then MIME type is obtained for a well-known extension.

### Added `MIMEResolver`

Feb 5 '01; affected top-level classes: `MIMEResolver`; made by: rmatous
Added new `MIMEResolver`. This class is intended as superclass for individual resolvers.

### Create expected file events

Jan 29 '01; affected top-level classes: `FileEvent` `FileAttributeEvent` `FileRenameEvent`
`FileEvent` and subclass constructors may take a parameter `boolean expected`.

### `Repository` is not a cookie

Jan 8 '01; affected top-level classes: `Repository`; made by: jtulach
`Repository` has been changed not to implement the `Node.Cookie` interface. The reason for such change is that this was the only place where filesystems package depended on another part in the IDE.
Compatibility: Code that used `Repository` as cookie should be changed to:

                        ic = (InstanceCookie)node.getCookie(InstanceCookie.class);
                        if (ic != null && Repository.class.isAssignableFrom(ic.instanceCookie())) {
                        // do stuff
                        }

Binary-compatible

### `MultiFileSystem` finds actions on a set of files specially

Dec 6 '00; affected top-level classes: `MultiFileSystem`
Method: `getActions(final Set foSet)` was added, which should provide a Set of `FileObject`s to run the actions on. This method overloads default behavior of `FileSystem.getActions(final Set foSet)`.

### Propagate masks flag for multi-filesystems

Nov 23 '00; affected top-level classes: `MultiFileSystem`; made by: jglick
`setPropagateMasks` and `getPropagateMasks` added to make it easier to compose multi filesystems inside other multi filesystems.

### Added `XMLFileSystem`

Nov 1 '00; affected top-level classes: `XMLFileSystem`
Added new `XMLFileSystem` that reads content of special XML file and represents it as filesystem. This filesystem is used by modules to provide their own content of menus, toolbars, templates, component palette, etc.

### MIME lookup by extension made friendlier for C/C++

Sep 11 '00; affected top-level classes: `FileUtil`; made by: jglick
MIME types no longer include C/C++ extensions by default; and file extension lookups give preference to case-sensitive matches but also work with case-insensitive matches by default.

### Customizable references to known file objects

Aug 22 '00; affected top-level classes: `AbstractFileSystem`
Added new protected method `Reference createReference(FileObject fo)`. This method returns `WeakReference` of `obj` (`new WeakReference (fo)`). If you subclass from `AbstractFileSystem`, you can overload this method to return another type of `Reference`.

### Find references to file objects by name

Aug 22 '00; affected top-level classes: `AbstractFileSystem`
Added new final protected method `Reference findReference(String resourceName)`. This method finds the reference associated with `resourceName`.

### Find known file objects starting from some point in the tree

Aug 10 '00; affected top-level classes: `AbstractFileSystem`
Added new protected method `existingFileObjects(FileObject)`. Can be used to find all `FileObject`s in this filesystem with the given predecessor.

### `RepositoryAdapter` added

Jun 25 '00; affected top-level classes: `RepositoryAdapter`; made by: jglick
Added to make it easier to use `RepositoryListener`.

### Filesystem implementation methods protected not public

Mar 27 '00; affected top-level classes: `LocalFileSystem` `JarFileSystem`; made by: jtulach

Many methods in `LocalFileSystem` and `JarFileSystem` were declared public though they should never have been called directly. (They were implementing interface methods that would only be called from within the class itself.) These methods are:

- `children(String)`
- `createData(String)`
- `createFolder(String)`
- `delete(String)`
- `folder(String)`
- `inputStream(String)`
- `lastModified(String)`
- `lock(String)`
- `markUnimportant(String)`
- `mimeType(String)`
- `outputStream(String)`
- `readOnly(String)`
- `rename(String,String)`
- `size(String)`
- `unlock(String)`

Also in `JarFileSystem` only:

- `readAttribute(String,String)`
- `writeAttribute(String,String,Object)`
- `attributes(String)`
- `renameAttributes(String,String)`
- `deleteAttributes(String)`

All these methods are now protected.

In general, outside code should use the proper outer API to access filesystems (`FileSystem` and `FileObject` and some helper classes), only directly calling methods of implementation classes where this is required (constructors or `setRootDirectory`). As a matter of style, it is recommended that calling code declare variables to be of the abstract type (e.g. `FileSystem`) to clarify that only generally available methods will be called.

Compatibility: First broken, later restored binary compatibility in trunk and `boston`. Any outside code calling them as public will break; however such code is definitely erroneous and should be rewritten.
Binary-compatible

### `AbstractFileSystem.refreshRoot` was of the wrong type

Feb 24 '00; affected top-level classes: `AbstractFileSystem`
`refreshRoot` now returns `FileObject` rather than the subclass `AbstractFileObject`. In fact the returned object currently is always an `AbstractFileObject` but this subclass is package-private so it was an API bug to mention it from an accessible method.
Compatibility: First broken, later restored binary compatibility in trunk and `boston`. The change should be source-code compatible, and is made to be binary compatible as well.

## 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` `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.

- 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 `BeanInfo`s 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 `BeanInfo`s 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.

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 December 7 2006. | Portions Copyright 1997-2005 Sun Microsystems, Inc. All rights reserved.