Google Brings Design-By-Contract To Java 134
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.'"
Finally! (Score:3)
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)
Re:Finally! (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:1)
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)
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)
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.
Re: (Score:3)
Re:BOf in Java? (Score:5, Informative)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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]
Re: (Score:2)
Re: (Score:2)
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).
Re: (Score:2)
Re: (Score:3)
"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)".
Re: (Score:2)
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.
Re: (Score:2)
They didn't, they listed the guessed number of actual attacks against (Windows) machines. Finding 2.6 million possible vulnerabilities in the JVM after running code analysis, now that *would* make an interesting Slashdot headline.
Re: (Score:3)
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.
Re: (Score:2)
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...
Re: (Score:2)
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
Re: (Score:3)
The Java standard libraries are *primarily* native code? WTF have you been smoking? You can tell the moderators are not very knowledgeable either.
If somebody could post the percentage of C/C++ code in the Java RE, please do because we need to get rid of FUD like this.
Re: (Score:1)
quick basic line count of openjdk 6:
1328021 lines in .c/.h/.cpp/.hpp files (this is _both_ windows and linux vms) .java files
4091401 lines in
Re:BOf in Java? (Score:4, Informative)
Re: (Score:2)
MOD PARENT DOWN. Retard most of Java is written in Java.
Trademarked (Score:5, Interesting)
Actually, Google is bringing Programming by Contract to Java. Design by Contract is trademarked by Eiffel Software (and Bertrand Meyer).
Re: (Score:2)
Re: (Score:3)
Well that should work out well. We'll just call it that everywhere else and make sure no one in the US ever sees it..
Re: (Score:2)
Re: (Score:2)
Well I did say it in jest it's truthful. It would be tricky naming it two different things. I just call it programming by contract because that's probably more accurate anyway.
Re: (Score:2)
Google is a US company. Sorry.
Re: (Score:2)
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.
Re: (Score:2)
That programming language is 25 years old now so of course its catch phrase have been used for a long time.
Re: (Score:2)
Prime example of why Eiffel has failed to catch on in the mainstream.
Re: (Score:2)
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".
Re: (Score:2)
I Wes referring to their marketing strategy which seems to be designed to discourage attracting developers.
Good news (Score:2)
Fail (Score:5, Insightful)
Re: (Score:1)
Re: (Score:1)
What would it mean to have a bug in the contract?
It would mean the contract has been poorly written (Score:1)
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
Re:It would mean the contract has been poorly writ (Score:2)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
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.
Re: (Score:2)
Nah... stringly-typed languages are perfectly safe.
Re: (Score:2)
WTF are you talking about? Design contracts have been around since the 70's at least. Come on can't you do any research at all before you post?
Re: (Score:2)
Re: (Score:1)
Um, patented things can be open source for certain.
Section 7 clearly states that it is an issue if you are asked to stop, but not before (though says it is up to you to try it, and not intended to induce infringement).
Section 8 clearly states you can limit distribution to where patents do not apply and still be compliant.
GPL V2
Too fragile (Score:3, Interesting)
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
Until plugins are developed, and on Eclipse is not that hard, the compiler infrastructure is accessible to plugins developers, but right now without any plugin you get error notifications is you setup the annotation processor [fsteeg.com]
Re: (Score:2)
Yup, because Java didn't have assert [sun.com] before!
Re: (Score:2)
Re: (Score:2)
How are you going to detect passing an invalid parameter to a function at compile time?
You would have to know every place a method is called and every value being passed in.
1: public members can be called from code you never compile.
2: You need to be able to know the value of all the objects used as parameters at the time they are called. These values can not be determined explicitly in many cases.
3: java has strong reflection abilities and run time injection that are used in many libraries that throw an e
Re: (Score:2)
Personally I use, coverity, findbugs & pmd and don't use things like assert because assert relies on the coder actually knowing what to do and doing it and these tools can be loaded into the IDE. They don't catch everything but they do find 99%
Java does not have buffer overflows (Score:2)
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.
Re: (Score:2)
You didn't read the article did you? This has nothing to do with buffer overruns.
Back to the 80's! (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
There's a subset of Ada called SPARK that has these concepts.
SPARK (Programming Language) [wikipedia.org]
Re: (Score:2)
google "6.170" and you will find that the work at MIT predates eiffel by many years.
Re: (Score:2)
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)
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...
Re: (Score:2)
Have you tried reading the links in the summary?
-- Google's announcement article, which was the second link in the summary
Re: (Score:1)
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
DEC did a good one (Score:3)
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
Re: (Score:2)
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.
Re: (Score:1)
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
No side-effects AT ALL?! (Score:2)
Isn't throwing an error a side-effect?
Re: (Score:2)
Well if you program correctly you will never have to worry about that, will you?
This is the ENTIRE IDEA.
That's the INTENDED effect (Score:2)
It's not a side effect, it's the INTENDED effect.
Isn't throwing an error a side-effect?
Re: (Score:2)
If an error message is printed, which is a side effect, that's happening when the exception was caught, which isn't really part of evaluating the exception throwing expression.
I think by using levels of abstractions, the idea that it's the exception handling is what has the side-effect rather than the exception thrower misses the point that the exception thrower is still proximally the cause of the side-effect.
Re:No side-effects AT ALL?! (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:1)
Bah runtime (Score:2)
http://www.worldcat.org/title/applying-uniqueness-to-the-java-language/oclc/701244184&referer=brief_results
Re: (Score:2)
So you need to profile your code too! What else is new? This is a tool, not a panacea.
Re: (Score:1)
Re: (Score:2)
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.
It's just syntactic sugar anyway (Score:2)
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.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Source code in strings? Really? (Score:1)
@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
Give me a paper bag, I'm aboUT TO BLAAARRGH! (Score:1)
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.
Re: (Score:1)
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.
About time... (Score:2)
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.
Re: (Score:2)
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.
I don't understand what's important about this (Score:1)
Re: (Score:2)
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.
About time (Score:1)
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.
.Net Contracts are Better! (Score:2)