站内搜索: 请输入搜索关键词
当前页面: 在线文档首页 > NetBeans API Javadoc 5.5.1

Change History for the File Systems API - NetBeans API Javadoc 5.5.1

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.

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

Changes by affected class

org.openide.actions.AbstractCompileAction

org.openide.filesystems.AbstractFileSystem

org.openide.actions.AddWatchAction

org.openide.cookies.ArgumentsCookie

org.openide.actions.BuildAction

org.openide.actions.BuildAllAction

org.openide.actions.BuildProjectAction

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.loaders.DataObjectFilter

org.openide.cookies.DebuggerCookie

org.openide.actions.DebugProjectAction

org.openide.filesystems.DefaultAttributes

org.openide.DialogDisplayer

org.openide.explorer.propertysheet.editors.DirectoryOnlyEditor

org.openide.cookies.ElementCookie

org.openide.explorer.propertysheet.editors.ElementFormatEditor

org.openide.filesystems.EnvironmentNotSupportedException

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.filesystems.FileAttributeEvent

org.openide.explorer.propertysheet.editors.FileEditor

org.openide.filesystems.FileEvent

org.openide.filesystems.FileObject

org.openide.explorer.propertysheet.editors.FileOnlyEditor

org.openide.filesystems.FileRenameEvent

org.openide.filesystems.FileStateInvalidException

org.openide.filesystems.FileSystem

org.openide.filesystems.FileSystemCapability

org.openide.filesystems.FileUtil

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.windows.InputOutput

org.openide.windows.IOProvider

org.openide.filesystems.JarFileSystem

org.openide.LifecycleManager

org.openide.filesystems.LocalFileSystem

org.openide.modules.ManifestSection

org.openide.explorer.propertysheet.editors.MethodParameterArrayEditor

org.openide.filesystems.MIMEResolver

org.openide.explorer.propertysheet.editors.ModifierEditor

org.openide.modules.ModuleDescription

org.openide.filesystems.MultiFileSystem

org.openide.nodes.NodeOperation

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.filesystems.Repository

org.openide.filesystems.RepositoryAdapter

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

org.openide.filesystems.URLMapper

org.openide.filesystems.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 MIMEResolvers 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: The previous semantics of Repository is broken. Replacement:

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

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

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.

FileEvents 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 nulls.

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

Also in JarFileSystem only:

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.

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