Disclaimer: The content of this NetBeans development wiki page is intended for pre-planning purposes ONLY. The development, release, and timing of any feature or functionality described here should not be treated as final, and is subject to change at any time at the sole discretion of Oracle. For information about NetBeans software releases please visit the NetBeans Roadmap.


Planning Summary

Feature Task Description Covered bugs Man-days
CSL Wizard Wizard for implementation language support 15
Adaptor Support Annotation-based registration of adaptors 5
Enumration Support for extensible enumerations per-MIME type Issue 142711 3
Scheduling Adaptor to allow customized scheduling while retain CSL post/pre processing 5
Code Folding Core New simplified SPI for folding Issue 142711, Issue 206854 10
Retrofit Consolidate existing code 5
Semantic Highlighting Color caching and support for parser-based highlighters 3
Structure Support API New file structure API/SPI Issue 150084, Issue 170281, Issue 177866 10
Folding Folding adaptor based on file structure 2
Retrofit Consolidate existing code 8
GsfDataObject removal Replace GsfDataObject by standard supports 5
Code Completion Support adaptor Simplified Adaptor to Editor APIs 13
Retrofit Adapt HTML module 3
Total 72

See also CSLRequirementsNB69

Individual Features

Adaptor Support

MimeDataProvider implementation for CSL adaptors, which will convert certain interface implementors into different APIs. The adaptor will, for example, inject a FoldManagerFactory instance in the Lookup, for each registered ParsingFoldAnalyzer instance. No special annotation needs to be developed for individual services, if only adaptor has to be registered; standard @MimeRegistration can be used.

This item MAY have performance impact: additional member of MIME proxylookup is added for each adaptor.

An annotation supplementing the @MimeRegistration can be added, which will allow to plug in the Adaptor while the annotation mentions the original interface to bind. Compile-time check that an appropriate adaptor generator to translate the annotated type to the desired.

Estimate: 5 days


Support for extensible enumerations must be provided. Each of the languages should provide a set of enumeration values. Each language must be allowed to define the set of values, it must be possible to use predefined values as well. This principle should be used for:

  • Fold Types
  • ColoringAttributes
  • Modifiers
  • ElementKind

CSL will define basic instances/classes for individual enums:

  • Fold Types: Initial Comment, Code block, Documentation, Tag
  • Coloring: Class, Declaration, Field, Global, Local Variable, Undefined, Unused,

Individual plugins will be able to:

  • use the predefined value directly
  • add its own value
    • separate
    • derived from a predefined one; this relation will be used in settings mgmt UI

Estimate: 3 days


Many features in CSL depend on Parser.Result. While a standard ParserResultTask can be scheduled and the client can be called with a read-to-use result to do the real processing, advanced modules, such as Java, may require to schedule a custom ParserResultTask. The Task can communicate its specific scheduling constraints to the parser, e.g. parser phase (as done in JavaParserResultTask).

The will be probably implemented by generating a subclass, which will receive and pre/post process ParserResultTasks lifecycle methods (e.g. interruption of the computation on changes).

Estimate: 5 days

Code Folding

There are 3 different use-cases for the common folding infrastructure:

  • Java module handles its own scheduling, but duplicates part of current CSL infrastructure: the diff/commit operation of folds, and initial fold handling. We need to

open an API to FoldManager implementation, which will perform the diff/commit and interact with the Editor.

  • XML module handles its own fold analysis based on lexing; this is accetable for a markup language. It needs also the diff/commit operation, and it would benefit from

scheduling support, based on document changes. As the Fold API itself contains document change event source, the Folding module can support this use-case without additional dependencies.

  • CSL-based languages: all currently implement Parsing API-based StructureScanner, which converts Parser.Result to folds. They need to be supported to the same degree

as in past versions, except they will connect to different interfaces.

The support must use the extensible enumerations and expose the set of FoldType values relevant for a given MIME type or an editor. The UI should be changed, to allow folding settings per MIME type (language). Folding settings should be inherited from the general types defined by CSL for all languages.

Code folding support should split in two modules: basic support will go directly to Editor Folding. Parser-based folding support must be separated into a new module Parsing Editor support.

Rough estimate: 12 days

Existing module migration

Java and XML should migrate to the new folding infrastructure. Existing duplicated code in Java/XML should be discarded. All other languages must concisely define their own folding types for user control (PHP, JS, ...)

Estimate: 5 days

Semantic Highlighting

Allow to register separately from SemanticAnalyzer, the CSL will still perform the bookkeeping:

  • schedule the ParserResultTask
  • perform caching of ColoringAttributes sets, and their translation through user preferences to AttributeSet

Client plugin must be able to provide its own ParserResultTask, so it can use advanced scheduling capabilities, such as the JavaParserResultTask phase id.

Existing module must plug into this highlighter, instead of into Language

Estimate: 5 days

Structure Support

A new API to represent structure must be defined, cleaned up (compared to existing API/SPI mixture). An adapter should exist to adapt the new API to the current StructureItem. Extensible 'element type' and 'modifier' enumerations will be used to classify elements - relevant supports, like icon lookup and badging need to be adjusted. Explicit support will be provided for grouping or virtual nodes. Each file should support multiple root nodes, which form different views on the file. These root nodes should be identified by specific Element Kinds.

Individual Providers will provide contents for the root and/or individual sub-elements.

Rough Estimate: 15 days'

Navigator Filters

Element kind filters must be pluggable for each of the languages and each of the different views. They will filter the tree based on ElementKind (extensible type enum) + Modifier combination. Custom filtering based on StructureItem instance must be also supported.

Estimate: 3 days

Structure-based folding

Folding support can be extended to follow recognized structure of the file: elements of certain kind will be automatically turned into code folds with a certain type. The folding could be then specified by a simple mapping from ElementKind to a FoldType. This level of support will work well for most block and markup languages, and further simplifies folding implementation.

Estimate: 3-5 days

Retrofit of existing modules

Existing languages must be retrofitted to use the new API. In most cases, the code will be simplified, as the tree structure a binding to a 'model element' (whatever it is) will be defined/provided by CSL infrastructure. Part of plugin code, which use item.getModelElement style to obtain model data will continue to run almost unchanged.

Estimate: 10 days'

GsfDataObject removal

The current GSF DataObject does not provide much useful support; it just implements EditorCookie, which have been implemented in the OpenIDE in the meantime. GsfDataObject should be deprecated and the existing languages using it should create their own Loaders and DataObjects.

Estimate: 3-5 days

Code Completion

Code completion suggestions cannot be automated; however CompletionItem creation could be supported as currently done in CSL. Interfaces in CSL should be revisited and cleared. Registration of CC adaptor must be done through normal MimeLookup. Adaptor must be provided by CSL to wrap language plugin's implementation and expose it as Editor CompletionTask and factories for it.

Estimate: 13 days


HTML module must be retrofitted to use this new adaptor; HTML completion will be then available in Java/Javadoc.

Estimate: 3 days

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo