Netbeans平台: .setting文件

.settings files are similar to .instance files, with the distinction that they specify all the superclasses/interfaces of the object represented, so that some code can ask Lookup/whatever "Do you have one of these?" without needing to actually create an instance of the object. You could call .settings files "POJO persistence".

They had a brief run of popularity as Yet Another Way To Store Settings a few years ago, around when the new window system was being conceived. They're not bad, but a bit baroque. The main point was to avoid loading classes or creating objects just to satisfy a test like "how many object instances are there of X", "does this folder/lookup/collection contain an instance of X". For NetBeans, where there are lots of classes, this sort of thing really does make a difference in performance. The observation was that huge amounts of classloading could be triggered just to find out that something was not actually of use to whatever code triggered it to be instantiated.

.settings files can be used for the same purposes as .instance files - as a way of indicating that the file represents some class that should be instantiated. The main difference is that by defining all of the superclasses and interfaces of the the object they represent, it is possible for the system to delay actually instantiating the object longer - more questions about the object can be answered by the system without creating it to answer those questions.

.settings files are typically not used for registering actions in the main menu and similar places, since these actions will need to be instantiated almost immediately anyway in order to determine if they should be enabled or not. A future API for declarative actions will possibly change that, but at present, it does neither harm more good, and .instance files are simpler (and for cases where the object will be instatiated immediately anyway, faster).

Some examples:

Declaring a system option as a .settings file from an XML layer

Have a layer entry such as this:

  <folder name="Services">
    <file name="org-openide-text-PrintSettings.settings" url="PrintSettings.settings">
      <attr name="SystemFileSystem.localizingBundle" stringvalue="org.netbeans.core.Bundle"/>
      <attr name="SystemFileSystem.icon" urlvalue="nbresloc:/org/openide/resources/printSettings.gif"/>
    </file>
  </folder>

Note the url attribute - it points to a file PrintSettings.settings which is in the same directory in the module jar as the layer file - it is a relative path. That settings file will look like this:

  <?xml version="1.0"?>
  <!DOCTYPE settings PUBLIC "-//NetBeans//DTD Session settings 1.0//EN" "http://www.netbeans.org/dtds/sessionsettings-1_0.dtd">
  <settings version="1.0">
    <instanceof class="java.beans.beancontext.BeanContextProxy"/>
    <instanceof class="org.openide.util.SharedClassObject"/>
    <instanceof class="org.openide.options.SystemOption"/>
    <instanceof class="org.openide.options.ContextSystemOption"/>
    <instanceof class="org.openide.text.PrintSettings"/>
    <instance class="org.openide.text.PrintSettings"/>
  </settings>

The two things to note are that the .settings file declares many of the relevant parent classes of the object (so it does not need to be instantiated just to see what kind of object it is), and the layer file declares the icon and a resource bundle (for the display name) as file attributes .