Probably the thing that is most predictable as NetBeans evolves is that more and more functionality is moving toward being declared using XML. That is to say, rather than incur the overhead of loading large numbers of classes on startup, you will define how NetBeans should instantiate classes that supply your functionality in an XML document that contains the class names and other information necessary to instantiate your objects on demand. In the long run, this translates to improved performance by reducing NetBeans’ memory footprint, and makes NetBeans a more scalable environment.

As of 3.3, system settings and visual workspaces can be declared in XML; with 3.4 or 4.0, it will be possible to declare user invokable actions and when they should be enabled entirely in XML. The goal is that eventually, no classes from a module need to be loaded in order to present that module’s functionality to a user—classes will be instantiated when the user actually begins to use the functionality.

An effort is underway to make the mechanisms of finding objects inside NetBeans as consistent as possible. Generally this means using org.openide.util.Lookup wherever possible to register objects. Formerly programmatic registries are being made declarative, as mentioned in the previous section. Other forms of object registration will eventually also be moved to use lookup: org.openide.TopManager gets more methods deprecated with every NetBeans release, and getCookie(Class) methods on Node and DataObject will one day be replaced with getLookup( ).

As of this writing, there is also an experimental effort to use JNDI to register objects by name. This style complements Lookup, which is effective for a pool of anonymous objects.

The current Datasystems API suffers from many problems. As a central API in the NetBeans architecture, it has often borne the weight of new features and suffered in complexity. It also has insoluble performance limitations that hurt scalability, and it has a complicated threading model that has produced many race conditions and deadlocks. Finally, this API is cluttered with compile-time references to most other major APIs in NetBeans, making it very hard to use as a standalone library or in a reduced application.

Since all of these problems cannot be solved by compatible extensions to the existing API, work is underway to develop a complete replacement. The new Datasystems will be conceptually similar to the current API, but have a much smaller core and use cleaner design patterns for thread safety, extensibility, and performance. A runtime compatibility bridge is part of the new implementation, permitting clients of the new API to “see” old-style DataObjects and vice-versa.

The Looks API is an API that will probably be used heavily in NetBeans in the future. The Looks API is currently available in an experimental form. Many API and user interface issues surrounding Looks have yet to be resolved as of this writing, however.

One of the key aspects of Nodes is that they don’t hold any data, they just present it—show a set of actions, properties, children, and Cookies for some other object that exists in the JVM. So more than one kind of node can represent the same data—in fact, this is exactly the kind of flexibility Nodes exist to provide.

Unfortunately, there is no standard way to switch the node used to display an object to mix and match pieces of existing nodes to create a customized appearance for the object. There is also no way for code holding a reference to an object from an unfamiliar data model to find a node that could display it appropriately.

Looks is a direct application of the MVC paradigm. Given an object from a certain data model, you can apply a Look to a LookNode displaying it, which will determine how the children, properties, and actions for that Node will appear. By changing the look on a node and combining and filtering looks, you can flexibly control the appearance of an object in the UI while keeping a clean MVC separation. You can search a registry of looks suited to a given object.

A clear example of the need for Looks is the presentation of XML data. In the DOM model, even whitespace adds elements to the document tree. For correctness, this kind of precise mapping between the data model and the document contents is absolutely necessary—a data model exists to represent its data, all of it, period. But to present a tree crammed with distracting whitespace Nodes to a user who needs to get something done is terrible UI. An intervening layer that can filter a data model and whittle it down to the content that is actually useful to the user is natural. Permitting modules that work with special XML subtypes like Ant scripts to supply optional customized appearances for these XML files is also natural. These are exactly the problems the Looks API intends to solve.

The Looks API is one of the newest APIs in NetBeans and is evolving even as this book is being written. It is important for XML support and key to the UI for the Metadata Repository. Revised Datasystems will probably use Looks natively as well. As with the Lookup API, its power is in its genericness, and as time goes on more and more modules will come to use this infrastructure to control how a data model is presented to the user.

One area that has not benefited as greatly as it could from the introduction of XML layers is actions. While they are installed in the module’s XML layer, they are instantiated when the main menu for the IDE is built—context-sensitive action classes need to be called to determine if and when they should be enabled or disabled.

One of the things being worked on for NetBeans 4.0 is a specification for declaring the constraints on an action in XML layers. Since the primary mechanism for determining the enablement of actions is the Cookies available on the activated nodes, this specification will include ways to declare the required cookies as part of the definition of the action, along with specifying that action’s display name and icon. The method to call to perform the action can be specified in much the same manner as factory methods are specified on .instance files. This should cover most cases, and in fact obviate the need for action classes at all; the method to call to perform the action can be in any implementation class within the module declaring it.

The current Actions API also does not provide an extensible way to manage context menus. The revised API should provide richer layer-based installation of all kinds of actions.

The new API and implementation are being developed as a separate module. The current actions support in the Open APIs will be left alone but deprecated in favor of the replacements.

Check the overview page for the Actions API in your version of NetBeans to determine the right way to install your actions.

Because NetBeans has become a generic platform for applications, beyond simply being a platform for development tools, any functionality in the basic APIs that is specific to their application to development tools is considered a bug. Some items in the core APIs are inapplicable except for using the NetBeans platform to build development tools, and these are gradually being deprecated and retired.

Specific items planned for deprecation are as follows:

The metadata repository (MDR) is a very impressive piece of technology that promises to revolutionize the way new language support is built for NetBeans. While it was created in order to enable refactoring support in the NetBeans IDE and to more easily implement support for additional languages, it can be a very useful tool to other applications built on NetBeans that deal with complex sets of data. For example, Project XEMO (http://www.xemo.org/), a music composition environment based on NetBeans, is using the MDR to allow users of their tool to do things such as rapidly access bar 33 of the first cello part for a symphony being edited.

Reflecting its name, the MDR is a repository of information that can be queried. It makes possible things such as computing structural diffs between versions of classes, finding all of the references to an element such as a class, and even translation between languages.

The two core concepts behind the MDR are the following:

Some aspects of what the metadata repository offers to NetBeans appear almost like black magic. With this tool, building basic support for a language involves supplying NetBeans with a metamodel of the language in question, a parser for that language (such as one generated using ANTLR—http://www.antlr.org/), and a tool to generate code, written to an API supplied by the MDR. When the metamodel is installed, a set of JMI (Java Metadata Interface) compliant interfaces are generated. But not only that—NetBeans will also generate the bytecode necessary to structurally browse source code in that language!

As this chapter is being written, the Java module is in the process of being rewritten to use the MDR. Following this will come tools for refactoring and other technologies based on it.

An acute reader of Chapter 22-Chapter 26 will have noticed many places where that module needed to implement fairly complex parse-regenerate-listen logic, all of which is conceptually similar to the logic already used in the Java module, XML module, and so on. MDR promises to unify this programming style. Score files will be defined by an ANTLR grammar and a metamodel developed in UML. Parse-regenerate code can then be generated automatically, rather than defining ScoreCookie and ScoreSupport manually. Furthermore, the metamodel will support fine-grained change notification—that is, just one note in the model changes when just one line of text is changed. This kind of generic structure diff is known to NetBeans developers as nará æi çka, or “the little smashing-together,” of old and new structural trees to find where they differ.

The metadata repository is implemented as a separable library that can be used by standalone applications outside of NetBeans. For performance, the metadata it stores is kept in B-tree files on disk, but the storage mechanism is pluggable and can be replaced with, for example, a database if desired. For detailed information about the MDR, see the MDR web site (http://mdr.netbeans.org/).

Coming in NetBeans 4.0 is a completely revamped project management system. This system has been under development for some time, and a prototype is available at the time of this writing. Historically, support for projects in the NetBeans IDE has been relatively weak, and has been reimplemented several times. The new projects module attempts to provide the Grand Unified Theory of projects, yet do so in a generic and lightweight way that will be applicable across languages and possibly in non-IDE applications.

Here are some of the primary requirements for the coming projects support in NetBeans:

An extensive set of documentation and proposals, along with the prototype, is available on the projects module pages (http://projects.netbeans.org/), which go over the details of the new projects system. In particular the http://projects.netbeans.org/openissues/DiscussionSummary.html discussion summary of the planning for the new projects infrastructure is illuminating.