I fear these kinds of tools will be (are?) used as an argument to keep using C/C++. "Just adhere to all these standards and use all these code analysis tools" is a really bad way of handling bugs when I guarantee you it won't be used by those that need it most.
I think we need to start thinking of programming as a true craft. Like watch making. Not something you learn within 2 years just to become a productive app-maker to mass produce more useless apps. But something you grow into by gaining a full understanding about how the computer works. And this requires you to go trough both assembler and C. And by raising the notion of coding as a true craft that takes time and require precision, we will gain more secure applications. Not by hiding the inherent mechanics of the machine treating programmers like kids who need training wheels.
Except we're not making the same kind of thing over and over. Programming's not a craft. It's an abnormally non-routine form of engineering. By all means, teach the college students about doping, logic circuits and binary assembly. But skip C. Skip C++. It's not cool, it's not hardcore, it's just sad.
Whether they are used as a justification to use C/C++ for new projects (which isn't an argument I've seen), it's still better to have some solid tools available to find security issues in the existing C/C++ code that's already out there.
It's really dangerous to think that switching to another language will fix all your security problems. You can have safe memory, but that's about it. Serious exploits like "goto fail" can exist in any language.
No. The state of the art has advanced well past Java. And besides the kinds of bugs that a good type system can fix, there's also bugs borne from usability problems like switch fall-throughs that are trivial to fix with a better syntax.
