Theoretically, yes. I ran it against the FitNesse TestSuite and couldn't see any tremendous increase of memory consumption. I mean, all this TestClass object holds are references to meta data that are already present with the class loader. There is no much additional storage needed. Therefore, let's rethink that mechanism.

Making RunBefores and RunAfters public doesn't solve the issue, unfortunately. I mean, the class is public and I already use it in the beta of the add-on, but I still need to get the annotated methods and I use new TestClass(instance.getClass()) internally. Therefore, the problem is just postponed:

```
for (int i = instances.size() - 1; i >= 0; i--) {
    final Object instance = instances.get(i);
    final TestClass tClass = new TestClass(instance.getClass());
    final List<FrameworkMethod> befores = tClass.getAnnotatedMethods(Before.class);
    statement = befores.isEmpty() ? statement : new RunBefores(statement, befores, instance);
}

```

Even worse, it generates this new TestClass for Befores and Afters and the longer I dig into this, the more places I find where new TestClass(target.getClass()) is executed. I think we would really go the right way by introducing a TestClass pool. But that's just my opinion...