CODEWITHSUNDEEP
javaswingstaticinner-classes
Konstantin
Konstantin

Reputation: 3055

Declare a nested class non-static for the sake of retaining a reference?

Say I have a specialized subclass of JDialog (called BrushListDialog) within which I have a JList. The list uses a custom list model (which extends DefaultListModel<String>) and a custom cell renderer (which extends DefaultListCellRenderer). For readability's sake, I nested these classes within the main class.

Normally, I'd make these classes static (which I did do for the cell renderer), but the list model class has the following method:

private boolean showRemoveConfirmDialog(Object elem) {
    int option = JOptionPane.showConfirmDialog(BrushListDialog.this,
            elem + " is a default brush type.\nDo you want to allow the removal of such entries?",
            "Remove", JOptionPane.YES_NO_OPTION, JOptionPane.WARNING_MESSAGE);
    if (option == JOptionPane.YES_OPTION) {
        TYPES.clear();
        return true;
    }
    return false;
}

As you can see, it relies on the top-level class's instance for determining the JOptionPane's display position. BrushListDialog.this, of course, cannot be called within a static context, and therefore the nested class cannot be static.

I see three ways of handling this (using null for the first parameter in showConfirmDialog is not an option):

  1. Keep the cell renderer static, but make the list model an inner class for the sake of being able to call BrushListDialog.this.
  2. Make both nested classes static, and pass the current BrushListDialog instance through the list model's constructor.
  3. Use Swing utility methods to go through the components and find an instance of BrushListDialog (this is hacky in my opinion).

So I ask you: is keeping the list model non-static for the sake of being able to access the parent dialog's instance worth it?

Source code for the two nested classes

Upvotes: 1

Views: 125

Answers (2)

Michael Berry
Michael Berry

Reputation: 72274

I wouldn't personally see the need to refactor the class to be non-static - we're not talking about a huge overhead here, just a single reference in practice. Given that, it comes down to what is the more readable and maintainable option; I'd argue that leaving the code as it is falls best into that category.

That said, if you really want to make it static, I'd go with the second option you present there over the first.

The third one you've added sounds awful - definitely stay away from that one.

Upvotes: 1

thkala
thkala

Reputation: 86333

As far as the JVM is concerned, options (1) and (2) are usually identical - the Java compiler implicitly creates a reference to the parent class and an appropriate constructor.

I would base the static vs nested decision on whether you need to use that class outside of the parent class or not. If not, then use a nested class to avoid having to write the parent reference code explicitly - but beware of implicit access delegation methods created by improper access specifiers.

Option (3) sounds like a horribly fragile hack that I would avoid at all costs...

Upvotes: 1

Related Questions