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: org.netbeans.modules.editor.fold/1 > 1.20

Changes by affected class

org.netbeans.api.editor.fold.Fold

org.netbeans.api.editor.fold.FoldHierarchy

org.netbeans.spi.editor.fold.FoldHierarchyMonitor

org.netbeans.spi.editor.fold.FoldInfo

org.netbeans.api.editor.fold.FoldingSupport

org.netbeans.api.editor.fold.FoldType

org.netbeans.spi.editor.fold.FoldTypeProvider

org.netbeans.api.editor.fold.FoldUtilities


Details of all changes by API and date


Fold API

Extensible FoldTypes, enhanced support for fold updates

Mar 12 '13; API spec. version: 1.35; affected top-level classes: FoldTypeProvider FoldInfo FoldType Fold FoldUtilities FoldingSupport; made by: sdedic; issues: #226413

FoldTypes can be defined for a mime type by FoldTypeProviders. They can form a type hierarchy. FoldUtilities provide methods to check fold enablement and available FoldTypes. Working directly with Preferences is not advised.

Fold can provide offsets to start and end of its content excluding guard areas. FoldingSupport provides factories for comment-driven FoldManager and for fold ContentReader capable of reading javadoc-style comments or similar.

FoldOperation allows to update folds with FoldInfos, removing, adding or updating Folds as necessary. Existing FoldManagers can be simplified. Folds can be defined wihtout initial state - the state will be determined form the options by the infrastructure. All folds defined by a FoldManager can be retrieved from FoldOperation.foldIterator(), even though they are blocked.

Fold UI separation from Editor Library

Mar 8 '13; API spec. version: 1.34; affected top-level classes: FoldHierarchy FoldingSupport FoldHierarchyMonitor; made by: sdedic; issues: #226368 #226413

FoldHierarchyMonitor was introduced to allow hooking into UI when a FoldHierarchy is produced for a JTextComponent. The 'active' flag is provided on the FoldHierarchy to determine whether the hierarchy be popuplated with folds at all.

Using FoldingSupport utility class, clients can create instance of FoldManager that creates folds based on comments, previously CustomFoldManager in editor.lib module.

FoldOperation.owns(Fold) added

Mar 3 '08; API spec. version: 1.8; made by: mmetelka; issues: #108030

Added FoldOperation.owns(Fold) to check whether fold was produced by a particular FoldOperation.