Extreme Java When vanilla Java is not enough


From Swing to NetBeans Platform (part 2)

In my previous post, I put an old Swing application to run as a NetBeans Platform Application. After some refactoring, I got it working, nicely integrated to NB's file editing support. Now, I'm converting their Tileset Manager from a JDialog to a TopComponent sensitive to global selection.

I started with a new "TileSet Manager" module, then moved the TSM dialog to that module and changed it to a JPanel. After adding a TC and putting the TSM Panel on it, half-work was done. Thanks to the Swing skills of Tiled team, the next step was a piece of cake. After tracking the global selection, I only made the right "setEditor" on their manager and voilá! The tileset table changes according to the selected file! God bless the NetBeans Team!

It's already very cool, but I want more. Their version uses JTables and lots of buttons on this dialog. What about using NBP's ExplorerManager? Easy as 1-2-3. I replaced the TSM Panel with a BeanTreeView plus some Nodes and the ExplorerManager (just like FeedReader tutorial). I could use OutlineView to keep the table look, but I plan to add some depth on this tree later. And, instead of a table with two columns, I use a nice tree view with HTML display name:

Migration of actions started by the most complex one: Delete. Adding the action to the ExplorerManager and their JButton's actionPerformed to Node.canDestroy and Node.destroy did the trick.

There were other actions, like "Save As" and "Embed". All of them were easy to convert. I cut the code on "actionPerformed", pasting it on new actions. I put them on NB layer and used this snippet to convert them to Node.getActions:

public Action[] getActions(boolean context) {
  List<Action> list = new ArrayList<Action>();
  for (Object obj : Lookups.forPath("...")
      .lookupAll(Object.class)) {
    if (obj instanceof JSeparator) {
    if (obj instanceof Action) {
      list.add((Action) obj);
  return list.toArray(new Action[list.size()]);

From Swing to NetBeans Platform (part 1)

I don't remember how, but I found a nice tile map editor named Tiled. It has two versions: QT and Java. The former is their "trunk", while the latter is their "legacy". Too bad, it was a nice piece of software.

Nonetheless, their screenshot made me think: "this MUST be refactored to be a NetBeans Platform App". There's a lot of dialogs, splitpanes, toolbars, etc. It is an waste of time doing that on Swing.

Let's see the situation of the source code:

  • Almost abandoned - only a couple of commits this year. Check.
  • No plans to keep it up-to-date - blame the QT version. Check.
  • GPL licensed. Check.

That's the recipe that allows me to play with this cool application, refactoring it from Swing to NBP.

I started by cloning their Mercurial repository (cool, I can keep their SCM history). Then, I run it with NetBeans. Now that I know it works, I deleted the project metadata (build.xml and nbproject) and created a new NBP-based Application. Their old source on "src" I moved to a new "src" inside a "Legacy Integration" module.

Now, the fun part: remove the junk. There's a lot of cool features on the original project, but almost all of them NBP does too:

  • Plugin support, with custom classloader and other stuff. Deleted
  • Multiple filetype support. Imploded to support only native formats
  • Command line parsing. Split in a new module, using NB own support

Up to this point I have: nothing! After all, that application was SDI with JFrame. To make the editor working again, I created a "TMX File Support". The first version of TMXDataObject contained only an OpenCookie that opens a TopComponent. In this TC, I embedded the Tiled JFrame components (editor, menubar, statusbar, etc). This ugly workaround worked pretty nice! And the Application is now MDI!

After some cleanup, it was pretty easy to migrate their NewMapAction to NB layer.xml, the SaveAction to a SaveCookie and SaveAsAction to SaveAsCapable. In a matter of minutes, their editor was fully integrated with NB file support, including the conditionally enabled "Save" button.

Next step is the Tileset Manager. Currently it is a JDialog, and I will migrate it to a TopComponent (like Navigator).

Stay tuned!


Using NetBeans Parser API with Navigator API

So, you created a new language on you NBP-based application and associated it with a new file type. Now, you need to show your parse result on your Navigator panel. I haven't found a standard way to do so, but the best shot so far was adding the parser result to the DataObject's CookieSet. This way you can lookup it in your NavigationPanel's panelActivated. Easy and fast.


File attributes on layer.xml

When registering files on NBM's layer file, you can define attributes, too:

<file name="my-pkg-MyClass.instance">
  <attr name="mystr" stringvalue="value"/>
  <attr name="myint" intvalue="1"/>
  <attr name="mymethod"

They are avaliable as attributes of FileObject (through getAttribute). You can also use special attributes "instanceClass" to define a different class to instantiate or "instanceCreate" to define a factory method. This factory method can receive a map of attributes. I'm using it to customize a generic DataLoader:

public class MyLoader extends MultiDataLoader {
  private MyDataLoader(String secondaryExt) {
    this.secondaryExt = secondaryExt;
  public static build(Map<String, Object> attrs) {
    return new MyLoader(attrs.get("ext").toString());

NetBeans Platform + JPA + Derby embedded

If you want to use NetBeans Platform and JPA together, there's a great tutorial on NB's site. Unfortunatelly, it explains how to do it with an external database and using an external JAR for your entities.

If you want to have a entity module with your classes (instead of an external JAR and a library wrapper), no big deal - it works! You can follow GJ's tutorial, but you will create a module project instead and you will not have NB's wizards to help creating entity classes.

I also created a module install on my Derby wrapper, with this line:

FileUtil configRoot = FileUtil.getConfigRoot();

This defines where Derby will create database files (user's dir, in this case).

BTW, if a "no suitable driver found" is thrown, you forgot to add a dependency between JPA wrapper (EclipseLink, TopLink, OpenJPA or Hibernate) and JDBC wrapper.