Programs should consist of off-the-shelf, interchangeable, black-box components that are produced by a network of independent software companies. These components should not only come with type signatures but also with contracts that describe other aspects of their behavior. One way to express contracts is to state preand postconditions for externally visible functions. These preand post-conditions should then be validated during evaluation or possibly even during compilation. If a function call fails to satisfy its contract, the run-time system should blame the faulty program component. Behavioral contracts in the form of assertions are well-understood in the world of procedural languages. Their addition to class and interface hierarchies in object-oriented programming languages, however, raises many new and interesting questions. The most complicating factor is that objects can pass between components and trigger call-backs. Another problem is that object-oriented languages allow objects to satisfy several interfaces at once. In this paper, we analyze existing approaches to adding contracts to class-based languages and show how they blame the wrong component in certain situations for breach of contract. We then present a conservative extension of Java that allows programmers to specify method contracts in interfaces. The extension is a compromise between a consistent enforcement of contracts and language design concerns. In the future, we plan to clarify the relationship between contracts and contract violations with a rigorous analysis.