Answer for Netbeans Teaser

In this blog entry I showed the following screenshot:

Note: This functionality is available in recent (last weeks) NetBeans IDE build with JDK 6.

Here is the explaination of what is going on:

The screenshot shows the debugger stopped at a line in the contructor of class Foo. Foo has a member variable bar of type Bar which is an inner class of Foo. The Local Variables window show the this instance of type Foo and bar field of type Bar. Nothing new or interesting so far. Right clicking on the bar field's row in the Local Variables window reveals the Show References action in the popup menu. Invoking the Show references action shows the Instances window. The Instances window is the interesting bit. The Instances window shows three panes - Instances pane, Fields pane and References pane. The Instances pane shows all instances of type Bar. The Fields pane is analogous to the Local Variables window and shows the structure of the instance of Bar. The References pane shows the references to the selected instance of Bar. In this example the only reference to the instance pointed to by the bar field is the instance of Foo. I think this is huge! What this means is that I can look at the references to the objects while I am debugging my program. The ability to look at the references has been traditionally available in the Profiler tools such as HeapWalker. The differences is that the HeapWalker tool shows the static information from a heap dump file. The Instances window above shows the information from a live VM that is being debugged. This brings the power of Profiler like tools to the NetBeans debugger. I think this is very synergistic. For example, normally one can only look at the objects visible from the current stack frame in the Local Variables window. Using the Instances pane in the Instances window now it is possible to look at other instances of any reference type that may not be directly visible from the current stack frame. Similarly by using the fix&continue feature of the debugger it will be possible to debug memory leaks in certain scenarios.

There is also a Classes window which can be invoked using Windows:Debugger:Classes action. This is analogous to Classes window of the HeapWalker.

Small nit:

• The #nnn numbers shown in the Instances pane of Instances window are not the same ad Unique Id# shown in the Local Variables window. I have already filed an RFE to display the debuger assigned Unique ids in the Instances window so that it will be easy to corelate the information those two windows.
• The Fields pane shows information very similar to the Local Variables window. The two GUIs could be better unified.

Going forward I hope to see more and more integration of NetBeans debugger and profiler which will help integrate the profiling in the regular edit-compile-debug cycle.

NetBeans Teaser

What is going on in the following screenshot?

Hint: Study the areas marked by red rectangles.

Answer in the next blog entry.

KeyBinding Explorer module on Plugin Portal

I have started to move my modules to NetBeans Plugin Portal. There you will find the Key Binding Explorer module which let's you explore the active key bindings in NetBeans IDE. Here are the screenshots:

Search based on key bindings sequence

Type the key sequence in the textfield on top of the first column to see what it is bound to.

Search based on raw keys (no modifiers)

Type the keys (without modifiers) in the textfield on top of the second column to see what the they are bound to.

Search based on action name

Type the name of the action in the textfield on top of the third column to see what key sequence is bound to it. You can use regexps in the action name.

You can sort the columns. You can do primary, secondary and tertiary sort by control clicking on the column headings. You can generate the html or xml file. You could use an xml+XSLT to generate nice PDF reference card. If anyone develops such a tool please send me the information.

You can download the plugin from here.

Sources

DISCLAIMER: This module is experimental. So no guarantees. Use the module at your own risk.

How is it implemented? Java Editor Hint: Change variable type fix

In the previous entry I talked about the Change Variable Type fix. In this entry I will talk about how it is implemented.

Registration of the factory

Like many other features in NetBeans the hints/fixes/suggestions are implemented using a factory mechanism. The factory is registered in the module's layer file like this:

<filesystem>
  <folder name="org-netbeans-modules-java-hints">
    <folder name="rules">\
      <folder name="errors">
        <file name="org-netbeans-modules-javahints-ChangeTypeCreator.instance"/>
      </folder>
    </folder>
  </folder>
</filesystem>

The factory is registered under the org-netbeans-modules-java-hints/rules/errors folder because it creates a fix for certain compilation errors such as type mismatch of the left and right side of a vatriable declaration statement.

Implementation of the factory

As the user edits the source code, the Java editor incrementally runs the javac in the background. As the javac emits compilation errors the editor shows the red squiggly lines. Aside from that it also invokes the factories registered to handle the particular compilation errors. In this case org.netbeans.modules.javahints.ChangeTypeCreator is one such factory. The ChangeTypeCreator implements the interface org.netbeans.modules.java.hints.spi.ErrorRule. This intreface essentially has two important method:

    /** Get the diagnostic codes this rule should run on
     */
    public Set<String> getCodes();

    /** Return possible fixes for a given diagnostic report.
     */
    public List<Fix> run(CompilationInfo compilationInfo,
                         String diagnosticKey,
                         int offset,
                         TreePath treePath,
                         Data<T> data);

The getCodes() method essentially indicates the set of compilatioin error codes that are handled by the factory. The ChangeTypeCreator handles:

compiler.err.prob.found.req
compiler.err.incomparable.types

These codes are part of standard error codes emitted by the javac.

In the run(...) method of ChangeTypeCreator,enough information about the context in the editor is passed in. The ChangeTypeCreator uses the APIs to determine the types of expressions on the left and right side of a variable assignmenets and returns an instance of org.netbeans.modules.javahints.ChangeTypeHint. This instance is used to populate the list of fixes that appear as actions in the light bulb pop up menu in the left margin of the editor.

Implementation of the Change variable type fix

The ChangeTypeHint which implements org.netbeans.spi.editor.hints.Fix . It provides the text of menu item which is returned from:

    public String getText()

The actual fix is implemented in the method:

 public ChangeInfo implement()

using the Java Source APIs.

Java Editor Hint: Change variable type fix

In NetBeans 6.0 Java editor supports writing custom, so called, fixes, hints and suggestions. These appear as a light bulb icon in the left margin of the Java editor. For example, in the code below:

100        List list = ...;
101        :
:
110        String s = list.get(0);

the type of the variable s does not match the type of the expression list.get(0). In such cases a light bulb icon appears in the left margin of the Java editor on the line 110 of the code. Clicking or invoking the fix action reveals a menu item saying Cast ...get(...) to String. Selecting the menu item changes the code on line 110 to:

110        String s = (String) list.get(0);

This is all well and good. However what if you wanted to adjust the type of the variable s to Object. It is very easy to write such a fix and that is what I have implemented.

With this fix, I always write my variable like this:

110        int i = .....; // some expression that return a type I don't know - assume it is RefactoringPluginFactory

Select the hint to change the type of i to the correct type.

110        RefactoringPluginFactory i = ....; 

(I know, I know some may say why I am doing this...because I am an extremely poor typist :( )
Then I quickly delete i and use the smart variable name proposal code completion to get:

110        RefactoringPluginFactory refactoringPluginFactory = ....;

I have added the fix to the Experimental Java Hints (contrib/editorhints/java) module. You can get the module from Development Update center.

Sources

DISCLAIMER: This module is experimental. So no guarantees. Use the module at your own risk.