Google Brings Design-By-Contract To Java

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

BOf in Java?

[Lord Ender]

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.

Fail

[nicholas22]

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

[pz]

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:Finally!

[mark-t]

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!

[The Snowman]

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.