Question: Is there any way to attach a contract class to an interface or class without modifying the source code of the target?

Answer: By using external contracts you do not need to modify the source code of the target interface or target class. This is especially useful for legacy systems and class libraries like the Java Class Library (JCL). For more information about this topic, please refer to the section external interface contracts and external class contracts.

Question: What is the C4JCL project about?

Answer: C4JCL is an acronym for "Contracts for the Java Class Library". The vision of this Java community project is to enrich the Java Class Library (JCL) by contracts based on the C4J framework.

Question: What about unit tests? Do I still need them when using contracts?

Answer: Yes, unit test are still essential for writing high quality software. Unit tests activate the contracts by calling the target class' methods. And contracts help to make unit tests smaller and at the same time more powerful. Contracts which obey to the six contract principles support unit tests in that way, that the software engineer writing a test class just has to follow three simple steps in order to write a thorough test:
1. Write a test for each command of the target class.
2. Write a test for each basic query of the target class.
3. Write a test for each derived query of the target class.
Having one test per method is sufficient as the contract's postconditions will check the effects of the methods automatically whether they fulfill the contract or not.

Question: I would like to use contracts not only for testing, but also for my productive system. But I do not like the idea that violating a contract will stop my whole system by throwing an Assertion Error. Is there any way telling C4J only to log the contract violation but not to throw an assertion error?

Answer: Contracts can also be activated for productive systems. You may use the C4J configuratino attribute "throw-error" to tell C4J that contract violations should only be logged and no assertion error should be thrown. For more information about this topic, please refer to the section configuration.

Question: What is the difference between the first and second generation of C4J?

Answer: The first generation of C4J - the versions 1.0 up to 2.7.5 - were not agile, i.e. native Eclipse refactoring is not supported, as name conventions like pre_ and post_ are used to link pre- and post-conditions to the target methods. The second generation of C4J - starting from version 6.0 - is agile, as no name conventions are required and inheritance relations between the class contract and the guarded class (or interface) allow the usage of the native Eclipse refactoring support.

Question: Who invented the concept of contract classes?

Answer: Jonas Bergström, Stockholm, the inventor of C4J (first generation). For more information about Jonas Bergström please refer to the topic About C4J.

Question: What is the difference between an exception and an assertion? Isn't it the same?

Answer: Exceptions and AssertionErrors are not the same thing. AssertionErrors should be thrown by class, when its specification (its contract) has been violated. In contrast to this, an exception should be thrown when exceptional circumstances occur. Exceptional circumstances like the breaking of a network link are conditions, which are not covered (or could not be covered) by the specification of the class, i.e. by its contract. In other words: AssertionErrors refer to the correctness of a class, exceptions to its robustness. And they should be clearly separated to serve these very different quality aspects.