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.'"
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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.
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.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
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.
24 beers in a case, 24 hours in a day. Coincidence? I think not!