5

I use Javassist to create a class. And in a test suite, when a second test tries to create the same class, it fails at pool.makeClass( ... ) because the class is frozen (i.e. already created via toClass().

What's the way to overcome this? Ideally, the first test should delete the class somehow - perhaps unload from the classloader - but as I read in JLS, the unload operation is not reliable.

So perhaps the workaround is to check in the class creating code whether it exists, and if it does, defrost() it, remove all members etc, and re-create it.

Any other ideas?

Or is there some reliable way to delete the class through Javassist?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Ondra Žižka
  • 43,948
  • 41
  • 217
  • 277
  • 1
    Unloading from a `ClassLoader` is not unreliable— it is impossible. A class may be unloaded if it *and* its `ClassLoader` became unreachable but since every class refers to its loader that implies that *all* classes loaded by this loader must have become unreachable too. But you can (re-)create the class using a *different* `ClassLoader`. Well, formally it is a different class with the same name (and maybe the same byte code) then. – Holger Nov 26 '13 at 19:35
  • That seems to be the answer... if you put it so, I'll accept. – Ondra Žižka Nov 27 '13 at 00:35
  • 2
    Is it Ok to remind you that you did not accept yet or am I too impatient? – Holger Jan 04 '23 at 08:17
  • I can't accept until I verify, and sorry, I was not working on that yet since asking... I will check it one day, I promise. – Ondra Žižka Feb 15 '23 at 09:42

2 Answers2

7

You cannot unload a single class from a ClassLoader. A class may be unloaded if it and its ClassLoader became unreachable but since every class refers to its loader that implies that all classes loaded by this loader must have become unreachable too.

But you can (re-)create the class using a different ClassLoader. Well, formally it is a different class with the same name (and maybe the same byte code) then. If the code executed within the test case leaves no references in the heap, the ClassLoader and its classes might be collected after the test.

Holger
  • 285,553
  • 42
  • 434
  • 765
  • Ok, But if the loaded class in second ClassLoader has references to another classes of the first ClassLoader, Should we also add all reference types to the second ClassLoader? – Pooya Oct 20 '14 at 12:45
  • 2
    @Пуя: It depends on several factors. A class defined by a `ClassLoader` C1 might have references to classes which are resolved to runtime types defined by another `ClassLoader` C2 if C1 delegates the associated class loading requests to C2. This is the standard behavior if C2 is the *parent* loader of C1. But this implies that these classes in C2 remain unchanged and that C2 remains reachable and can’t be garbage collected while C1 is in use. So if you want to modify multiple related classes at once, all of them have to be redefined in the new `ClassLoader`. – Holger Oct 20 '14 at 13:19
  • 1
    And if instances of the new class are intended to replace old ones at places where a super class or interface type is expected, that particular base type or interface *must* be resolved to the same runtime type to allow drop-in replacements. – Holger Oct 20 '14 at 13:21
0

I get the same problem, i solved it this way, may be cannot apply for your test case:

Make CtClass a private static variable of your Class.

Create a method that check's if CtClass is already built. If CtClass is not built, call the method that builds it, else, return that CtClass.

Make that all your test use the new method.

So, if you have N Test, just the first one will attempt to Built the CtClass, the rest of them will have the static CtClass Variable.

Rafael Aguilar
  • 3,084
  • 1
  • 25
  • 31