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.
release41 branch was made on Apr 03 '05 for use in the NetBeans 4.1 release.
Specification versions: 6.0 begins after this point.
release40 branch was made on Nov 01 '04 for use in the NetBeans 4.0 release.
Specification versions: 5.0 begins after this point.
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.
IllegalArgumentException is thrown from
FileUtil.toFileObject was changed
FileObject.setImportant deprecatedFileObject.toString() not to be used for specific purposesFileObject.getPath() returns full resource path of file objectWizardDescriptor as bean customizers
Repository is not a cookieLayerBuilder.instanceFile addedLayerBuilder.folder addedFileUtil.createData
and FileUtil.createFolder that take java.io.File as a parameter.
FileObject.getOutputStream
that doesn't take FileLock as a parameter.
IllegalArgumentException is thrown from
FileUtil.toFileObject was changed
FileObject.getFileObject made not final.FileUtil.createMemoryFileSystem ()
FileUtil.preventFileChooserSymlinkTraversal(...)
FileUtil.normalizeFile addedFileObject.setImportant deprecatedFileObject.toString() not to be used for specific purposesFileObject.getPath() returns full resource path of file objectFileEvents fired inside atomic actions can report from which atomic actions they were firedWizardDescriptor as bean customizers
Repository from within Filesystems APIMIMEResolver
Repository is not a cookieMultiFileSystem finds actions on a set of files speciallyXMLFileSystem
RepositoryAdapter addedAbstractFileSystem.refreshRoot was of the wrong typeThese 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
LayerBuilder.instanceFile addedLayerBuilder.folder addedFileUtil.createData
and FileUtil.createFolder that take java.io.File as a parameter.
FileObject.getOutputStream
that doesn't take FileLock as a parameter.
IllegalArgumentException is thrown from
FileUtil.toFileObject was changed
FileObject.getFileObject made not final.FileUtil.normalizeFile addedFileObject.setImportant deprecatedFileObject.toString() not to be used for specific purposesFileUtil.createMemoryFileSystem ()
FileUtil.preventFileChooserSymlinkTraversal(...)
FileObject.getPath() returns full resource path of file objectFileEvents fired inside atomic actions can report from which atomic actions they were firedorg.openide.actions.AbstractCompileActionorg.openide.filesystems.AbstractFileSystemAbstractFileSystem.refreshRoot was of the wrong typeorg.openide.actions.AddWatchActionorg.openide.cookies.ArgumentsCookieorg.openide.actions.BuildActionorg.openide.actions.BuildAllActionorg.openide.actions.BuildProjectActionorg.openide.explorer.propertysheet.editors.ChoicePropertyEditororg.openide.actions.CleanActionorg.openide.actions.CleanAllActionorg.openide.actions.CompileActionorg.openide.actions.CompileAllActionorg.openide.actions.CompileProjectActionorg.openide.cookies.CompilerCookieorg.openide.loaders.CompilerSupportorg.openide.options.ControlPanelorg.openide.loaders.DataObjectFilterorg.openide.cookies.DebuggerCookieorg.openide.actions.DebugProjectActionorg.openide.filesystems.DefaultAttributesorg.openide.DialogDisplayerorg.openide.explorer.propertysheet.editors.DirectoryOnlyEditororg.openide.cookies.ElementCookieorg.openide.explorer.propertysheet.editors.ElementFormatEditororg.openide.filesystems.EnvironmentNotSupportedExceptionorg.openide.cookies.ExecCookieorg.openide.loaders.ExecSupportorg.openide.actions.ExecuteActionorg.openide.actions.ExecuteProjectActionorg.openide.loaders.ExecutionSupportorg.openide.loaders.ExtensionListEditororg.openide.explorer.propertysheet.editors.ExternalCompilerorg.openide.filesystems.FileAttributeEventorg.openide.filesystems.FileChooserBuilderorg.openide.explorer.propertysheet.editors.FileEditororg.openide.filesystems.FileEventFileEvents fired inside atomic actions can report from which atomic actions they were firedorg.openide.filesystems.FileObjectFileObject.getOutputStream
that doesn't take FileLock as a parameter.
FileObject.getFileObject made not final.FileObject.setImportant deprecatedFileObject.toString() not to be used for specific purposesFileObject.getPath() returns full resource path of file objectorg.openide.explorer.propertysheet.editors.FileOnlyEditororg.openide.filesystems.FileRenameEventorg.openide.filesystems.FileStateInvalidExceptionorg.openide.filesystems.FileSystemorg.openide.filesystems.FileSystemCapabilityorg.openide.filesystems.FileUtilFileUtil.createData
and FileUtil.createFolder that take java.io.File as a parameter.
IllegalArgumentException is thrown from
FileUtil.toFileObject was changed
FileUtil.createMemoryFileSystem ()
FileUtil.preventFileChooserSymlinkTraversal(...)
FileUtil.normalizeFile addedorg.openide.actions.FinishDebuggerActionorg.openide.actions.GoActionorg.openide.actions.GoToCursorActionorg.openide.actions.HelpActionorg.openide.awt.HtmlBrowserorg.openide.explorer.propertysheet.editors.IconEditororg.openide.explorer.propertysheet.editors.IdentifierArrayEditororg.openide.modules.IllegalModuleExceptionorg.openide.windows.InputOutputorg.openide.windows.IOProviderorg.openide.filesystems.JarFileSystemorg.openide.filesystems.annotations.LayerBuilderLayerBuilder.instanceFile addedLayerBuilder.folder addedorg.openide.filesystems.annotations.LayerGeneratingProcessororg.openide.filesystems.annotations.LayerGenerationExceptionorg.openide.LifecycleManagerorg.openide.filesystems.LocalFileSystemorg.openide.modules.ManifestSectionorg.openide.explorer.propertysheet.editors.MethodParameterArrayEditororg.openide.filesystems.MIMEResolverMIMEResolver
org.openide.explorer.propertysheet.editors.ModifierEditororg.openide.modules.ModuleDescriptionorg.openide.filesystems.MultiFileSystemMultiFileSystem finds actions on a set of files speciallyorg.openide.nodes.NodeOperationorg.openide.actions.OpenProjectActionorg.openide.windows.OutputEventorg.openide.windows.OutputListenerorg.openide.windows.OutputWriterorg.openide.Placesorg.openide.cookies.ProjectCookieorg.openide.util.actions.ProjectSensitiveActionorg.openide.filesystems.RepositoryRepository from within Filesystems APIRepository is not a cookieorg.openide.filesystems.RepositoryAdapterRepositoryAdapter addedorg.openide.loaders.RepositoryNodeFactoryorg.openide.actions.SaveProjectActionorg.openide.cookies.SourceCookieorg.openide.actions.StartDebuggerActionorg.openide.awt.StatusDisplayerorg.openide.actions.StepOutActionorg.openide.explorer.propertysheet.editors.StringArrayCustomEditororg.openide.explorer.propertysheet.editors.StringArrayCustomizableorg.openide.explorer.propertysheet.editors.StringArrayEditororg.openide.actions.ToggleBreakpointActionorg.openide.TopManagerorg.openide.actions.TraceIntoActionorg.openide.actions.TraceOverActionorg.openide.explorer.propertysheet.editors.TypeEditororg.openide.filesystems.URLMapperorg.openide.filesystems.XMLFileSystemXMLFileSystem
FileObject FileUtil; made by: jtulach; issues:
#170862One can register a recursive listener on a file object by calling FileObject.addRecursiveListener(FileChangeListener).
LayerBuilder.instanceFile addedLayerBuilder; made by: jglick; issues:
#171284
New overload of instanceFile makes it easier to create
instances for use with lazy factories.
LayerBuilder.folder addedLayerBuilder; made by: jglick; issues:
#171029Now possible to create empty folders from layer-generating processors.
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.
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.
FileEvent; made by: jtulach; issues:
#170544FileEvent.runWhenDeliveryOver(Runnable) method added to support easier processing of batch sets of events.
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").
FileObject; made by: jtulachAdded asBytes(), asText(encoding), and asLines(encoding) methods into FileObject to simplify reading of its content.
FileUtil; made by: jskrivanek; issues:
#33162Added 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.
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").
FileUtil; made by: jskrivanek; issues:
#153202Method 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; made by: tboudreau; issues:
#47737Added 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.
Added org.openide.filesystems.FileChooserBuilder to API.
It is now possible to write declarive MIME resolvers checking file names (element name) and file content (element pattern).
LayerGeneratingProcessor LayerBuilder LayerGenerationException; made by: jglick; issues:
#149136It is now possible to write JSR 269-compliant annotation processors which create XML layer (i.e. system filesystem) entries.
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 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");
}
If you have a MIMEResolver subclass, be sure to use the new super constructor.
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.
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.
The old impl would have interpreted a resolver (with the correct doctype) in any location beneath Services. (Actually
a resolver would offer an InstanceCookie<MIMEResolver> in any location, but outside Services they would not have been
used in MIME resolution.) The new impl expects resolvers to be Services/MIMEResolver/*.xml, as in practice they always
are, and does not bother to verify that the public ID is set to the expected value in the doctype.
The old impl would have inserted the declarative resolvers in default lookup (assuming you were running with the
module system started and thus FolderLookup[Services included). The new impl does not.
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"/>.
FileUtil; made by: jglick; issues:
#59311
Added methods urlForArchiveOrDir and archiveOrDirForURL
to FileUtil to make it easier to work with classpaths.
FileUtil; made by: rmatous; issues:
#127121public static FileObject addFileChangeListener (final FileChangeListener fcl) to receive
FileEvents from FileSystems providing instances
of FileObject convertible to java.io.Filepublic static FileObject removeFileChangeListener (final FileChangeListener fcl) to no longer receive
FileEvents from FileSystems providing instances
of FileObject convertible to java.io.Filepublic static FileObject refreshAll () to refreshes all FileObject that represent files File.listRoots()
and their children recursively.
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.
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.
FileObject; made by: rmatous; issues:
#110549
Added method isLocked to FileObject.
FileUtil; made by: jglick; issues:
#103187
Added methods getOrder, setOrder,
and affectsOrder to FileUtil.
Repository; made by: jtulach; issues:
#26338Repository.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.
FileUtil.createData
and FileUtil.createFolder that take java.io.File as a parameter.
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
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).
FileObject.getOutputStream
that doesn't take FileLock as a parameter.
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.
IllegalArgumentException is thrown from
FileUtil.toFileObject was changed
FileUtil; made by: rmatousBecause 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.
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.
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.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.
FileUtil.createMemoryFileSystem ()
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.
FileUtil.preventFileChooserSymlinkTraversal(...)
FileUtil; made by: jglick; issues:
#46459FileUtil.preventFileChooserSymlinkTraversal(...)
to help work around problems with symbolic links and JFileChooser.
FileUtil; made by: rmatous; issues:
#37549FileObject isn't root.
Repository; made by: rmatous; issues:
#42273getDefault ()
getDefaultFileSystem ()
URLMapper for providing FileObjects
DefaultAttributes; made by: rmatous; issues:
#43180FileUtil; 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 addedFileUtil; 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 deprecatedFileObject; 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.
There is no direct replacement. Code using this method should be reëvaluated in the light of other changes in NetBeans 4.0.
EnvironmentNotSupportedException FileObject FileSystem FileSystemCapability; made by: jglickVarious 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:
FileSystem.Environment and
EnvironmentNotSupportedException
FileSystemCapability (and its constants and subclasses),
FileSystem.getCapability and setCapability,
constructors taking FileSystemCapability
FileSystem.PROP_HIDDEN, isHidden, and
setHidden
FileSystem.PROP_SYSTEM_NAME, getSystemName,
and setSystemName
FileSystem.find
FileObject methods such as getPackageName
FileSystem.isPersistent
See also deprecations in
Repository
.
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 purposesFileObject; 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:
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).
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.
Older Filesystems API clients which assumed that
FileObject.toString() and
FileObject.getPath() do the same thing will be broken.
FileUtil URLMapper; made by: rmatous; issues:
#41506FileUtil FileObject; made by: rmatous; issues:
#37445FileObject AbstractFileSystem; made by: rmatouspublic 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; made by: rmatous; issues:
#28312URLMapper.findFileObjects returns empty array if not successful.
As far there was in documentation written, that null is returned.
FileUtil; made by: vstejskalFileObject; made by: pzavadsky; issues:
#27640
#27687FileObject.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 objectFileObject; made by: jglick; issues:
#26904getPackageNameExt('/', '.'), 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.
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.
Repository; made by: jtulachURLMapper; made by: rmatouspublic static FileObject[] findFileObjects (URL url) and
public abstract FileObject[] getFileObjects (URL url).
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.
URLMapper; made by: rmatousURLMapper. This class provides basic mapping
for FileObjects from LocalFileSystem, JarFileSystem and MultiFileSystem and is intended
as superclass for individual mappers.
FileSystem; made by: rmatouspublic void FileSystem.refresh (boolean expected)) was added.
FileSystem; made by: rmatouspublic 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; made by: rmatouspublic 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.
FileSystem; made by: rmatousFileSystem.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 firedFileEvent; made by: rmatousboolean FileEvent.firedFrom(FileSystem.AtomicAction run) returns true if this
FileEvent was fired from run.
MultiFileSystem; made by: rmatouscreateWritableOnForRename 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; made by: rmatousFileAttributeEvent'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.
FileAttributeEvent
fields were non-null may now be broken, and should check for
nulls.
FileStateInvalidException; made by: mschillingpublic String getFileSystemName(). This will
return the name of the filesystem containing the file with invalid
state if such information is available.
FileUtil; made by: rmatouspublic 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.
WizardDescriptor as bean customizers
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.
FileObject; made by: rmatouspublic FileObject createData(String name)
throws IOException. Creates new data file in this folder with the
specified name. Plainly calls createData(name,"").
FileObjectpublic final void delete().
FileObject is locked before delete and finally this lock is
released.
AbstractFileSystemprotected boolean checkVirtual(String
name).Tests if file really exists or is missing. Some operation on
it may be restricted if returns true.
AbstractFileSystemprotected void markImportant(String name,
boolean important). Mark the file as being important or
unimportant.
FileObjectpublic 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.
Repository from within Filesystems APIRepositoryRepository.getDefault() that allows standalone
tools (using just filesystems library) without access to
TopManager to get the default repository of the system.
FileUtilgetMIMEType(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.
MIMEResolver
MIMEResolver; made by: rmatousMIMEResolver. This class is intended as superclass
for individual resolvers.
FileEvent FileAttributeEvent FileRenameEventFileEvent and subclass constructors may take a parameter
boolean expected.
Repository is not a cookieRepository; made by: jtulachRepository 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.
Repository as cookie should be changed to:
ic = (InstanceCookie)node.getCookie(InstanceCookie.class);
if (ic != null && Repository.class.isAssignableFrom(ic.instanceCookie())) {
// do stuff
}
MultiFileSystem finds actions on a set of files speciallyMultiFileSystemgetActions(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).
MultiFileSystem; made by: jglicksetPropagateMasks and getPropagateMasks added to
make it easier to compose multi filesystems inside other multi filesystems.
XMLFileSystem
XMLFileSystemXMLFileSystem 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.
FileUtil; made by: jglickAbstractFileSystemReference 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.
AbstractFileSystemReference findReference(String resourceName). This
method finds the reference associated with resourceName.
AbstractFileSystemexistingFileObjects(FileObject).
Can be used to find all FileObjects in this filesystem with
the given predecessor.
RepositoryAdapter addedRepositoryAdapter; made by: jglickRepositoryListener.
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.
boston. Any outside code calling them as public will break;
however such code is definitely erroneous and should be rewritten.
AbstractFileSystem.refreshRoot was of the wrong typeAbstractFileSystemrefreshRoot 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.
boston. The change should be source-code compatible, and is
made to be binary compatible as well.
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:
#19443Three 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
BeanInfos 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 BeanInfos
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.
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.
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
#20898Many classes were moved to a separate module, openide-deprecated.jar, not available to modules by default. Uses of these classes in modules should be cleaned up whenever possible.
Additionally, the entire contents of org.openide.src.* and
org.openide.src.nodes.*, as well as
org.openide.cookies.SourceCookie and some associated
property editors, were moved to a separate module.
The most common apparent symptom for module authors will be the absence
of TopManager. Most methods in this class have been
replaced by newer utility classes in a straightforward manner. See the
Upgrade Guide.
The deprecated classes continue to be available in the module
org.openide.deprecated which you may depend on it you
cannot remove uses of the deprecated APIs. In order for
TopManager.getDefault() to work, you must also require the
token org.openide.TopManager, which is provided by an
unspecified module. The deprecated API module and its implementation
module are autoloads, meaning they will not be loaded unless some
module still requires them.
Similarly, the Java Hierarchy API was moved to the module
org.openide.src which you should depend on in order to use
this API.
For compatibility, the above three dependencies are added to your module automatically in case it either requests no specific API version at all, or requests an API version prior to 3.14. Modules requesting APIs 3.14 or higher must declare these dependencies explicitly if they in fact need them.
Built on July 6 2010. | Portions Copyright 1997-2010 Sun Microsystems, Inc. All rights reserved.