Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Brings Design-By-Contract To Java

Soulskill posted more than 3 years ago | from the putting-a-hit-out-on-bugs dept.

Google 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.'"

cancel ×

134 comments

Sorry! There are no comments related to the filter you selected.

Finally! (2)

goofy183 (451746) | more than 3 years ago | (#35175208)

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!

Celebrate Black History Month - Yo Mama Jokes! (-1)

Anonymous Coward | more than 3 years ago | (#35175868)

Yo mama so stupid she got hit by a parked car.

Re:Finally! (1, Insightful)

mark-t (151149) | more than 3 years ago | (#35178152)

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.

BOf in Java? (2, Insightful)

Lord Ender (156273) | more than 3 years ago | (#35175218)

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? (5, Informative)

goofy183 (451746) | more than 3 years ago | (#35175310)

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:BOf in Java? (0)

Anonymous Coward | more than 3 years ago | (#35175768)

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.

Not to mention increase readability/maintainability by reducing boilerplate code

Re:BOf in Java? (2)

medv4380 (1604309) | more than 3 years ago | (#35175834)

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 fix those buffer overflow issues. They'd have to add it to C++ and implement it on the whole JRE and that would be a massive rewrite. It might fix things but adding it to Java only will fix things like when a programmer fails to do sanity checks of user input.

Re:BOf in Java? (4, Informative)

goofy183 (451746) | more than 3 years ago | (#35176124)

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:BOf in Java? (1)

Speare (84249) | more than 3 years ago | (#35177494)

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 are going to do, do it, then tell the testing apparatus what you did. The grammar was different in each section.

While I can give high marks for the idea, it really struck me as a huge expense of time and initiative to paraphrase every bit of code into three variations of the same thing. You write functions/methods/modules expressly to avoid code duplication, but apparently they think this kind of code duplication is different somehow. Cumbersome. Cumbersome is the word that comes to mind when I think of designing by contract.

Re:BOf in Java? (1)

gorzek (647352) | more than 3 years ago | (#35177962)

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 commonly run into is code that doesn't do what was intended. The developer meant for it to work a certain way, but the code as implemented works slightly (or even markedly) differently. Even worse, there's often no documentation so you can't be sure what the developer intended.

This paradigm, if not completely eliminating the above problem, sounds as though it can go a long way toward addressing it. Even in the absence of documentation, the pre/post validation would tell you a lot about how the program is expected to function.

That said, I haven't done any design-by-contract, it just sounds very intriguing despite the additional coding it requires.

Re:BOf in Java? (1)

GooberToo (74388) | more than 3 years ago | (#35178292)

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:BOf in Java? (1)

nicholas22 (1945330) | more than 3 years ago | (#35175358)

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#.

Re:BOf in Java? (2)

Johnny Fusion (658094) | more than 3 years ago | (#35175396)

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)".

Re:BOf in Java? (0)

Anonymous Coward | more than 3 years ago | (#35175824)

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)".

So, they ran a static analysis and reported the raw number of potential issues in the JRE... let me tell you how many there are in the actual windows source code: just about the same amount, in each depot (there are about 14 depots)...

Re:BOf in Java? (1)

owlstead (636356) | more than 3 years ago | (#35176194)

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:BOf in Java? (1)

owlstead (636356) | more than 3 years ago | (#35176162)

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:BOf in Java? (2)

mswhippingboy (754599) | more than 3 years ago | (#35175400)

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:BOf in Java? (1)

dna_(c)(tm)(r) (618003) | more than 3 years ago | (#35176674)

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:BOf in Java? (0)

blueg3 (192743) | more than 3 years ago | (#35175902)

One of the major sources of security bugs in Java is that the Java standard libraries are primarily native code. The native code is rife with buffer overflows, unchecked pointers, and other vulnerabilities.

Re:BOf in Java? (2)

owlstead (636356) | more than 3 years ago | (#35176280)

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:BOf in Java? (1)

Anonymous Coward | more than 3 years ago | (#35176804)

quick basic line count of openjdk 6:

1328021 lines in .c/.h/.cpp/.hpp files (this is _both_ windows and linux vms)
4091401 lines in .java files

Re:BOf in Java? (0)

Anonymous Coward | more than 3 years ago | (#35179456)

I did a 5-minute check, I found 123 classes of 7209 with some native functions. Not sure about actual LOC but definitely native code is the minority.

Re:BOf in Java? (3, Informative)

nicholas22 (1945330) | more than 3 years ago | (#35177732)

Sorry but you're completely wrong. Java libraries are primarily written in Java you wally.

Re:BOf in Java? (2)

sproketboy (608031) | more than 3 years ago | (#35179344)

MOD PARENT DOWN. Retard most of Java is written in Java.

Re:BOf in Java? (0)

Anonymous Coward | more than 3 years ago | (#35179586)

AWT, the printing subsystem, parts of NIO and networking contain some native code to interop with the underlying OS. But to say the standard libraries are "primarily" native code is far from the truth. They are primarily pure Java, with native code where necessary to interop with the underlying OS.

Re:BOf in Java? (1)

hey! (33014) | more than 3 years ago | (#35176360)

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 when I write a unit test is how dang *specific* unit tests are. It'd be nice to be able to say, "I haven't given any thought to values outside this range so make sure you're only using values in this range."

It also seems to me that this could be a nice safety net for when people try weird and wonderful things to eke out a little more performance, like caching or reusing objects, or having factory methods that return a singleton. Often these strategies are poorly implemented, or have side effects that aren't well thought out. So you might say that a method that returns a connection to some external software service ensures the connection TO be open and NOT TO BE in some kind of error state. You'd just toss that annotation in without much advance thought, because in *your* version of the routine it just won't happen. Later when some genius modifies the method to roll his own connection pooling scheme, the annotation will catch the problem of service connections returned in an inconsistent state to the previously non-existent and still not visible pool. Gosh, I've run across that kind of thing more than once.

Trademarked (4, Interesting)

D Ninja (825055) | more than 3 years ago | (#35175296)

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

Re:Trademarked (1)

nicholas22 (1945330) | more than 3 years ago | (#35175346)

This only applies to the US. The rest of the world can use that moniker. This is because the trademark only applies there. Sorry.

Re:Trademarked (2)

trollertron3000 (1940942) | more than 3 years ago | (#35177626)

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:Trademarked (1)

nicholas22 (1945330) | more than 3 years ago | (#35177746)

Stop trolling.

Re:Trademarked (1)

trollertron3000 (1940942) | more than 3 years ago | (#35179612)

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:Trademarked (1)

abigor (540274) | more than 3 years ago | (#35177772)

Google is a US company. Sorry.

Re:Trademarked (1)

FranTaylor (164577) | more than 3 years ago | (#35175666)

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:Trademarked (1)

a_n_d_e_r_s (136412) | more than 3 years ago | (#35176100)

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

Re:Trademarked (0)

Anonymous Coward | more than 3 years ago | (#35176600)

So they haven't maintained their trademark... gp's post is moot.

Re:Trademarked (1)

H0p313ss (811249) | more than 3 years ago | (#35176006)

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

Good news (1)

metamatic (202216) | more than 3 years ago | (#35175316)

I'm sure Oracle will be only too happy to work with Google to add this to the JDK, right? Right?

Fail (5, Insightful)

nicholas22 (1945330) | more than 3 years ago | (#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.

Re:Fail (1)

worip (1463581) | more than 3 years ago | (#35175434)

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?

Re:Fail (1)

noidentity (188756) | more than 3 years ago | (#35176088)

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?

It would mean the contract has been poorly written (1)

Anonymous Coward | more than 3 years ago | (#35176582)

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 out certain problems at compile time). Some properties can only be checked at runtime (and thus a runtime exception is thrown giving a better clue as to where the problem lies when it blows up). Contracts are tools to help programmers write correct programs to be written and like a bad test suite, bad contracts won't help you all that much in achieving that.

Re:It would mean the contract has been poorly writ (2)

noidentity (188756) | more than 3 years ago | (#35177098)

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, since it is the definition of correct. If your clients code to the contract, you can't go changing it without breaking clients. The contract may be badly-designed, and it's good to avoid bad designs, but once you have clients, to go in and try to fix a "buggy" contract is to water down what contracts mean in the first place. It encourages clients to ignore contracts and code to what they imagine the routine should do. At that point, you might as well abandon contracts because they aren't being used as the definition of what is correct anymore, just a vague guide as to what the routine might do.

Re:It would mean the contract has been poorly writ (1)

p3d0 (42270) | more than 3 years ago | (#35177726)

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.

Re:Fail (1)

p3d0 (42270) | more than 3 years ago | (#35177652)

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:Fail (0)

Anonymous Coward | more than 3 years ago | (#35175732)

An IDE operates on matching tokens in character-string-based code. I suspect that the content within the Contract annotations being String-based is an implementation artifact that will be a surmountable obstacle for plugin writers.

Re:Fail (0)

Anonymous Coward | more than 3 years ago | (#35175860)

With an annotation processor, you could make it type-safe and IDE-safe...

Re:Fail (0)

Anonymous Coward | more than 3 years ago | (#35175922)

E.g. c4j.sourceforge.net defines contracts in java code in a non-intrusive manner.

Re:Fail (0)

sproketboy (608031) | more than 3 years ago | (#35176062)

Modded down? Fucken google fanbois.

Re:Fail (0)

Anonymous Coward | more than 3 years ago | (#35179362)

I would stay away or use something more type-safe and IDE-safe.

And because the parent fails to point out alternative solutions (for Java), let me. A good project for Java design by contract would be the Java Modeling Language (JML) [wikipedia.org] produced by Gary Leavens.

Pattent problems? (0)

Anonymous Coward | more than 3 years ago | (#35175428)

By the way, Eiffel already pattented "design by contract". Therefore, it cannot be open sourced.

Re:Pattent problems? (1)

FranTaylor (164577) | more than 3 years ago | (#35175616)

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:Pattent problems? (1)

bunratty (545641) | more than 3 years ago | (#35175664)

No. Eiffel Software trademarked the term Design by Contract. Therefore, whatever scheme you come up with to do something similar, you cannot call it by the same name. You can do exactly what Eiffel does as long as you call it by a different name, such as Programming by Contract. Trademarks protect names. Patents protect inventions.

Re:Pattent problems? (1)

AvitarX (172628) | more than 3 years ago | (#35175988)

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 (3, Interesting)

lehphyro (1465921) | more than 3 years ago | (#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.

Re:Too fragile (1)

robmv (855035) | more than 3 years ago | (#35177562)

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:Too fragile (1)

lehphyro (1465921) | more than 3 years ago | (#35177920)

But you don't get IDE auto-completion and syntax coloring.

Re:Too fragile (1)

robmv (855035) | more than 3 years ago | (#35178022)

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:Too fragile (0)

Anonymous Coward | more than 3 years ago | (#35178636)

Erm, that sounds like a pretty simple IDE change to add support.

Re:Too fragile (0)

Anonymous Coward | more than 3 years ago | (#35179512)

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.

Perhaps, but the IDE won't be able to give you errors immediately. This requires a full compile of the source file to generate errors, which is a lot more fragile than if they avoided using strings and went with a more concrete syntax (like that used in Validate [apache.org] ).

Java finally gets assert(3) (0)

Anonymous Coward | more than 3 years ago | (#35175472)

Is what this sounds like to me. I've always felt an important part of strong C programming was to put a set of asserts at the top of each function that asserts the properties of the function's input (numeric ranges, non-NULL pointers where applicable, etc). Again, not for user input validation, but for validating software design assumptions that make up the contractual interface between caller and callee.

Re:Java finally gets assert(3) (1)

VGPowerlord (621254) | more than 3 years ago | (#35175532)

Yup, because Java didn't have assert [sun.com] before!

Re:Java finally gets assert(3) (1)

bunratty (545641) | more than 3 years ago | (#35175708)

Assert detects errors a runtime. Java has had those for years. Design by Contract finds errors at compile time.

Re:Java finally gets assert(3) (0)

Anonymous Coward | more than 3 years ago | (#35176192)

If you've been working with this type of system, what percentage of these types of errors are detectable at compile time as compared with run-time? I assert conditions on method/function arguments and run unit tests, and am having trouble thinking of any particular examples in my own work where a compile time check would have caught something before it was caught by unit tests. I think delineating exactly what the method's assumptions are is important, and have no particular objection to the idea in general, but am wondering what practical impact it would have compared with existing working methods. (I wrote Java full time for six years but have been doing Obj-C for the past three. I'm not the GP.)

Re:Java finally gets assert(3) (1)

Stevecrox (962208) | more than 3 years ago | (#35178618)

For compile time checking your better off using static code analysis, Coverity is very good at finding reverse/forward null/memory leak problems. Findbugs is good for finding some of these issues as well because it looks at the code from a byte code perspective.

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% of the obvious stuff.

One of the things which did stun me was running Tomcat 6.0.18 through Coverity it found 529 defects, about 180 were parameter checking ones. I've been tempted to join an open source project and spend my time resolving these kinds of bugs.

Re:Java finally gets assert(3) (1)

Nadaka (224565) | more than 3 years ago | (#35176200)

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 even bigger wrench into the process.

Java does not have buffer overflows (1)

naasking (94116) | more than 3 years ago | (#35175476)

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:Java does not have buffer overflows (1)

FranTaylor (164577) | more than 3 years ago | (#35175568)

You didn't read the article did you? This has nothing to do with buffer overruns.

Re:Java does not have buffer overflows (0)

Anonymous Coward | more than 3 years ago | (#35175758)

What article are you reading? First paragraph:

Google is developing a set of extensions for Java that should aid in better securing Java programs against buffer overflow attacks.

Fourth paragraph:

Primarily touted as a technique to ease programming, Contracts could also provide an easy way for developers to guard against buffer overflow attacks, the researchers said.

Fifth paragraph:

One of the oldest techniques in the attacker's virtual arsenal, buffer overflows remain a problem.

Seems like it has everything to do with buffer overflows.

Back to the 80's! (1)

FranTaylor (164577) | more than 3 years ago | (#35175480)

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:Back to the 80's! (2)

microbox (704317) | more than 3 years ago | (#35175562)

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.

Re:Back to the 80's! (0)

subanark (937286) | more than 3 years ago | (#35176480)

The problem with D and similar languages is that programmers are too clever for their own good. D doesn't enforce checking, and is only safer than C if you don't use a good chunk of its extra features. All it takes is one library that wanted to make a shortcut and ends up being faulty for the entire application to not work correctly. C# has the best middle of the road approach where you can use unsafe code, but using it anywhere in your project will require you enable the unsafe code switch, so at least you can be sure that your code is unsafe clean pretty easily.

Re:Back to the 80's! (2)

wbhauck (629723) | more than 3 years ago | (#35175586)

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

SPARK (Programming Language) [wikipedia.org]

Re:Back to the 80's! (0)

Anonymous Coward | more than 3 years ago | (#35175668)

I think Bertrand Meyer was the originator of the idea, or at least the first to realize it in the form of a production-ready programming language. Google "Eiffel programming language".

Re:Back to the 80's! (1)

FranTaylor (164577) | more than 3 years ago | (#35175912)

google "6.170" and you will find that the work at MIT predates eiffel by many years.

Another one? (4, Informative)

quivrnglps (572909) | more than 3 years ago | (#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...

Re:Another one? (1)

VGPowerlord (621254) | more than 3 years ago | (#35175642)

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

Re:Another one? (0)

Anonymous Coward | more than 3 years ago | (#35176512)

Google suffers from "not invented here" syndrome

Re:Another one? (0)

Anonymous Coward | more than 3 years ago | (#35177378)

That's exactly what they are doing idiot.

DEC did a good one (2)

Animats (122034) | more than 3 years ago | (#35177768)

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 signed, It's an impressive system which works by symbolic case analysis. It yields a proof, a counterexample, or times out analyzing too many cases. About 3% of programs time out. (If your kernel driver has undecidable behavior, it needs work.)

I headed a team that did a proof of correctness system for Pascal back in the early 1980s. [animats.com] That was pushing the limits of what you could do back then; verifying a small program took 45 minutes on a 1 MIPS VAX. Today, with about four orders of magnitude more CPU power, it's a practical technology.

There have been many attempts to bolt some "design by contract" features onto various languages, but they're usually not very good. The problem is saying things about collections. 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.

Another big issue, which Spec# handles and this Google hack apparently doesn't, is the "insideness" issue for object invariants. Object invariants are supposed to be true whenever control enters and exits an object. But what if an object calls one of its own public methods, perhaps through a long chain of calls? Now, control is inside the same object twice. That violates the invariant rule.

This class of bugs is common in window systems, where all the widget, pane, window, and event objects are frantically calling each other. It also comes up in concurrency, which I don't see Google's hack addressing either.

Re:DEC did a good one (1)

Coryoth (254751) | more than 3 years ago | (#35178624)

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.

No side-effects AT ALL?! (1)

snowgirl (978879) | more than 3 years ago | (#35175724)

Isn't throwing an error a side-effect?

Re:No side-effects AT ALL?! (1)

FranTaylor (164577) | more than 3 years ago | (#35175804)

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 (1)

fnj (64210) | more than 3 years ago | (#35175876)

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

Isn't throwing an error a side-effect?

Re:That's the INTENDED effect (0)

Anonymous Coward | more than 3 years ago | (#35177734)

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

Isn't throwing an error a side-effect?

An expression has a side effect, in computer science, if its evaluation changes global state. It has nothing to do with the intent of the expression; this isn't like the side effect of a drug.

That said, throwing an error isn't normally considered a side effect.

If you think about it, even evaluating a pure expression affects global state: the runtime is going to mark that the expression was evaluated and that control can now move to the next expression.

Throwing an error does basically the same thing: the expression is marked as evaluated and control simply moves to an exception handler instead of the next expression.

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.

Re:No side-effects AT ALL?! (3, Insightful)

pz (113803) | more than 3 years ago | (#35176082)

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:No side-effects AT ALL?! (1)

noidentity (188756) | more than 3 years ago | (#35176142)

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.

Bah runtime (2)

subanark (937286) | more than 3 years ago | (#35175874)

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

Re:Bah runtime (1)

FranTaylor (164577) | more than 3 years ago | (#35176084)

So you need to profile your code too! What else is new? This is a tool, not a panacea.

Re:Bah runtime (1)

subanark (937286) | more than 3 years ago | (#35176344)

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.

Re:Bah runtime (1)

Coryoth (254751) | more than 3 years ago | (#35178664)

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 (1)

FranTaylor (164577) | more than 3 years ago | (#35175972)

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:It's just syntactic sugar anyway (1)

noidentity (188756) | more than 3 years ago | (#35176248)

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.

Re:It's just syntactic sugar anyway (1)

subanark (937286) | more than 3 years ago | (#35176418)

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.

Re:It's just syntactic sugar anyway (2)

p3d0 (42270) | more than 3 years ago | (#35177804)

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.

Source code in strings? Really? (1)

Anonymous Coward | more than 3 years ago | (#35176204)


@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 compiler, and with a simple //REQUIRES or //ENSURES comment, it would be no less obvious to the reader. Now real DBC also involves checking things like class invariants and making sure that preconditions never narrow and postconditions never expand, but I know Google's little hack doesn't do class invariants, so I kind of doubt it does the latter two either.

Google has some great Java code -- guava is probably the best collections library out there, for instance -- but this sad little hack is not it.

Give me a paper bag, I'm aboUT TO BLAAARRGH! (1)

elsurexiste (1758620) | more than 3 years ago | (#35176416)

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:Give me a paper bag, I'm aboUT TO BLAAARRGH! (0)

Anonymous Coward | more than 3 years ago | (#35176566)

Does that say more about contracts or you?

Re:Give me a paper bag, I'm aboUT TO BLAAARRGH! (1)

subanark (937286) | more than 3 years ago | (#35176686)

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.

bury button (0)

Anonymous Coward | more than 3 years ago | (#35176452)

Where's the bury button? Oh yeah - shitdot doesn't have one.

About time... (1)

david.emery (127135) | more than 3 years ago | (#35177548)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>