My solution to keeping track of Piece instances would be a enum PieceRepository.

import java.util.ArrayList;
import java.util.List;


public enum PieceRepository {

    INSATNCE;

    private List<Piece> pieces;

    private PieceRepository() {
        pieces = new ArrayList<Piece>();
    }

    public void addPiece(Piece piece) {
        pieces.add(piece);
    }

    public List<Piece> getPieces() {
        return pieces;
    }

}

Piece sample code:

public class Piece {

    public Piece() {
        PieceRepository.INSTANCE.addPiece(this);
    }

}

Some other class that extends Piece:

public class HalfPiece extends Piece {

    public HalfPiece() {

    }

}

And test:

public class TestMain {

    public static void main(String[] args) {

        new Piece();
        new Piece();
        new Piece();
        new HalfPiece();

        System.out.println(PieceRepository.INSTANCE.getPieces().size());

    }

}

Output is:

4

Edit: Used http://stackoverflow.com/questions/3635396/pattern-for-lazy-thread-safe-singleton-instantiation-in-java To make repository thread safe.

You will need to maintain a list of what things are in your pieces package manually.

Best way is to do what you do, that is add them one by one to some sort of container.

However selecting them is a separate task from adding them to your tree

static List<Piece> piecesIWant() {
    List<Piece> pieces = new ArrayList<Piece>();
    pieces.add(new Add(0,0));
    pieces.add(new Subtract(0,0));
    return pieces;
}

void createTree(Collection<Piece> wantedPieces) {
    DefaultMutableTreeNode arithmeticNode = new DefaultMutableTreeNode("Arithmetic");
    for (Piece p : wantedPieces) {
        arithmeticNode.add(new DefaultMutableTreeNode(p));
    }
}

I have attempted something similar to this, that (mostly) got rid of the hardcoded registration problem, which was based on using static initialization blocks and class loaders.

In my case, each class was responsible for generating a binary encoding for some data, in varying formats.

First of all, I had a class that would accept the encoder definition

class Encoders {
    public void addEncoding(String identifier, Constructor<Encoder> ctor){
        // ...
    }
}

Each encoder class looked something like this:

class MyEncoder {
    static {
        Encoders.addEncoding("MyEncoding", MyEncoder.class.getDeclaredConstructor());
    }

    public MyEncoder(){
        // ...
    }
}

Then to load them all, I iterated through the classes specified in an external config file containing a list of the binary class names for each encoder. One could do something even fancier by processing these configs in different files.

public void loadEncoders(Logger log){
    try(BufferedReader reader = new BufferedReader(new FileReader("encoders.txt"))){
        loadClasses(reader, log);
    } catch (FileNotFoundException e) {
        log.log(Level.WARNING, "Could not find encoders list!", e);
    } catch (IOException e){
        log.log(Level.WARNING, "Could not read encoders list!", e);
    }
}

public boolean loadClasses(BufferedReader reader, Logger log){
    ClassLoader loader = ClassLoader.getSystemClassLoader();
    boolean success = true;
    while(true){
        String name = reader.readLine();
        if(name == null) break;

        try {
            loader.loadClass(name);
        } catch (ClassNotFoundException e){
            log.log(Level.WARNING, "Unable to find " + name, e);
            success = false;
        }
        return success;
    }
}

Depending on your needs, there are ways around this but, sadly, none of them will work automagically, and they may require some effort. Only you can decide what's warranted and what's overkill.

From what I can see, you're building a GUI for chips or circuits. I imagine you want to provide a component that lists gates for your users, much like the component buttons in WindowBuilder or Matisse. Let's see how these solve the problem.

Asking for directions

WindowBuilder comes with the standard Swing and AWT components out of the box. Since these will be in pretty much any Java distribution, they can just add the components manually once. It's a bit tedious to do, but you only need to do it once (and maintain forever).

What about components that aren't standard, like when your users make stuff of their own? Well, there are three main ways that jump out:

1. Ask your platform for an index. For WindowBuilder, this is Eclipse, which has information on loaded and available classes. For stand-alone Java applications like GUIs, this will involve scanning your class path.

   Also available for your needs is java.util.ServiceLoader. If you or your users can be bothered to make an index file in provided JARs, ServiceLoader will do some lifting for you.

2. Ask your user for a JAR and scan it. Open it up, check each class whether it extends Piece, and add/flag it if it does. This covers archives that aren't on the class path.

3. Ask your user for a class name and let the ClassLoader fetch it. This covers classes that are not in a JAR or on the class path.

Once you have potentially valid types, it's time to figure out how to instantiate and present them.

Reflecting on what you found

So suppose you have a list of classes that extend Piece and we may or may not be able to accommodate. Unfortunately, Piece.getInstance() won't help us here: to be overridable, it needs to be an instance method; to use an instance method, we need an instance. Egg, meet Chicken.

Much like we'd do with JavaBeans, we can gleam some information from your classes using reflection and convention:

1. Find a public static method matching a specific signature, e.g. a factory method. create(), createInstance(), and so on, are good candidates. Document what you accept, and in what order you search.

2. Find all public constructors, and try to invoke them with 'default' values. What constitutes default values depends a bit on context. We may need to ask our users to provide values for us. Again, document what is supported, and how you will try instantiating.

After we've done all this, we pretty much have what we need to allow our users to build whatever they want. But GUI builders usually don't forget coordinates to custom components after reloading, so how do we save our users the trouble not to have to input them over and over again?

Maintain a registry (optional)

We should save two things about found implementations: (1) their class name, so we can find them, and (2) how to instantiate them. How you want to save this is up to preference; I'd lean towards an XML file because that allows enterprising users to tweak, change, or add others if we somehow fail to find them.

<?xml version="1.0" encoding="utf-8"?>
<pieces version="1">
  <piece>
    <className>com.acme.pieces.Add</className>
    <factory-method name="create">
    </factory-method>
  </piece>
  <piece>
    <className>com.acme.pieces.Explode</className>
    <constructor>
      <arg type="int">10</arg>
      <arg type="int">10</arg>
    </constructor>
  </piece>
</pieces>

That's really all we need to store. (Do version your data format, even if you plan on only ever supporting one.)

Worth it?

If we're going to be user-friendly and fail-safe and all these beautiful things, this is a lot of effort, and possibly even overkill. This feels like a basic enough issue that there must be some projects with some support for it (I'm looking sideways at Spring and Apache, here).

If you're just going for a fixed list of things that you want available, manually maintaining a list in code is pretty much your simplest, if sometimes tedious, solution. It's not shiny or pretty but it's quick and it may meet your needs.