Note: This project is obsolete and is not being maintained. It might be useful for research purposes, but is not suitable for real-world usage!
Barter is a tool for increasing the quality of applications written in Java. It allows the programmer to use design by contract and define other development aspects right in the classes and interfaces where they are relevant, as JavaDoc comments. It is essentially a code generator for AspectJ, implemented as an xDoclet task. If this is confusing, take a look at some examples below, and ye shall be enlightened.
Please visit the Barter project page at SourceForge for downloads.
Note: in method level expressions, you can refer to all the parameters passed in to the call.
Barter provides a flexible way to handle assertion failure. You can specifiy your own implementation of
barter.runtime.ViolationHandlerI
, that will be invoked when a pre-/postcondition or invariant
fails. The default implementation throws a BarterAssertionFailed
error. To specify an alternative
class, you have to set the barter.runtime.impl.TracingViolationHandler
) - this is useful if you are instrumenting an existing
application.
It is possible to selectively evaluate assertions. You just need to provide an implementation of barter.runtime.AssertionConfigurationI
, and set the barter.assertionConfig
system property to the classname. This way you gain runtime control over which assertions to evaluate on a per-class basis. You could help out by writing a nice AssertionConfigurationI that can read a configuration file.
Barter focuses on capturing the "usage policy" of classes and interfaces where they are the most convenient: right in the source code of the class. AspectJ requires you to maintain these aspects in separate files. AspectJ is very expressive, however, it can be overwhelming for common things, like verifying pre- and postconditions. Barter attempts to keep simple things simple.
Other tools, like iContract also provide design-by-contract. Barter leverages the advanced features of AspectJ, so you can define more interesting contracts/policies about a class, and add other development aspects.
Barter significantly reduces complexity of testing, but doesn't replace it. Even though assertions are now consistently enforced (and inherited), you still need to excercise the classes, and test interactions between them. And as usual, aspects come to the rescue.
Hell, yeah. You can easily use Barter and any of the following expressions in the same sentence: aspect oriented / extreme / literate programming, agile development, continuous integration, and a lot more...
The following code demonstrates simple pre- and postconditions and inheritance of contracts.
/** @barter */ interface Foo { /** * @barter.pre bar>0 * @barter.post $result!=null */ public String getFoo(int bar); } /** @barter */ class FooImpl implements Foo { /** * @barter.post !$result.equals("ugly") */ public String getFoo(int bar) { switch (bar) { // intentional bugs :-) case 10: return "ugly"; case 100: return null; } return "ok"; } public static void main(String args[]) { Foo f = new FooImpl(); f.getFoo( 5 ); // everything's fine f.getFoo( -2 ); // caller violates the precondition defined in Foo f.getFoo( 10 ); // implementation violates the postcondition defined in Foo f.getFoo( 100 ); // implementation violates the postcondition defined in FooImpl } }
Barter is released under the terms of the LGPL (GNU Lesser General Public License).
For discussing Barter, please subscribe to the barter-users mailing list. If you have any comments, questions or contributions, feel free to drop me an email.
Copyright © 2002. Viktor Szathmary