Forgot your password?
typodupeerror
Google Java Programming

Google Brings Design-By-Contract To Java 134

Posted by Soulskill
from the putting-a-hit-out-on-bugs dept.
angry tapir writes "Google is developing a set of extensions for Java that should aid in better securing Java programs against buffer overflow attacks. Google has announced that it open sourced a project that its engineers were working on to add a new functionality into Java called Contracts, or Design-By-Contract. 'Contracts exist to check for programmer error, not for user error or environment failures. Any difference between execution with and without runtime contract checking (apart from performance) is by definition a bug. Contracts must never have side effects.'"
This discussion has been archived. No new comments can be posted.

Google Brings Design-By-Contract To Java

Comments Filter:
  • by goofy183 (451746) <eric.dalquist@gP ... .com minus punct> on Friday February 11, 2011 @11:04AM (#35175208) Homepage

    There have been several projects that have tried to do this before but the developers never saw it through. When annotations were added in JDK5 this was one of the features I've been looking for. Being able to define invariants on the interface will make implementations much more safe and consistent!

    • Re: (Score:2, Insightful)

      by mark-t (151149)
      I'm probably digressing OT here, but my own main beef with annotations in Java is that they don't actually serve any real functional purpose that I've ever been able to see beyond documentation, while at the same time they break compatibility with older Java compilers which are unable to compile any source code with annotations in it. The exact same effect could have been achieved by having the annotations be embedded in comments, similar to Javadoc, and would not have broken source compatibility.
      • Re:Finally! (Score:4, Insightful)

        by The Snowman (116231) on Friday February 11, 2011 @03:32PM (#35179780) Homepage

        I'm probably digressing OT here, but my own main beef with annotations in Java is that they don't actually serve any real functional purpose that I've ever been able to see beyond documentation, while at the same time they break compatibility with older Java compilers which are unable to compile any source code with annotations in it

        Considering annotations are in Java 5, and Java 5 is no longer supported by Sun/Oracle, I don't really care about Java 4 and earlier compilers.

        Annotations can have great benefits in running code, but you need to use reflection. For example, the product I develop at my job uses them for technical designs. We use a custom annotation to mark up classes that are not yet implemented, so we can design a process flow and actually run through it in the application before it is implemented. A factory pattern class replaces these classes with a generic, configurable replacement on the fly. Often, the most difficult part of the process is defining it, not implementing it. This alone has saved us hundreds if not thousands of hours of time fixing bugs and definitely fewer builds into QA.

      • by Björn (4836) *
        Annotations are used extensively in enterprise Java at runtime.
      • On the contrary, annotations are entirely functional, not decorative. Annotations cannot be in comments; while the code would compile, it wouldn't run correctly (if at all) since the behaviors requested by the annotations would be missing. Look into JAXB and EJB for how annotations can be used well.

      • by Anonymous Coward

        Anotations have plenty of purposes... I use them so I don't have to deal with the metadata XML hell that used to be j2ee... Can you say EJB resource injection without having to look at two separate files at the same time? It makes reading the code a lot easier because you don't have to switch what you're looking at all the time to make sense of it. I know this is a "holy war" type thing, but honestly, annotations have made my life a lot easier because now I don't have to maintain tons of XML files on top of

  • BOf in Java? (Score:3, Insightful)

    by Lord Ender (156273) on Friday February 11, 2011 @11:04AM (#35175218) Homepage

    I did not realize buffer overflows were a problem for apps written in Java. Java has built-in "generic" dynamic data structures which should be suitable for 99% of the software any of us write. Why would we ever be manually managing memory in Java? Doing so should be "considered harmful" to a far greater degree than goto statements.

    • Re:BOf in Java? (Score:5, Informative)

      by goofy183 (451746) <eric.dalquist@gP ... .com minus punct> on Friday February 11, 2011 @11:08AM (#35175310) Homepage

      I think that is a poorly written summary. You can't (in pure java and ignoring JVM bugs) overflow buffers. You can however forget to do sanity checking on inputs based on the business rules of your app. That is where this will help. Codifying even simple things like "The argument should never be null" in an annotation on the interface definition helps both document and consistency for implementations of that interface.

      • by medv4380 (1604309)
        It's not a poorly written summary. TFA actually mentions that the reason for implementing this is to address the Buffer Overflow attacks that have been used against the JRE. Even though google is well meaning in what they are doing I don't think they understand where the problem is at. Most of the buffer overflow attacks were targeting the JRE and that only has a small set of code written in java. The vast majority of the JRE is written in C and C++. Adding Design by Contract standards to Java won't f
        • Re:BOf in Java? (Score:5, Informative)

          by goofy183 (451746) <eric.dalquist@gP ... .com minus punct> on Friday February 11, 2011 @11:59AM (#35176124) Homepage

          The problem is TechWorld having no idea what this tool is for. The announcement by Google http://google-opensource.blogspot.com/2011/02/contracts-for-java.html [blogspot.com] never mentions the word "buffer" and accurately describes this as a tool for pre/post validation of method arguments and return values. Some how TechWorld decided to tie in JVM level buffer overflow issues with a pure Java DbC tool, anyone actually familiar with Java knows at a glance that the two are unrelated.

          • by Speare (84249)

            When I heard of Designing by Contract, I recalled a similar public speaking maxim. The maxim goes, "Tell them what youâ(TM)re going to say. Say it. Then tell them what you said." The idea is that reinforcing and rephrasing things will get your point across more clearly to the audience.

            Designing by contract is something seen in the Eiffel language. I haven't looked at it in years, but it seems to follow this maxim religiously. Every function or method had three sections: tell the compiler what you

            • by gorzek (647352)

              This seems like the sort of design paradigm that would be useful in situations where you cannot afford any defects. Having to write the same code 3 different ways (or rather, write it 2 ways then write a test to verify it) at least permits automated consistency-checking without having to involve other people.

              Sure, the time spent writing more code isn't free, however this can reduce time spent testing (by QAs), and might obviate code review by peers since the code already "reviews" itself.

              One of the issues I

          • by GooberToo (74388)

            accurately describes this as a tool for pre/post validation of method arguments and return values

            Now that makes more sense.

            As a side note, Python is able to do this by means of decorators and now with annotations in Python 3. Here's some example code. [activestate.com]

    • They're not. It's the usual un-edited crap in the summary. You cannot possibly do a buffer overflow in the traditional sense of the word in Java. You can in C#.
      • by pla (258480)
        You cannot possibly do a buffer overflow in the traditional sense of the word in Java.

        Ahahahahaahhaa...

        Heh.

        <snrrrrk>

        You Java guys. Always cracking me up. "But it runs in more places"... Than GCC used to compile the JRE? "But you can't overflow buffers"... Not within the language (why would you want to compromise a sandbox?), but via the implementation (thus giving "real" access outside the sandbox).
    • If you took time to read TFA you may have come across this little tidbit.

      "One of the oldest techniques in the attacker's virtual arsenal, buffer overflows remain a problem. In December, Microsoft identified 2.6 million possible attacks that could be waged using a stack-based buffer overflow in the JRE (Java Runtime Engine)".

      • by owlstead (636356)

        Yes, and if you dig any further you find out that it is a Java *deployment* issue which exploits features of the underlying operating system. Funny enough, only Windows is affected, who would have guessed? And since nobody in his right mind is going to use Design By Contract for deployers, you can safely ignore the buffer overflow argument used in the article. Pure FUD.

    • I did not realize buffer overflows were a problem for apps written in Java.

      In general, they're not. However, there have been a few bugs in the JRE found over the years that resulted in stack buffer overflows which could have led to an exploit . AFAIK, all of these know bugs have long been fixed. However, there is always the potential that a new bug could be found.

      DBC is not about managing memory for Java, it's simply a tool (using annotations) to allow validation (think ASSERTs) of arguments to methods and the values the methods return.

      • Funny thing is that since 2002 (Java 1.4) the assertion mechanism is a standard language feature - and intended for Design by Contract [oracle.com]

        And so the reinvented wheels of redundancy keep on turning and repeating themselves over and over again, but at least we can now assert that they were turning, will be turning and didn't stop turning in several ways...

    • by hey! (33014)

      Well, bugs in a particular JRE aside, is your system *exclusively* implemented in Java? You don't, say, save the data to a database that isn't 100% Java, or anything like that? That said, it seems to me that buffer overflow is a relatively minor issue. In any case, if you read TFA, you'll see that contracts aren't about input checking, which should be done in UI code.

      It sounds to me like DbC makes an interesting complement to unit testing. One of the hollow feelings I always feel in the pit of my stomach w

  • Trademarked (Score:5, Interesting)

    by D Ninja (825055) on Friday February 11, 2011 @11:08AM (#35175296)

    Actually, Google is bringing Programming by Contract to Java. Design by Contract is trademarked by Eiffel Software (and Bertrand Meyer).

    • This only applies to the US. The rest of the world can use that moniker. This is because the trademark only applies there. Sorry.
    • Holy moly what a crappy trademark. It will fail the moment it is challenged. That term has been in common use for many many years. That's not a trademark, it's bad lawyering work.

      • That programming language is 25 years old now so of course its catch phrase have been used for a long time.

    • by H0p313ss (811249)

      Prime example of why Eiffel has failed to catch on in the mainstream.

      • Eiffel has failed to catch on because of the steadfast belief of Mr. Meyer that his "software development methodology" is the sole right and proper one, and everyone who disagrees is an idiot. If you've read some papers from the man, they can largely be summed up as "This is how we do things in Eiffel; it's the right way, and Java (C++, ...) are very bad languages that no-one should use because they don't do it like that".

  • I'm sure Oracle will be only too happy to work with Google to add this to the JDK, right? Right?
  • Fail (Score:5, Insightful)

    by nicholas22 (1945330) on Friday February 11, 2011 @11:09AM (#35175324)
    It is a String-based implementation, which is awful in terms of consistency, type-checking, etc. and vulnerable in code refactoring. I would stay away or use something more type-safe and IDE-safe.
    • by worip (1463581)
      I agree, does this not rely on the developer actually specifying the contract? Also, would it not be possible to have bugs in the contract itself?
      • I agree, does this not rely on the developer actually specifying the contract? Also, would it not be possible to have bugs in the contract itself?

        What would it mean to have a bug in the contract?

        • A bug in a contract is like a bug in a specification - it might be harmless but it means you are allowing potentially dangerous/poorly working implementations to be given the rubber stamp of approval.

          Contracts are effectively ways of saying "the state of the program before this operation will adhere to rules P" and "after you do this operation I promise that the state of the program will adhere to rules R". Sometimes it is possible to check whether the rules would be broken using a static checker (weeding o

          • The idea of contracts is that clients write their code to work with anything which fulfills the contract. So let's say you have some client code written, but then determine that there's a bug in the contract. What does this mean? The client code is either written for the "buggy" contract, or the client code was ALSO buggy and written for the intended contract. At that point, it seems that the client has failed to grasp what the contract is in the first place. The idea is that the contract cannot be buggy, s
            • by p3d0 (42270)
              The "definition of correct" is the system working the way it should. I'm not sure what you're suggesting here: that a system should stick with the original, possibly flawed, contracts rather than fix them to operate properly? That once you make an error in a contract, you should live with it forever? I fail to see how that perspective is helpful or realistic, and, forgive me if I'm wrong, but I suspect you may be lacking in practical experience with Design by Contract.
              • Guilty as charged. Still, my point was that in the case you describe, there is a problem with the design of the system, not merely the contract.
                • by p3d0 (42270)
                  Ah I see what you mean now. Actually I think you've hit upon the key feature of Design by Contract that most people miss. It's not just tossing assertions all over your code. It's a design discipline that shapes the way you write the system, and that's why it's good at finding design problems.
        • by p3d0 (42270)

          Contracts can easily have bugs. That shouldn't be too hard to imagine. You could easily have a postcondition "ensure item[index] == 123" when "index" is out of bounds, or when you meant to write "0x123", or when the array is actually called "items".

          The fact that contracts can have bugs doesn't negate their value any more than the same fact about software negates software's value.

    • Nah... stringly-typed languages are perfectly safe.

  • Too fragile (Score:3, Interesting)

    by lehphyro (1465921) on Friday February 11, 2011 @11:17AM (#35175442)
    Using strings instead of compiled code is too fragile. org.apache.commons.lang.Validate or com.google.common.base.Preconditions are much better for this kind of validation.
    • by robmv (855035)

      They are written using a the annotation syntax, they look like a String, but using the annotations processor of the Java 6 compiler that string is compiled to Java bytecode, and by the way, what is code? Strings... from the FAQ [google.com]

      Is the contract code compiled? I only see strings in annotations!

      The annotation processor takes care of compiling the strings into bytecode and runs along the Java compiler, so you get static syntax and typing errors at compile time, as usual.

  • Java does not have buffer overflows unless the JVM has a bug, or you're calling out to unsafe code via JNI. The lack of such memory errors is the very definition of memory safety.

  • The software engineering group at MIT (Liskov, Guttag, etc) have been pushing for this since the early 1980s. Guttag told us in lecture that he tried unsuccessfully to get these concepts built into the Ada specification.

    • by microbox (704317)
      D [digitalmars.com] has had contracts since the get-go. Sometimes I wonder if it would be a better world if all the C and C++ out there was *magically* reimplemented into a better language.
    • by wbhauck (629723)

      There's a subset of Ada called SPARK that has these concepts.

      SPARK (Programming Language) [wikipedia.org]

    • Yup, .NET has also only got contracts last year (in the standard library; third-party solutions existed earlier), which is a shame. Well, better late than never. Between it being part of .NET core distribution, and backed by a player as big as Google in Java land, let's hope this becomes mainstream soon.

  • Another one? (Score:4, Informative)

    by quivrnglps (572909) on Friday February 11, 2011 @11:22AM (#35175522)

    According to Wikipedia [wikipedia.org] there are already quite a few projects doing DbC:

    Java, via iContract2, Contract4J, jContractor, Jcontract, C4J, CodePro Analytix, STclass, Jass preprocessor, OVal with AspectJ, Java Modeling Language (JML), SpringContracts for the Spring framework, or Modern Jass, Custos using AspectJ,JavaDbC using AspectJ, JavaTESK using extension of Java.

    Do we really need an entirely new one? If none of those are sufficient, why not build on top of and improve an existing project? Starting over is not always a good thing...

    • Do we really need an entirely new one? If none of those are sufficient, why not build on top of and improve an existing project? Starting over is not always a good thing...

      Have you tried reading the links in the summary?

      Contracts for Java is based on Modern Jass by Johannes Rieken.

      -- Google's announcement article, which was the second link in the summary

      • Still, what's new here? What value has Google added to that existing OSS project - other than marketing power and visibility? Looking at the Google project's FAQ:

        Is this framework related to 'ModernJass' from Sourceforge.net?

        Yes, Cofoja is a significant rewrite of ModernJass. We worked closely with the original author of ModernJass (Johannes Rieken) on this.

        OK...then why not contributing to the OSS project instead of phagocyting it and re-branding it into another Google product? I guess I'm answering my own question here...

        Has anyone found more details? For instance, Modern Jass does not support JML. Is Google going to support it? If not, why didn't they create their own work to implement it?

        I'm

    • One of the best ones was the DEC Extended Static Checker for Java [stanford.edu] in the late 1990s. That project died after Compaq acquired DEC and shut down research. But it formed part of Microsoft's efforts for Spec#, which has a formal verification system.

      Microsoft has had a huge success with formal proof of correctness - the Static Driver Verifier [microsoft.com]. This is a system which tries to formally prove that a Windows driver can't crash the operating system. All drivers for Windows 7 have to pass this verifier to be sign

      • by Coryoth (254751)

        One of the best ones was the DEC Extended Static Checker for Java in the late 1990s. That project died after Compaq acquired DEC and shut down research. But it formed part of Microsoft's efforts for Spec#, which has a formal verification system.

        ESC/Java lives on as ESC/Java2 [secure.ucd.ie] which uses the JML language for annotation. This makes it significantlymore powerful than ESC/Java since you also get the entire JML toolchain as well. ESC/Java2 also has excellent IDE support via Eclipse plugins now. If you like that sort of thing it is well worth looking into.

      • The hacks that try to do design by contract at run time tend to avoid expressions which examine big data structures, since they have to run them over the whole data structure every time. Real verifiers prove or disprove such things at compile time. It turns out, though, that a few standard cases for collections cover many of the usual things you want to say.

        Very good point, and the irony is that the Google blog uses collections in one of their examples.

        The Google project is based on a library called Modern Jass. I'm not familiar with it since the last time I did research on DbC was in 1999/2000 when the only DbC tool for Java that existed might have been Reto Kramer's iContract. Yet, to call it a hack...is it purely because of this absence of static analysis you mention? BTW what kind of static analysis is implemented in Eiffel?

        As for concurrency, I agre

  • Isn't throwing an error a side-effect?

    • Well if you program correctly you will never have to worry about that, will you?

      This is the ENTIRE IDEA.

    • It's not a side effect, it's the INTENDED effect.

      Isn't throwing an error a side-effect?

    • by pz (113803) on Friday February 11, 2011 @11:57AM (#35176082) Journal

      Isn't throwing an error a side-effect?

      No, because it does not mutate a value, but only changes the control flow.

      I wish I had more time to explain in detail, but that isn't going to happen today, unfortunately. Side-effect in this context is a highly specific term that means, essentially, to change the value of a variable through assignment.

      • by snowgirl (978879)

        Isn't throwing an error a side-effect?

        No, because it does not mutate a value, but only changes the control flow.

        I wish I had more time to explain in detail, but that isn't going to happen today, unfortunately. Side-effect in this context is a highly specific term that means, essentially, to change the value of a variable through assignment.

        No, the first sentence was sufficient. I am a CS guru. Just previously vague definitions need clarification.

    • If the contract is violated, the program should be terminated immediately. The point is that there are no side-effects when the contracts are observed.
  • I'm still waiting for a decent compile time DbC. Runtime checks won't catch an untested control flow, and when the fault does happen you better hope it happens in your lab and not on a client's computer. You can read my analysis of this in my Master's thesis (which focused on unique references that were ensured to be unique at compile time):
    http://www.worldcat.org/title/applying-uniqueness-to-the-java-language/oclc/701244184&referer=brief_results
    • So you need to profile your code too! What else is new? This is a tool, not a panacea.

      • by subanark (937286)
        I'm not sure I follow you. Profiling typically refers to determining places in your code that run slow. A static checker would ensure that there is no set of inputs that would violate the contract, and it would produce errors when you compile your code informing you that some condition may not always hold. For example, in Java if all code paths do not assign a local variable before it is referenced, you will get a compiler error.
    • by Coryoth (254751)

      You'll want to look into JML and ESC/Java2 which supplies DbC syntax and static checking via theorem provers. It's been around for quite some time and is fairly powerful.

  • You can do all of this range checking yourself manually in your code if you want, there is nothing new here.

    These annotations just do the dirty work of pumping out the boilerplate code. You could do it yourself with an emacs macro or some such.

    • It's all syntactic sugar. The point is to reduce the cost of development. Contracts should be distinct from implementations; a user should be able to consult the contract in order to find his obligations when calling a routine. By optionally checking contracts at run-time, you can be reasonably confident that they are actually being followed.
    • by subanark (937286)
      These provide more expressiveness than a typical macro can provide. They also extract the check from your code, so if you find a bug or need to refactor the checking code, you don't need to go though every place you inserted the biolerplate code and change it.
    • by p3d0 (42270)
      Actually Design by Contract is a design discipline, not a bunch of error checks. It's a bit like programming without gotos: the benefit comes not from avoiding typing "goto" into your source code, but rather from the style of reasoning you use when you learn the proper alternatives.
  • by Anonymous Coward


    @Requires({
    "Collections.isSorted(left)",
    "Collections.isSorted(right)"
    })
    @Ensures({
    "Collections.containsSame(result, Lists.concatenate(left, right))",
    "Collections.isSorted(result)"
    })
    List merge(List left, List right);

    Seriously, let's just toss out the whole idea of syntax checking or anything. I could put these into individual asserts and they would be hilighted by my IDE and checked by my compi

  • I've seen that contract thing being used on a project. It was gruesome, and needless most of the time. I had to remove all the contract enforcements just to understand the underlying code. I guess I'm allowed to be a skeptic on this technique.

    tl;dr Contracts suck.

    • by subanark (937286)
      The contract itself is not part of the code. You can understand the code simply by ignoring all the comments (or having your IDE collapse them). However, you will need to understand the contract system if you want to modify the code, as otherwise you can end up violating them with any changes you make.

      Yes, the contracts adds complexity to the language, which is a primary reason that C's preprocessor directives were not included as part of Java.
  • Eiffel and Ada have had 'design by contract' as a key language feature for 25+ years, and this is a major contribution to both 'safety' and correctness of design. It's good to see Java catch up.

    • Eiffel safety has been broken due to the language fragrant violation of Liskov Substitution Principle by allowing argument covariance on method overrides in derived classes, and by treating all generic types as covariant in all their type parameters - a hole in the type system big enough for a train to ride through.

      Don't get me wrong, DbC is a wonderful idea. It's a pity that it has been tied to the horrible language that is Eiffel for too long - it deserved better.

  • Does it really require a language extension to throw a runtime error whenever a boolean is met with false? Or is the amazing part that google has found a way to make java even more verbose? I didn't think it could be done.
    • Contracts are supposed to be part of the public interface, whereas the usual "if (fail) throw ..." code resides in the midst of implementation. You want method contracts to actually appear in your public Javadocs, for example. So it makes sense to make them distinct from normal error checking logic.

  • I was learning Eiffel and had been coding in Ada for a couple of years when Java showed up. I was surprised then that Sun's language designers had given us a language that was already 15 years behind the state of the practice, let alone 30 years behind the state of the art.

  • Or you could use the .Net Code Contracts which do all this with static analysis. Therefore you get proof up front that your contracts will never be violated by non exposed code, and without a performance penalty at run time. If a contract cannot be verified, warnings are given. You can then introduce appropriate branching to provide guarantees as necessary. http://research.microsoft.com/en-us/projects/contracts/ [microsoft.com]

The world is no nursery. - Sigmund Freud

Working...