Slashdot Mirror
Java Static Analysis And Custom Bug Detectors
An anonymous reader writes "Java static analysis and custom bug detectors can be a very cost-effective way to improve software quality. By creating a detector for a known bug pattern, we can search for that bug pattern not only in the current code base for a specific project, but in any project, current or future. This article looks at how static analysis tools can change the way you manage software quality."
The point is not to use another piece of software/language to solve bugs. In the industry, you're not always given the choice and, yet even worst, people who make decisive choices are not always knowledgeable to make proper decisions (hello, managers!). We get to deal with the choosen tools and that's it.
Your alternatives are probablement better in respect of quality due to their formalism but you'd have to convince your manager or boss to sign up with these solutions. Might be easier to stick with Java and use a Java bugs finder tools.
You should run whatever LINT-like tools you can find. Developers should agree as a group on what warnings are spurrious and what warnings are legitimate, and adjust any lint policy configurations to suit.
You can also find far more than simple bugs, but you can decide on best practices and consistency standards which should be adhered also. These can vary in importance, but it really helps for a clean and searchable codebase. For a trivial example, if coding in C, decide as a group whether to use *p = '\0' or *p = 0 when writing into a char string. For a more involved example, regularly scan the codebase for regular expressions like (>)\s*(8|16|24) to find possible Intel/PPC endian issues lurking where you don't expect it.
The adage goes, if you find you're doing something more than once, see if you can automate it, so you can pay more attention to the things which can't be automated. This goes for coding and debugging too.
[
Not having used any static analysis tools, but having worked on several java projects, I question how useful these tools are. In my experience, most bugs that could be detected by static analysis are usually caught relatively quickly anyway. The trickiest (and potentially most damaging) ones are usually non-general enough to slip past a general-purpose tool. Am I mistaken?
The point is that you have to use the correct tools to get the job done properly. Using one potentially faulty tool (Java static analyzers) in an attempt to alleviate the shortcomings of another faulty tool (Java) is a recipe for disaster. The best bet is often to use the right tool for the right job. When it comes to building large, high-quality, cost-effective software systems, Java is often the wrong language to use. OCaml and Haskell provide the features necessary for such systems to be developed effectively and on-budget.
If the boss insists on quality software, and insists on using Java, as an engineer or developer you'll just have to explain that both are not possible. Sure, you may get disciplined, or even fired. Of course, present your argument in terms a manager is likely to understand, namely showing how using a proper language results in fewer bugs, which will result in a greater return on the firm's investment. Maybe then he or she will listen to you.
The only reason Java is used so often is ignorance. First off, many managers are ignorant of the major technical and economic benefits of languages like OCaml and Haskell, especially when compared to Java. Likewise, many developers are unaware, as well.
Second of all, many developers are afraid to put forth the very minor investment in learning such languages. Of course, they don't realize that the week they put in towards learning Haskell or SML will be returned many times over. Why is that? Because the software they write will often work correctly the first time. There won't be stuck at the office on weekends, suffering through awful debugging sessions. Instead, they will have gotten the work done by Thursday, ensured the system was functional on Friday, and then spend the weekend with their family.
until Sun relases a new JRE and all your old aplications do not work at all anymore when users install the new JRE.
That hasn't been a problem so far as even Java 1.1 applications will still work just fine today in Java 1.5.
That is because unlike other languages, Java has taken a lot of care to keep things working through revisions. Libraries going into disuse are deprecated, not removed - so you have a long time while a library or method call still exists before going away.
Even the design of Java's Generics system was made so that older code would be able to work in harmony with it.
When you're thinking of language revisions breaking code, you must thinking of C#... it's easy to get confused since it's a direct clone of Java.
C/C++ applications tend to work for decades and can be written to be far more reliably cross-platform.
They tend to work for decades because they are still running on the same 386 box they were originally installed on (a testament to Linux). Now if you are trying to move that complex C/C++ app to a more recent platform, like say Fedora 5 - all the sudden you glib isn't quite what the program was expecting.
C/C++ is great for cross platform compatibility along with performance, but you should not pretend that it doesn't take work to maintain and keep things in sync with librarires and system calls.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I mean, it can find bugs without all this tedious unit-test writing. - this 'tedious unit-test writing' is the only way to make sure that the business rules are asserted. Concurrency problem is a non-problem for most applications. In case of Java, J2EE container handles the concurrency issues. Configuring another tool just for the sake of configuring just another tool is a waste of resources and cannot be always justified. I would rather see my people spend more time writing unit-tests than configure pointless tools.
Good day.
You can't handle the truth.