The generated code is not compilable. Is it a bug?

In most situations it is not a bug. JUnitdoclet does generate non compilable code whenever you should decide, what to do there. For example:

• A Singleton has a private constructor only. The generated method createInstance won't compile, but now you are aware of the problem and you can handle it the right way.
• When testing accessor methods of a floating point attribute (types float or double) the assertEquals method does require a third parameter for delta. Even if 0.0 would be ok in most cases, JUnitDoclet can't be 100% sure. But you can, so you decide. (Other tools would have decided this on your behalf, and you would have serious problems finding the cause of the problem in the very few occations when 0.0 is not ok. Our approach is different: There is no need to outsmart JUnitDoclet.)
• A constructor may require a parameter. Which value should JUnitDoclet use? You know that, so you change the code. JUnitDoclet will remember your change when regenerating.
• The default tests for accessor methods with interfaces or abstract classes try to create an instance of that interface or abstract class. You know which situations you want to test, please modify it the way you need it there. For the future, we have some more advanced ideas on this matter.

Please read "Is JUnitDoclet just another wizard?" as well.