Good Design-by-Contract Library for Java?

Question

A few years ago, I reviewed the DbC packages for Java, and I was not completely satisfied with any of them. Unfortunately, I did not have good notes on my findings, and I assume that everything has changed. Anyone want to compare and match different DbC packages for Java?

Answer 1

There is a good overview on WikiPedia about a contract project , at the end of the section there is a section on languages ​​from third-party support libraries , which includes a good series of Java libraries. Most of these Java libraries are based on Java Assertions.

In the case where you only need Precondition Checking , there is also a lightweight Validate Method Arguments in SourceForge under Java Argument Validation (regular Java implementation).

Depending on your problem, perhaps OVal , for checking field properties / properties is a good choice. This structure allows you to put restrictions in all kinds of forms (annotations, POJO, XML). Create restrictions for clients through POJO or scripting languages ​​(JavaScript, Groovy, BeanShell, OGNL, MVEL). And he is also involved in the implementation of contract programming .

Answer 2

Google has an open source library called contracts for java .

Contracts for Java is our new open source tool. Prerequisites, postconditions, and invariants are added as Java Boolean expressions inside annotations. By default, they do nothing, but are included through the JVM argument, theyre checked at runtime.

• @Requires, @Ensures, @ThrowEnsures and @Invariant specify contracts as Java boolean expressions • Contracts are inherited from both interfaces and classes and can be selectively enabled at runtime 

contracts for java .

Answer 3

I tested the 4J contract once and found it useful, but not perfect. You create contracts for calls and after calls of methods and invariants throughout the class.

The contract is created as a statement for the method. The problem is that the contract itself is written to a string, so you do not have IDE support for contracts or compilation time if the contract still works.

Library link

Answer 4

It has been a long time since I looked through them, but found some old links. One of them was for JASS .

Another that I used (and loved) was iContract from Reliable Systems. He had an ant task that you would execute as a preprocessor. However, I can’t find it with some Google searches, it looks like it disappeared. The source site is now a link farm. Check out this link for some possible ways to get to it.

Answer 5

There is a Groovy extension that allows Design by Contract (tm) in Groovy / Java code - GContracts . He uses the so-called closure annotations to indicate invariants of classes, pre- and postconditions. Examples can be found in the github project victories.

The main advantage: this is only one jar without external dependencies, and it can be solved using Maven compatible repositories, because it was placed in the central Maven repository .

Answer 6

I highly recommend you consider the Java Modeling Language ( JML ).

Answer 7

I think many DbC libraries were overridden by the built-in assert keyword introduced with Java 1.4:

• it is built-in, no other library is required
• works with inheritance
• you can activate / deactivate based on the package
• easy refactoring (e.g. no statements in the comments)

Answer 8

I personally believe that the DbC libraries currently available left something to be desired, and none of the libraries I looked at played well with the Bean Validation API.

The libraries I looked at have been documented here

There are many crossroads with DbC concepts in the Bean API for validation. In some cases, the Bean Validation API cannot be used as a simple POJO (Code Driven without CDI). The IMO wrapper around the Bean Validation API should be sufficient.

I found that existing libraries are a bit complicated to add to existing web projects, given that they are implemented either with AOP or with byte code tools. Probably, with the advent of the Bean API, verification of such complexity for the implementation of DbC is unreasonable.

I also documented my rant in this post and hope to build a small library that uses the Bean validation API

Answer 9

If you need simple and simple basic support for expressing your contracts, take a look at valid4j (found on Maven Central as org.valid4j: valid4j). It allows you to express your contracts with regular hamcrest templates as simple code (no comment or comment).

For preconditions and postconditions (mostly statements -> throwing AssertionError):

 import static org.valid4j.Assertive.*; require(inputList, hasSize(greaterThan(0))); ... ensure(result, lessThan(4.0)); 

If you are not happy with the default global policy (throwing AssertionError), valid4j provides a configuration mechanism that allows you to provide your own implementation of org.valid4j.AssertiveProvider.

References:

• http://www.valid4j.org/
• https://github.com/helsing/valid4j

Answer 10

I would suggest a combination of several tools:

• Java assert condition... or more advanced Groovy cousin, Guava Preconditions.checkXXXX(condition...) and Verify.verify(condition...) , or a library like AssertJ , if all you need to do is just do simple checks in your "main" or "test" code.

• You will get more features with a tool such as OVal ; it can check both objects, as well as the arguments and results of the method, you can also run checks manually (for example, show verification errors in the user interface before calling the method). It can understand existing annotations, e.g. from JPA or javax.validation (e.g. @NotNull , @Pattern , @Column ), or you can write inline constraints like @Pre(expr="x >= 0 && x <= y") . If the annotation is @Documented , the checks will also be visible in Javadocs (you also don't need to describe them).

• OVal uses reflection, which can cause performance problems and other problems in some environments, such as Android; then you should consider a tool like Google Cofoja , which has less functionality but depends on the compilation time annotation processing tool instead of reflection