Perhaps not, but I don't think inline documentation is often very useful either and breaking code density is a jarring thing. External documentation exists for a reason (even if it's just doxygen-izing your inline docs instead of pointing people at the direct source), and I much prefer reading (and writing) short READMEs, examples, or tutorials than digging through implementation code if I'm interested in using something. And if I'm integrating anything non-trivial I don't think little comments saying "/* * executes the passed query string, not using prepared statements, throws SQLException, returns nothing */ public static void executeSql(String query) throws SQLException {" are useful or worth my time. Write comments when something needs some explanation not clear from the context, save the academic comment-everything documentation for enterprise busywork or academia.
I think you're mixing up inline documentation with api documentation.
For inline stuff where it's explaining a complex/dense lump of code, it's useful to keep it as close to the original code as possible, so that if somebody updates the code, they're more likely to see/update the comments as well.
