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

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.filesystems.annotations.LayerBuilder

org.openide.filesystems.annotations.LayerGeneratingProcessor

org.openide.filesystems.annotations.LayerGenerationException

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

Deprecating FileSystem.getActions

May 14 '14; API spec. version: 8.12; affected top-level classes: FileSystem AbstractFileSystem MultiFileSystem; made by: jtulach; issues: #243265

Deprecating getActions method in preparation of splitting filesystems API into UI (e.g. depending on Swing) and non-UI part (that can run on JDK8 compact profile). Introducing general replacement findExtrasFor instead...

Allowed to reveal deleted files, or original files overriden by writable layer

Nov 23 '12; API spec. version: 8.5; made by: sdedic

Files which have been deleted can be obtained by folder.getAttribute("revealEntries"). See MultiFileSystem javadoc for details

Warning: stability of this feature is development

New method FileChooserBuilder.setAcceptAllFileFilterUsed.

Oct 30 '12; API spec. version: 8.3; affected top-level classes: FileChooserBuilder; made by: tmysik; issues: #220401

Added new method to FileChooserBuilder that determines whether the AcceptAll FileFilter should be used in the created file chooser.

New method FileChooserBuilder.addDefaultFileFilters and accompanying annotations.

Aug 29 '12; API spec. version: 8.1; affected top-level classes: FileChooserBuilder MIMEResolver; made by: jhavlin; issues: #209998

Added new method to FileChooserBuilder that adds all default FileFilters to created file chooser.

Default filters are registered using new parameters in annotations MimeResolver.Registration and MimeResolver.ExtensionRegistration.

FileObject has getLookup()

Aug 22 '12; API spec. version: 8.0; affected top-level classes: FileObject; made by: jtulach; issues: #209231

FileObject now implements Lookup.Provider and thus has new getLookup() method.

addRecursiveListener with a filter

Apr 11 '12; API spec. version: 7.61; affected top-level classes: FileUtil; made by: jtulach; issues: #207189

Added new method variant to register recursive listener and control whether to recurse into a subtree or not via FileFilter.

File System can create temporary file

Feb 20 '12; API spec. version: 7.60; affected top-level classes: FileSystem; made by: alexvsimon; issues: #207659

Added methods to create temporary file objects: FileSystem.getTempFolder, FileSystem.createTempFile.

SPI for Additions to System File System

Feb 3 '12; API spec. version: 7.59; affected top-level classes: Repository; made by: jtulach; issues: #198508

Those who wish to influence content of configuration file system have an easier way now.

Annotations to declare MIME type

Feb 2 '12; API spec. version: 7.58; affected top-level classes: MIMEResolver; made by: jtulach; issues: #191777

There are new annotations to register mime type. One can either use simpler ones based on extension or XML namespace. In case these registration are not powerful enough one can use the original and flexible XML file based registration which is however processed during compile time to avoid needless XML parsing on each start.

Introduced FileObject.toURI

Jan 20 '12; API spec. version: 7.57; affected top-level classes: FileObject; made by: jglick; issues: #207294

Added FileObject.toURI for convenience.

Also deprecated FileObject.getURL in favor of toURL which is the same but does not throw FileStateInvalidException, and clarified that URLMapper.findURL(fo, INTERNAL) will never return null.


Compatibility:

FileObject.getURL should be replaced with toURL (or toURI), which also throw no checked exceptions.

Provides default line separator

Jan 13 '12; API spec. version: 7.56; affected top-level classes: FileObject; made by: alexvsimon; issues: #199534

FileObject.DEFAULT_LINE_SEPARATOR_ATTR defines file object attribute name to get default line separator. File object can provide default line separator if it differs from System.getProperty("line.separator"). Call fo.getAttribute(FileObject.DEFAULT_LINE_SEPARATOR_ATTR) returns string with default line separator. Default line separator will be used by the text editor if saving new content to an initially empty file. Any other code which creates file content programmatically must manually read this property if it cares.

Introduced FileObject.revert

Nov 29 '11; API spec. version: 7.55; affected top-level classes: FileObject; made by: jglick; issues: #162526

Added revert and canRevert to FileObject.


Compatibility:

The previous SPI has been kept. Only a more convenient API has been introduced, so it is no longer necessary for callers to look for a removeWritables attribute.

Detailed FileEvent constructor

Nov 22 '11; API spec. version: 7.54; affected top-level classes: FileEvent; made by: jtulach; issues: #203477

New FileEvent constructor allowing specification of expected state as well as time.

FileObject.getMIMEType(String... withinMIMETypes)

Aug 5 '11; API spec. version: 7.52; affected top-level classes: FileObject; made by: jtulach; issues: #199642

Introducing FileObject.getMIMEType(String...) that can be overriden by different implementations of file system API.

LayerBuilder can validate resources

Jul 25 '11; API spec. version: 7.51; affected top-level classes: LayerBuilder; made by: jglick; issues: #196452

LayerBuilder has a new validateResource method. absolutizeResource was also added.

LayerGenerationException has new constructors

Jul 25 '11; API spec. version: 7.50; affected top-level classes: LayerGenerationException LayerBuilder; made by: jglick; issues: #194545

LayerGenerationException has new constructors making it easier to specify the particular annotation responsible for a problem. Some methods in LayerBuilder have new overloads to take advantage of it.


Compatibility:

Code using the constructors not specifying an annotation should now do so.

FileUtil.getConfigObject

Jun 25 '11; API spec. version: 7.49; affected top-level classes: FileUtil; made by: jtulach; issues: #169338

One can convert files in SystemFileSystem to Object with a single utility method.

FileObject.getFileObject accepts ".."

Jan 27 '11; API spec. version: 7.45; affected top-level classes: FileObject; made by: jtulach; issues: #194418

Semantic of getFileObject method has been clarified to accept "..".

setAttribute("methodvalue:attrname", method) and "newvalue:"

Nov 24 '10; API spec. version: 7.43; affected top-level classes: FileUtil FileObject; made by: jtulach; issues: #120724

You can use prefix "methodvalue:" to setAttribute with type of Method. When the attribute is queried (without the prefix), the method is called as is common in XMLFileSystem attributes. You can also use newvalue: prefix for attribute of type Class.

XMLFileSystem's newvalue can create private instances

Oct 25 '10; API spec. version: 7.43; affected top-level classes: XMLFileSystem; made by: jtulach; issues: #141698

If the class referenced from newvalue XMLFileSystem attribute is not public, it is made accessible for reflection.

FileUtil.normalizePath added

Sep 30 '10; API spec. version: 7.42; affected top-level classes: FileUtil; made by: vv159170; issues: #190480

The method FileUtil.normalizePath(String) was added as a refinement of FileUtil.normalizeFile that does not require String to File to String conversion on client side when intention is to convert unnormalized path to normalized path presentation.

FileObject.createAndOpen

Sep 10 '10; API spec. version: 7.41; affected top-level classes: FileObject; made by: jtulach; issues: #40739

Create a file and write its content (almost) atomically using the new FileObject.createAndOpen method.

Ability to specify "weight" for MultiFileSystem overrides

Mar 1 '10; API spec. version: 7.36; affected top-level classes: MultiFileSystem; made by: jglick; issues: #141925

MultiFileSystems will now interpret a special file attribute weight to determine how to resolve otherwise ambiguous overrides. For example, in the system filesystem, module XML layers can use this attribute. Suppose a generic infrastructure module declares:

<filesystem>
    <folder name="my-snippets">
        <file name="common.xml" url="generic-snippet.xml"/>
    </folder>
</filesystem>
                

If another module wishes to override this declaration, it can do so by specifying:

<filesystem>
    <folder name="my-snippets">
        <file name="common.xml" url="special-snippet.xml">
            <attr name="weight" intvalue="100"/>
        </file>
    </folder>
</filesystem>
                

This override will work even if the module system happens to load the specializing module before the infrastructure module (as could happen if there is no module dependency between them). The weight attribute also makes it clear that something is being overridden.


Compatibility:

Modules need no longer declare runtime-only dependencies on other modules merely to override their layer entries. Instead, they should specify a higher weight. (Normally the base module will declare no weight, so any positive number will do.)

Interruptable addRecursiveListener

Feb 17 '10; API spec. version: 7.37; affected top-level classes: FileUtil; made by: jtulach; issues: #180523

New variant of addRecursiveListener method that allows the caller to control the process enumerating files in subtree and stop it.

Effective constructor for JarFileSystem

Jan 26 '10; API spec. version: 7.35; affected top-level classes: JarFileSystem; made by: jtulach; issues: #177461

New constructor for JarFileSystem that initializes everything without opening the underlaying JAR file.

Access methods added to MIMEResolver.UIHelpers

Jan 8 '10; API spec. version: 7.34; affected top-level classes: MIMEResolver; made by: jglick; issues: #179289

Several internal methods were added to nested class of MIMEResolver - UIHelpers for use from other parts of the NetBeans Platform. Use from other modules is not supported.

Support for recursive listeners

Sep 18 '09; API spec. version: 7.28; affected top-level classes: FileObject FileUtil; made by: jtulach; issues: #170862

One can register a recursive listener on a file object by calling FileObject.addRecursiveListener(FileChangeListener).

Non-initializing LayerBuilder.instanceFile added

Sep 14 '09; API spec. version: 7.27; affected top-level classes: LayerBuilder; made by: jglick; issues: #171284

New overload of instanceFile makes it easier to create instances for use with lazy factories.

LayerBuilder.folder added

Sep 10 '09; API spec. version: 7.26; affected top-level classes: LayerBuilder; made by: jglick; issues: #171029

Now possible to create empty folders from layer-generating processors.

System filesystem label/icon annotations work without full module system

Aug 31 '09; API spec. version: 7.25; affected top-level classes: FileSystem; made by: jglick; issues: #171092

For convenience from unit tests, the system filesystem will now always process annotations such as displayName in its FileSystem.Status.


Compatibility:

An application or unit test installing a custom system filesystem and not overriding getStatus but expecting the default implementation to do nothing could be broken.

Support for processing batch events

Aug 25 '09; API spec. version: 7.24; affected top-level classes: FileEvent; made by: jtulach; issues: #170544

FileEvent.runWhenDeliveryOver(Runnable) method added to support easier processing of batch sets of events.

Allow modules to provide fallback layer content

Aug 12 '09; API spec. version: 7.23; affected top-level classes: Repository; made by: jtulach; issues: #169892

One can provide fallback content of system filesystem by returning Boolean.TRUE from call to fs.getRoot().getAttribute("fallback").

Read files with asText(), asBytes() and asLines()

Feb 3 '09; API spec. version: 7.21; affected top-level classes: FileObject; made by: jtulach

Added asBytes(), asText(encoding), and asLines(encoding) methods into FileObject to simplify reading of its content.

Possibility to add FileChangeListeners on File (even not existing)

Jan 14 '09; API spec. version: 7.20; affected top-level classes: FileUtil; made by: jskrivanek; issues: #33162

Added FileUtil.addFileChangeListener(FileChangeListener listener, File path) and FileUtil.addFileChangeListener(FileChangeListener listener, File path). It permits you to listen to a file which does not yet exist, or continue listening to it after it is deleted and recreated, etc.

Added FileUtil.getConfigFile and getConfigRoot for simpler access to default filesystem

Jan 12 '09; API spec. version: 7.19; affected top-level classes: FileUtil; made by: jskrivanek; issues: #91534

Rather than having to call Repository.getDefault().getDefaultFileSystem().getRoot().getFileObject("foo/bar"), you can simply call FileUtil.getConfigFile("foo/bar").

Persisted registration of file extension to MIME type

Dec 19 '08; API spec. version: 7.18; affected top-level classes: FileUtil; made by: jskrivanek; issues: #153202

Method FileUtil.setMIMEType(String extension, String mimeType) resurrected to register file extension for specified MIME type. It is persisted in userdir contrary to previous implementation. Added method FileUtil.getMIMETypeExtensions(String mimeType) to get list of file extensions associated with specified MIME type.

FileChooserBuilder added

Dec 1 '08; API spec. version: 7.17; affected top-level classes: FileChooserBuilder; made by: tboudreau; issues: #47737

Added FileChooserBuilder, a utility class for working with JFileChoosers. In particular, FileChooserBuilder makes it easy to create file chooser dialogs which remember what directory the user last invoked them on, across sessions.


Compatibility:

Added org.openide.filesystems.FileChooserBuilder to API.

Added new elements to MIME resolver DTD

Nov 18 '08; API spec. version: 7.16; made by: jskrivanek; issues: #142760

It is now possible to write declarive MIME resolvers checking file names (element name) and file content (element pattern).

Support for annotation processors generating XML layer fragments

Nov 1 '08; API spec. version: 7.15; affected top-level classes: LayerGeneratingProcessor LayerBuilder LayerGenerationException; made by: jglick; issues: #149136

It is now possible to write JSR 269-compliant annotation processors which create XML layer (i.e. system filesystem) entries.


Compatibility:

Any code which scans modules for XML layers should now interpret not only the OpenIDE-Module-Layer manifest attribute (if present), but also use the resource META-INF/generated-layer.xml if present.

FileUtil.getMIMEType() can be restricted by listed MIME types

Sep 3 '08; API spec. version: 7.13; affected top-level classes: FileUtil MIMEResolver; made by: jskrivanek; issues: #137734

To speed up MIME type recognition it is added an extra parameter to method FileUtil.getMIMEType(FileObject, String...). We can supply one or more MIME types which we are only interested in. Module writers have to override MIMEResolver default constructor and call super(String...), e.g.:

                    public MyResolver() {
                        super("text/plain", "text/sh");
                    }
                

Compatibility:

If you have a MIMEResolver subclass, be sure to use the new super constructor.

XMLFileSystem attributes can be queried for instance class

Aug 25 '08; API spec. version: 7.12; affected top-level classes: XMLFileSystem; made by: jskrivanek; issues: #131951

If you are interested just in the Class of an attribute, but without creating its instance, use fileObject.getAttribute("class:attrName"). This instructs the XMLFileSystem to scan its XML files for definition of attrName attribute and guess its class. The guessing is usually easy, just for methodvalue types, the system needs to use some kind of heuristic: it locates the appropriate factory method and returns its return type. This may not be the actual type of the returned object at the end, but it seems as the best guess without instantiating it.

Declarative MIME resolvers now available in standalone mode

Jul 10 '08; API spec. version: 7.11; affected top-level classes: MIMEResolver; made by: jglick; issues: #138846

Declaratively registered MIME resolvers using the XML file syntax (rather than Java classes implementing MIMEResolver) are now used even when you run an application with just the Filesystems API in the classpath. In particular, this makes declarative resolvers be honored in unit tests. Formerly, declarative resolvers were only loaded when you used org-netbeans-core.jar and started the full module system.


Compatibility:

XMLFileSystem supports 'bundlevalue' attribute

Jul 8 '08; API spec. version: 7.10; affected top-level classes: XMLFileSystem; made by: jtulach; issues: #138076

It is possible to declare a value in layer.xml files with <attr name="..." bundlevalue="org.yourpkg.Bundle#key"/>.

Added methods to interconvert URLs and traditional path entries

Mar 17 '08; API spec. version: 7.8; affected top-level classes: FileUtil; made by: jglick; issues: #59311

Added methods urlForArchiveOrDir and archiveOrDirForURL to FileUtil to make it easier to work with classpaths.

Add methods: addFileChangeListener, removeFileChangeListener, refreshAll

Feb 26 '08; API spec. version: 7.7; affected top-level classes: FileUtil; made by: rmatous; issues: #127121
Added utility methods:

Add method FileUtil.refreshFor(File... files)

Jan 16 '08; API spec. version: 7.6; affected top-level classes: FileUtil; made by: rmatous; issues: #125308

Added helper method for refreshing all necessary filesystems, to get refreshed all instances of FileObject representing passed files and their children recursively.

Simple way to run atomic action without having a fileobject

Jan 8 '08; API spec. version: 7.5; affected top-level classes: FileUtil; made by: rmatous; issues: #123899

Simple way to run atomic action without having a fileobject is ensured by adding two methods: FileUtil.runAtomicAction. All events about filesystem changes (related to events on all affected instances of FileSystem) are postponed after the whole code runned in atomic block is executed.

Added method to test if file is locked

Jul 26 '07; API spec. version: 7.3; affected top-level classes: FileObject; made by: rmatous; issues: #110549

Added method isLocked to FileObject.

Added methods to order files in a folder

Jun 16 '07; API spec. version: 7.2; affected top-level classes: FileUtil; made by: jglick; issues: #103187

Added methods getOrder, setOrder, and affectsOrder to FileUtil.

Allow modules to dynamically add/remove layer content

Mar 12 '07; API spec. version: 7.1; affected top-level classes: Repository; made by: jtulach; issues: #26338

Repository.getDefaultFileSystem's content can now be influenced by adding own FileSystems into global Lookup.getDefault(). This is supposed to work in a standalone mode as well as inside NetBeans Platform. The tutorial is available in the usecases section of achitecture description.

Added additional methods FileUtil.createData and FileUtil.createFolder that take java.io.File as a parameter.

Sep 7 '06; API spec. version: 7.0; affected top-level classes: FileUtil; made by: rmatous; issues: #81527

Added two utility methods for creation of folders and data files that take java.io.File as a parameter: public static FileObject createFolder (final File folder) throws IOException and public static FileObject createData (final File folder) throws IOException

Semantics of XMLFileSystem's methodvalue extended to also support methods that do not depend on FileSystems API at all

May 29 '06; API spec. version: 7.0; affected top-level classes: XMLFileSystem; made by: jtulach; issues: #76692

XMLFileSystem's methodvalue now supports also Map attribute, so one can write factory methods that are completely independent on filesystems by creating methods like static Object methodName(Map attrs) or static Object methodName(Map attrs, String s).

Added additional method FileObject.getOutputStream that doesn't take FileLock as a parameter.

May 3 '06; API spec. version: 6.6; affected top-level classes: FileObject; made by: rmatous

Although newly added method FileObject.getOutputStream doesn't take FileLock as a parameter, the implementation is responsible for taking a lock before OutputStream is returned and thus FileAlreadyLockedException exception is thrown when FileObject is already locked.

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 August 28 2014.  |  Portions Copyright 1997-2014 Oracle. All rights reserved.