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 deprecated
FileObject.toString() not to be used for specific purposes
FileObject.getPath() returns full resource path of file object
WizardDescriptor as bean customizers
Repository is not a cookie
FileObject.toURI
FileObject.revert
LayerBuilder can validate resources
LayerGenerationException has new constructors
FileUtil.normalizePath added
MultiFileSystem overrides
MIMEResolver.UIHelpers
LayerBuilder.instanceFile added
LayerBuilder.folder added
FileUtil.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 added
FileObject.setImportant deprecated
FileObject.toString() not to be used for specific purposes
FileObject.getPath() returns full resource path of file object
FileEvents fired inside atomic actions can report from which atomic actions they were fired
WizardDescriptor as bean customizers
Repository from within Filesystems API
MIMEResolver
Repository is not a cookie
MultiFileSystem finds actions on a set of files specially
XMLFileSystem
RepositoryAdapter added
AbstractFileSystem.refreshRoot was of the wrong type
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
FileObject.toURI
FileObject.revert
LayerBuilder can validate resources
LayerGenerationException has new constructors
FileUtil.normalizePath added
MultiFileSystem overrides
MIMEResolver.UIHelpers
LayerBuilder.instanceFile added
LayerBuilder.folder added
FileUtil.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 added
FileObject.setImportant deprecated
FileObject.toString() not to be used for specific purposes
FileUtil.createMemoryFileSystem ()
FileUtil.preventFileChooserSymlinkTraversal(...)
FileObject.getPath() returns full resource path of file object
FileEvents fired inside atomic actions can report from which atomic actions they were fired
org.openide.actions.AbstractCompileAction
org.openide.filesystems.AbstractFileSystem
AbstractFileSystem.refreshRoot was of the wrong type
org.openide.actions.AddWatchAction
org.openide.filesystems.spi.ArchiveRootProvider
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.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
FileEvents fired inside atomic actions can report from which atomic actions they were fired
org.openide.filesystems.FileLock
org.openide.filesystems.FileObject
FileObject.toURI
FileObject.revert
FileObject.getOutputStream
that doesn't take FileLock as a parameter.
FileObject.getFileObject made not final.
FileObject.setImportant deprecated
FileObject.toString() not to be used for specific purposes
FileObject.getPath() returns full resource path of file object
org.openide.explorer.propertysheet.editors.FileOnlyEditor
org.openide.filesystems.FileRenameEvent
org.openide.filesystems.FileStateInvalidException
org.openide.filesystems.FileSystem
org.openide.filesystems.FileUtil
FileUtil.normalizePath added
FileUtil.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 added
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
LayerBuilder can validate resources
LayerGenerationException has new constructors
LayerBuilder.instanceFile added
LayerBuilder.folder added
org.openide.filesystems.annotations.LayerGeneratingProcessor
org.openide.filesystems.annotations.LayerGenerationException
LayerGenerationException has new constructors
org.openide.LifecycleManager
org.openide.filesystems.LocalFileSystem
org.openide.modules.ManifestSection
org.openide.explorer.propertysheet.editors.MethodParameterArrayEditor
org.openide.filesystems.MIMEResolver
MIMEResolver.UIHelpers
MIMEResolver
org.openide.explorer.propertysheet.editors.ModifierEditor
org.openide.modules.ModuleDescription
org.openide.filesystems.MultiFileSystem
MultiFileSystem overrides
MultiFileSystem finds actions on a set of files specially
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
Repository from within Filesystems API
Repository is not a cookie
org.openide.filesystems.RepositoryAdapter
RepositoryAdapter added
org.openide.loaders.RepositoryNodeFactory
org.openide.actions.SaveProjectAction
org.openide.cookies.SourceCookie
org.openide.actions.StartDebuggerAction
org.openide.filesystems.StatusDecorator
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
XMLFileSystem
FileUtil ArchiveRootProvider; made by: tzezula
getArchiveFile,getArchiveRoot and isArchiveFile
are pluggable using a new SPI ArchiveFileProvider.
In addition to these methods a new method isArchiveArtifact was added.
This method can be used if given URL points into an archive.
Repository; made by: sdedic
FileObject FileUtil AbstractFileSystem; made by: jhavlin; issues:
#237882
Add methods to FileObject for handling of
symbolic links:
isSymbolicLink()
readSymbolicLink()
readSymbolicLinkPath()
getCanonicalFileObject()
Add utility method to FileUtil for dealing with
recursive symbolic links.
isRecursiveSymbolicLink()
Introduce new interface AbstractFileSystem.SymlinkInfo.
FileLock; made by: sdedic; issues:
#247915
FileLock implements AutoCloseable to work well in try-with-resources constructs.
StatusDecorator; made by: sdedic; issues:
#247200
The FileSystem.Status was entirely removed, as it references class java.awt.Image, which is not available in compact jdk profiles and may trigger GUI system initialization. See javadocs of StatusDecorator for details.
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...
The default implementation of FileSystem.Status annotated file's icon using ImageUtilities which uses AWT graphics etc. Such dependency is not desirable in a standalone FileSystem API library.
The builtin implementation now does not work with the icon at all and returns null. A proper
implementation for FileSystem.Status is looked up in default Lookup and is implemented
properly (with Icon annotations) in openide.filesystems.nb module.
Files which have been deleted can be obtained by folder.getAttribute("revealEntries").
See MultiFileSystem
javadoc for details
Warning: stability of this feature is development
org.openide.filesystems.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.
org.openide.filesystems.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; made by: jtulach; issues:
#209231
FileObject now implements Lookup.Provider
and thus has new
getLookup() method.
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.
FileSystem; made by: alexvsimon; issues:
#207659
Added methods to create temporary file objects:
FileSystem.getTempFolder, FileSystem.createTempFile.
Repository; made by: jtulach; issues:
#198508
Those who wish to influence content of configuration file system have an easier way now.
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.
FileObject.toURI
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.
FileObject.getURL should be replaced with toURL (or toURI),
which also throw no checked exceptions.
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.
FileObject.revert
FileObject; made by: jglick; issues:
#162526
Added revert and canRevert to FileObject.
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.
FileEvent; made by: jtulach; issues:
#203477
New FileEvent constructor allowing specification
of expected state as well as time.
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
LayerBuilder; made by: jglick; issues:
#196452
LayerBuilder has a new validateResource method.
absolutizeResource was also added.
LayerGenerationException has new constructors
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.
Code using the constructors not specifying an annotation should now do so.
FileUtil; made by: jtulach; issues:
#169338
One can convert files in SystemFileSystem to Object with a single utility method.
FileObject; made by: jtulach; issues:
#194418
Semantic of getFileObject method has been clarified to accept "..".
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; 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
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; made by: jtulach; issues:
#40739
Create a file and write its content (almost) atomically using the new FileObject.createAndOpen method.
MultiFileSystem overrides
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.
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.)
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.
JarFileSystem; made by: jtulach; issues:
#177461
New constructor for JarFileSystem
that initializes everything without opening the underlaying
JAR file.
MIMEResolver.UIHelpers
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.
FileObject FileUtil; made by: jtulach; issues:
#170862
One can register a recursive listener on a file object by calling FileObject.addRecursiveListener(FileChangeListener).
LayerBuilder.instanceFile added
LayerBuilder; made by: jglick; issues:
#171284
New overload of instanceFile makes it easier to create
instances for use with lazy factories.
LayerBuilder.folder added
LayerBuilder; made by: jglick; issues:
#171029
Now 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:
#170544
FileEvent.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: jtulach
Added asBytes(), asText(encoding), and asLines(encoding) methods into FileObject to simplify reading of its content.
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.
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:
#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.
org.openide.filesystems.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.
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:
#149136
It 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:
#127121
public static FileObject addFileChangeListener (final FileChangeListener fcl) to receive
FileEvents from FileSystems providing instances
of FileObject convertible to java.io.File
public static FileObject removeFileChangeListener (final FileChangeListener fcl) to no longer receive
FileEvents from FileSystems providing instances
of FileObject convertible to java.io.File
public 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:
#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.
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: 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.
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:
#46459
FileUtil.preventFileChooserSymlinkTraversal(...)
to help work around problems with symbolic links and JFileChooser.
FileUtil; made by: rmatous; issues:
#37549
FileObject isn't root.
Repository; made by: rmatous; issues:
#42273
getDefault ()
getDefaultFileSystem ()
URLMapper for providing FileObjects
DefaultAttributes; made by: rmatous; issues:
#43180
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
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
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.
There is no direct replacement. Code using this method should be reëvaluated in the light of other changes in NetBeans 4.0.
FileObject FileSystem; made by: jglick
Various parts of the Filesystems API which are no longer useful in NetBeans 4.0 were deprecated. The assumptions which are now invalid were:
The root of a filesystem corresponds to a Java classpath root (if the appropriate capabilities were set). Now handled by the Classpath API.
The user explicitly mounts and unmounts filesystems, either to control the classpath, for version control purposes, or simply to access some area of the disk; and so filesystem metadata is relevant to the GUI. Now obsoleted by the Classpath API and MasterFS.
The IDE internally managed a list of mounted filesystems. Now only the default system filesystem is “mounted”; MasterFS transparently manages all “user-space” files.
File objects are persisted by saving a reference to the containing filesystem, plus the relative path within the filesystem. Now done using URLs.
Specific deprecations:
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 purposes
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:
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:
#41506
FileUtil FileObject; made by: rmatous; issues:
#37445
FileObject AbstractFileSystem; made by: rmatous
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; made by: rmatous; issues:
#28312
URLMapper.findFileObjects returns empty array if not successful.
As far there was in documentation written, that null is returned.
FileUtil; made by: vstejskal
FileObject; made by: pzavadsky; issues:
#27640
#27687
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
FileObject; made by: jglick; issues:
#26904
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.
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: jtulach
URLMapper; made by: rmatous
public 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: rmatous
URLMapper. This class provides basic mapping
for FileObjects from LocalFileSystem, JarFileSystem and MultiFileSystem and is intended
as superclass for individual mappers.
FileSystem; made by: rmatous
public void FileSystem.refresh (boolean expected)) was added.
FileSystem; made by: rmatous
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; made by: rmatous
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.
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
FileEvent; made by: rmatous
boolean FileEvent.firedFrom(FileSystem.AtomicAction run) returns true if this
FileEvent was fired from run.
MultiFileSystem; made by: rmatous
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; 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.
FileAttributeEvent
fields were non-null may now be broken, and should check for
nulls.
FileStateInvalidException; made by: mschilling
public String getFileSystemName(). This will
return the name of the filesystem containing the file with invalid
state if such information is available.
FileUtil; made by: rmatous
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.
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: rmatous
public FileObject createData(String name)
throws IOException. Creates new data file in this folder with the
specified name. Plainly calls createData(name,"").
FileObject
public final void delete().
FileObject is locked before delete and finally this lock is
released.
AbstractFileSystem
protected boolean checkVirtual(String
name).Tests if file really exists or is missing. Some operation on
it may be restricted if returns true.
AbstractFileSystem
protected void markImportant(String name,
boolean important). Mark the file as being important or
unimportant.
FileObject
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.
Repository from within Filesystems API
Repository
Repository.getDefault() that allows standalone
tools (using just filesystems library) without access to
TopManager to get the default repository of the system.
FileUtil
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.
MIMEResolver
MIMEResolver; made by: rmatous
MIMEResolver. This class is intended as superclass
for individual resolvers.
FileEvent FileAttributeEvent FileRenameEvent
FileEvent and subclass constructors may take a parameter
boolean expected.
Repository is not a cookie
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.
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 specially
MultiFileSystem
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).
MultiFileSystem; made by: jglick
setPropagateMasks and getPropagateMasks added to
make it easier to compose multi filesystems inside other multi filesystems.
XMLFileSystem
XMLFileSystem
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.
FileUtil; made by: jglick
AbstractFileSystem
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.
AbstractFileSystem
Reference findReference(String resourceName). This
method finds the reference associated with resourceName.
AbstractFileSystem
existingFileObjects(FileObject).
Can be used to find all FileObjects in this filesystem with
the given predecessor.
RepositoryAdapter added
RepositoryAdapter; made by: jglick
RepositoryListener.
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 type
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.
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:
#19443
Three sections of the Open APIs were split into new autoload modules.
The module org.openide.compiler (version 1.0) contains
the Compiler API and some other classes directly related to it.
The module org.openide.execution (version 1.0) contains
the Execution API and some other classes directly related to it.
The module org.openide.io (version 1.0) contains
InputOutput and related classes (formerly part of the
Window System API, and still physically in the
org.openide.windows package).
New modules wishing to use these APIs must declare regular module dependencies on them. Future changes in these APIs will be documented separately.
Furthermore, modules wishing to use certain services must
OpenIDE-Module-Require them if appropriate:
org.openide.compiler.CompilationEngine, in order to
call CompilationEngine.getDefault(), or safely use
AbstractCompileAction or one of its subclasses, or
call CompilerJob.start(), or use
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
#20898
Many classes were moved to a separate module, openide-deprecated.jar, not available to modules by default. Uses of these classes in modules should be cleaned up whenever possible.
Additionally, the entire contents of org.openide.src.* and
org.openide.src.nodes.*, as well as
org.openide.cookies.SourceCookie and some associated
property editors, were moved to a separate module.
The most common apparent symptom for module authors will be the absence
of TopManager. Most methods in this class have been
replaced by newer utility classes in a straightforward manner. See the
Upgrade Guide.
The deprecated classes continue to be available in the module
org.openide.deprecated which you may depend on it you
cannot remove uses of the deprecated APIs. In order for
TopManager.getDefault() to work, you must also require the
token org.openide.TopManager, which is provided by an
unspecified module. The deprecated API module and its implementation
module are autoloads, meaning they will not be loaded unless some
module still requires them.
Similarly, the Java Hierarchy API was moved to the module
org.openide.src which you should depend on in order to use
this API.
For compatibility, the above three dependencies are added to your module automatically in case it either requests no specific API version at all, or requests an API version prior to 3.14. Modules requesting APIs 3.14 or higher must declare these dependencies explicitly if they in fact need them.
Built on June 4 2024. | Copyright © 2017-2024 Apache Software Foundation. All Rights Reserved.