NetBeans Platform – Duplicate pair in treePair error

I have previously written about the NetBeans Platform
I’ve been using a lot recently at work and so have found a lot of pain points when using the APIs. I’ll try to document some of the more vexing problems here for other programmers who might be facing the same problem.

One problem you will probably face while using the NetBeans Platform is an inscrutable error message when you start up your application, something to the effect of:

java.lang.IllegalStateException: Duplicate pair in treePair1: java.lang.Object pair2: java.lang.Object index1: 55 index2: 55 item1: null item2: null id1: 16309239 id2: 4ecfe790

    at org.openide.util.lookup.ALPairComparator.compare(ALPairComparator.java:83)
    at org.openide.util.lookup.ALPairComparator.compare(ALPairComparator.java:54)
    at java.util.TreeMap.put(TreeMap.java:530)
    at java.util.TreeSet.add(TreeSet.java:238)
    at org.openide.util.lookup.AbstractLookup.getPairsAsLHS(AbstractLookup.java:322)
    at org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(Met…

While it’s impossible to know from this error message, this really indicates that you had some sort of exception in the initializer of one or more of your TopComponents, leading to duplicate null entries in some internal set that NetBeans Platform maintains, leading to this error message. Fortunately, there is usually a “Previous” button on the exception window so you can see what caused the real problem.

Reset windowing system in NetBeans Platform

One of the benefits of building programs on top of NetBeans Platform is the powerful windowing and docking framework it provides out of the box.  Part of this functionality is persistence; when a user closes a NetBeans Platform application, the state of all the windows is saved.  The next time the application is started, the windowing state is restored.  This is why the NetBeans IDE (which is built on the NetBeans Platform) remembers which files you had loaded and how you had your windows arranged.

During development, it is sometimes beneficial to do a ‘factory reset’ and reset the windows back to the way they would look when the application is launched for the first time. For instance, you may have inadvertently closed some windows you wanted to have open, or you opened some windows that you wanted closed and don’t feel like manually restoring each window’s open/closed state. Or perhaps you moved some of the windows in a position that made sense for testing part of the application, but now you want to test another part that requires the original windowing setup.

Clean and build

There are two main ways to do this.  The easiest way is to do a full clean and build of the project (right click on the top level project node in NetBeans and choose Clean and build)

This works fine, but it has the drawback of.. cleaning and rebuilding the project.  This can take a long time for complex projects, and is a bit overkill if all you want to do is reset the windowing system.

Remove Windows2Local

The second way of accomplishing this is to remove a folder named “Windows2Local”.  If the root of your NetBeans Platform project is located at /path/to/Foo, then the folder to remove is /path/to/Foo/build/testuserdir/config/Windows2Local

You can delete the folder any way you see fit; I usually do a

rm -rf /path/to/Foo/build/testuserdir/config/Windows2Local

from the terminal.

This folder contains the saved information about the window placement and sizes; by removing it, you force NetBeans to recreate it when the application restarts.

This method is much faster, as nothing needs to be recompiled.  It is my preferred way of resetting the windowing system back to its default state when developing NetBeans Platform applications.

NetBeans Platform – ModuleInstall ClassNotFoundException

In the NetBeans Platform, you can create an ModuleInstall class which handles the lifecycle of your module, and provides methods you can override to handle when your module is loaded and unloaded.  The standard way of creating this class is to use the wizard that NetBeans provides for this purpose, accessible by right clicking on the project and choosing New -> Other -> Module Development -> Module Installer

If you decide that you do not want to use the ModuleInstall mechanism any longer (the NetBeans Platform folks suggest you do NOT use it, as it will increase the startup time of the application), you might think you can just delete the Installer.java file that the wizard created.  Unfortunately, that’s not the case.  When you run the project you’ll get an exception like the following

org.netbeans.InvalidException:  
StandardModule:net.developmentality.moduleexample jarFile: ...
  java.lang.ClassNotFoundException:  net.developmentality.moduleexample.Installer starting from  ModuleCL@482...

The problem is that the wizard modified the manifest.mf file as well, and you need to manually clean up the file before your project will work again.

Open the manifest.mf file and you’ll see a line in the file like the following:

OpenIDE-Module-Install: net/developmentality/moduleexample/Installer.class

delete that line, and rebuild.  You should be ready to go.
In general, you need to be very careful about using any of the wizards that NetBeans provides.  They are extremely useful, but they end up changing XML files that you will need to manually edit later if you decide to refactor.  For instance, if you create an Action instance using the New Action Wizard, the action will be registered in the layer.xml file.  If you rename the action using the refactor command, the entries in the xml file are NOT modified, and you will get an exception at runtime unless you remember to edit that file.
Fortunately, the wizards are smart enough to at least tell you which files they are modifying.  It’s just a matter of remembering this further down the road when you need to refactor, move, or delete files.  Look for the modified files section in the wizard dialog:

 

Increase heap size for NetBeans Platform project

To increase the heap size in a NetBeans Platform project, you can edit the nbproject/platform.properties file and add the line

 

run.args.extra=-J-Xmx1G

 

, replacing the 1G piece with however much memory you’d like. (The other solutions I found did not work for me). Thanks to the NetBeans Forums for this solution.

If you’re curious about the -J piece, it’s necessary to ensure that the arguments are passed to the JVM rather than interpreted by NetBeans itself. This should work in general for whatever arguments you want to pass to the JVM upon launch of your NetBeans Platform project.

NetBeans Platform – how to customize the title bar and remove datestamp

Problem:

When you create a NetBeans Platform project, the title bar includes a datestamp/version identifier which is visually distracting.  You’d like to customize the title bar.

Default title versioning

Right click on the project node, and choose Find.  In the dialog box, search for {0}.

In the results, double click on the first Bundle.properties, in branding/modules…

Replace the lines with {0} with what you desire the title to be:

relaunch the program.

Updated title bar

You can also change the title at runtime with the following code:

Frame f = WindowManager.getDefault().getMainWindow();
f.setTitle("My title");

These are modified instructions based off of a thread found here.  See instructions on how to change the versioning number, if that’s what you desire, here.

 

EDIT:

If you are attempting to change the window title programmatically from an Installer instance, you’ll find that this doesn’t work.  The problem is that you are changing the title too early in the lifecycle.  Instead, you need to do the following:

// Only change the window title when all the UI components are fully loaded.
        WindowManager.getDefault().invokeWhenUIReady(new Runnable() {
            @Override
            public void run() {
                WindowManager.getDefault().getMainWindow().setTitle(windowTitle);
            }
        });

NetBeans Platform – How to handle the working directory problem

I have written previously about NetBeans Platform, but as a refresher or an introduction to my new readers, it’s a Java based framework for developing rich desktop applications.  A NetBeans Project is comprised of one or more modules.  The code in Module A cannot be accessed by Module B, unless Module B declares a dependency on Module A, and Module A explicitly declares that its code is public.  In this way, code is segmented and encapsulated into logical blocks.

In this example, I’ve created an example project, with three modules – one for the View, Model, and Controller.  (See Wikipedia if that’s not ringing a bell, and then my post about a Java Solar system for a concrete example implementation).

The project can be run either from the main project node,

or by any of the modules:

While in most cases, the behavior will be identical, there is one way in which the manner in which you launch the application matters enormously: relative paths.

The working directory is directly influenced by whether you choose the project or the module to launch with:

# Application launched from the ExampleApplication node:

Current Directory       = /NetbeansExample/ExampleApplication

# Application launched from the View module:

Current Directory       = /NetbeansExample/ExampleApplication/View

Why is this a problem?

Say my View code has a properties file it needs to read in to initialize some code.  Let’s say I store it at

/NetbeansExample/ExampleApplication/View/resources/example.properties

From within my sourcecode I might attempt to do the following:

File f = new File("resources/example.properties");

If I have started the application from the View module, then this will work fine; the current working directory is /NetbeansExample/ExampleApplication/View, as I previously said; thus by tacking on resources/example.properties, we come to a valid file.  If you launch from the main project, you will find that the file doesn’t exist, because /NetbeansExample/ExampleApplication/resources/example.properties does not exist.

How do can we handle this?

The best way I’ve found is through the use of the InstalledFileLocator class, provided by the Netbeans Platform Module APIs.

First, we need to move the .properties file from View/resources to View/release.

Once we have done that, we need to declare a dependency on the Module API in order to use this InstalledFileLocator class.  Right click on the View node and choose Properties,

In the libraries pane, click Add Dependency, and then start typing InstalledFileLocator.

The Module API should appear in the list.  Choose it and click OK.  You should see

From within your view code, you now replace code that looked like

File f = new File("resources/example.properties");

with

File f = InstalledFileLocator.getDefault().locate("example.properties", "net.developmentality.view", false);

where “example.properties” is the path to the file you’re trying to load, relative to the “release” folder, and where “net.developmentality.view” is the package name of the file in which you’re working.  The last argument is described in the Javadocs as:

localized – true to perform a localized and branded lookup (useful for documentation etc.)

I have had no problem leaving it false for my purposes.

Conclusion

I found this workaround after scouring the forums and being led to an FAQ about the LocalizedFileLocator.  It makes the code slightly more messy, but at least it works regardless of how the user or developer launches the application, which cannot be said for the standard way of specifying relative paths.  It is a very hard thing to search for, so hopefully someone running into this problem using NetBeans Platform finds this post.

NetBeans: Hang after debugging session

I’ve run into the issue a lot where I will use the debugger, stop the debugger, attempt to run the project again, and it just hangs.  I always forget how to solve the problem so I figured I’d write it down for posterity.

In the build folder of your project, look for “testuserdir/lock”.  If it exists, delete it.

I find the problem manifests itself when debugging Netbeans Platform modules; when you clean and build the module no errors or warnings are reported, but when you clean and build the main project, you get an error:

/Applications/NetBeans/NetBeans 6.8.app/Contents/Resources/NetBeans/harness/suite.xml:451: Will not delete /Users/nicholasdunn/Desktop/project/build/testuserdir because /Users/nicholasdunn/Desktop/project/build/testuserdir/lock still exists; kill any running process and delete lock file if necessary
BUILD FAILED (total time: 0 seconds)

NetBeans Platform Tip #2: Persisting state in TopComponents

Given the fact that NetBeans remembers the size, location, and layout of all your TopComponents, it isn’t too surprising that there is an easy mechanism for persisting state information.  Unfortunately it’s not immediately obvious; if you don’t stumble onto the right resources, you might be led to believe you need to deal with the Preferences API or writing to a database or some other flat file, and reading it later.  Fortunately it’s easier than that.  Assume we have a list of Strings we want to remember between invocations of our top component; somehow we get them from the user (the details of that are not important here), and we’d like to remember them.  The secret is in the writeExternal and readExternal methods, which are called when the TopComponent is serialized (saved) and deserialized (loaded).  Also make sure the persistence type you return is TopComponent.PERSISTENCE_ALWAYS; otherwise NetBeans will not attempt to save your TopComponent between invocations of your app.

public class TestTopComponent extends TopComponent implements Serializable {

    private List<String> strings = new ArrayList<String>();

    public EngineeringTableTopComponent(Collection<String> toSave) {
        initComponents();
        this.strings.addAll(toSave);
    }

    public EngineeringTableTopComponent() {
        this(Collections.EMPTY_LIST);
    }

    public void initComponents() {
         // Create GUI
    }

    @Override
    public int getPersistenceType() {
        return TopComponent.PERSISTENCE_ALWAYS;
    }

    /**
     * Save the state of the top component, including which properties are displayed
     * @param oo
     * @throws IOException
     */
    @Override
    public void writeExternal(ObjectOutput oo) throws IOException {
        super.writeExternal(oo);
        Object toWrite = new NbMarshalledObject(strings);
        oo.writeObject(toWrite);
    }

    /**
     * Restore the state of the top component, including which properties are displayed
     * @param oi
     * @throws IOException
     * @throws ClassNotFoundException
     */
    @Override
    public void readExternal(ObjectInput oi) throws IOException, ClassNotFoundException {
        super.readExternal(oi);
        NbMarshalledObject obj = (NbMarshalledObject) oi.readObject();
        strings  = (List<String>) obj.get();
    }
}