Netbeans平台: 我该使用何种注册方式呢?

我们知道在Netbeans平台中有四种注册/安装方式:

• 在模块的JAR文件的META-INF/services目录下增加文件条目
  
• 在系统文件系统下的某目录下增加文件
• 在模块的manifest文件中增加manifest条目
  
• 实现org.openide.modules.ModuleInstall类并且在manifest文件中配置, 这种方式是在系统启动时执行Java代码

我们知道模块的注册和安装其实在Netbeans平台中是同一个概念. 那么我们究竟应该使用何种方式进行注册呢?

具体情况具体分析:

如果我们正在实现其他模块提供的API, 那么这个模块应该告诉我们如何做. 如果它告诉你应该使用默认的lookup查询, 那么这就意味着使用META-INF/services机制.

如果我们正在定义自己开发的模块的API, 其他模块将实现这个API并且提供自己的类(想一下IDE的Navigator组件,不同的模块注册句柄能够按照不同的文件类型显示Navigator工具), 那么,很明显,基于manifest的注册机制首先就不在考虑范围之内, 因为在manifest条目中无法增加新类型. 程式化的注册机制也是能不用就不用, 因为弹性太差. 所以只剩下 META-INF/services机制或者系统文件系统机制. 我们可以考虑几个问题:

Is this just a simple interface or abstract class people should implement, and I just have to find them all and use them?

A: If so, use META-INF/services

Q: Will all of the objects other modules will register be used at the same time, or are there subsets for specific contexts?

A: This pertains to performance and scalability - wherever possible, you want to avoid actually instantiating the objects other modules install, and delay instantiating them until they really need to be used. Opening module jars and classloading are both expensive operations that slow things down.

If there will potentially be a large number of subclasses of your interface, try to find a way to divide them into context-appropriate categories and use folders in the system filesystem to partition contexts. For example, if you define the interface Eater, and modules will implement eaters of various foods, you probably should create folders for different general kinds of food. That way, you don't have to load a bunch of classes and create the OliveEater, BreadEater, EggEater and SausageEater just to ask them if they can eat the Pizza you came across.

Q: Is there information needed about how each object is to be used which could be provided declaratively, without instantiating the object?

A: If so, use the system filesystem, and either let modules declare file attributes thatprovide additional information, or let modules put their objects in subfolders that have contextual meaning (the same way the folder Loaders/text/x-java uses the folder path to indicate the data type objects pertain to).

Q: How many modules will actually implement my interface? How many objects from other modules will I typically be dealing with? Do I need to instantiate all of them just to display a list in the UI?

A: Displaying things in the UI is a particularly important case: You do not want to have to load a bunch of classes from a module just to show an icon and a display name for something - this pertains to anything you're going to display in the Options dialog, on Menus, or various other views.

You can solve this by using .instance files and asking that modules implementing your API use the file attributes defined for .instance files to declare the icon and display name. Then your code can just get a FileObject for each registered instance, call DataObject.find(theFileObject).getNodeDelegate().getIcon() or getDisplayName() to get the icon or display name of the object without ever having to create the object until it needs to do real work.

If you run the risk of having to instantiate all the objects in a folder just do trivial tests such as finding out how many objects of one class are in a given folder (which may contain objects of other classes), consider recommending .settings files instead of .instance files in your folders.