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

Comments

PMD and JLINT

[Hoolala]

We develop Java-based vertical products and we have found PMD and JLINT when integrated with an appropriate development process, can be highly effective in preventing serious bugs. That said, both PMD and JLINT incorporates "religious" issues, and it is important to determine what the religious issues are and steer clear of them lest the good rules get lost among the non-essential (from project perspective) rules.

FindBugs is awesome

[tcopeland]

As the lead guy on a "competing" static analysis framework - PMD - I can say that FindBugs is definitely a great piece of work. It catches all sorts of complicated problems with concurrency, does forwards/backwards data flow analysis, etc, etc. It's pretty sweet. Dr Pugh, who runs the project at the University of Maryland, did a JavaPosse interview that's some more good info on the project and where it's going.

Of course, if you really want to do source code analysis (vs bytecode analysis, which is what FindBugs does), then go for PMD, and [plug] get the book! [/plug]

PMS and JOINT

[Anonymous Coward]

We develop feminine-based vertical products and we have found PMS and JOINT when integrated with an appropriate development process, can be highly effective in preventing serious flows. That said, both PMS and JOINT incorporates "religious" issues, and it is important to determine what the religious issues are and steer clear of them lest the good rules get lost among the non-essential (from project perspective) rules.

Why not use OCaml or Haskell?

[Anonymous Coward]

While there may be various reasons why one would rather go with Java, if fairly high-quality software is needed, OCaml and Haskell may be just the solution. This is especially so when formally-verified software would be excessively expensive.

Even if static typing does limit flexibility somewhat, and does put more responsibility on the developer to ensure that their programs type correctly, doing so often leads directly to fewer problems. Plus you get the benefit of typing problems being discovered at compile time, rather than at runtime (where a user will see it, rather than a developer).

Due to coming out of various branches of mathematics, the type systems of languages like Haskell and OCaml are far superior to that of Java. It's almost a case where it's pointless to bother with Java static analysis tools, when using a language with proper static typing takes care of all that immediately at compile-time.

Re:Why not use OCaml or Haskell?

[Anonymous Coward]

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.

Re:Why not use OCaml or Haskell?

[Umbral Blot]

You do realize that for the most part Java has static typing? (For example compare its types to those in Lisp, Lua, ect)

Re:Why not use OCaml or Haskell?

[bunions]

OCaml and Haskell you say? Excellent. I was looking around for a magical silver bullet the other day, and these look like just the ticket!

Re:Why not use OCaml or Haskell?

[Anonymous Coward]

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.

Re:Why not use OCaml or Haskell?

[Anonymous Coward]

While there may be various reasons why one would rather go with Java...

*** Vulgar display of fanboyism detected ***

So, is this the solution for the question about the "meaning of life and everything else"?

Re:Why not use OCaml or Haskell?

[bunions]

The only reason Java is used so often is ignorance.

By a strange coincidence, that's also the only reason people make assertions like this.

Re:Why not use OCaml or Haskell?

[Anonymous Coward]

You'll be sorry when you find out that werewolves actually aren't vulnerable to silver bullets after all.

Re:Why not use OCaml or Haskell?

[NoOneInParticular]

Can't help myself to be obnoxious: although this is alleviated a bit with Java 1.5 (Java C# edition), Java has traditionally be statically typed when it isn't necessary (MyObject object = new MyObject(); int x = 4; .... Really, a proper compiler (like Ocaml's) can infer such types!) and runtime-typed when it would actually be useful (MyObject object = (MyObject) array.get(index); /* Sure hope that guy from the cubicle over there actually put a MyObject in there, let's check his code... */). That and no way for a proper library to use any form of overloading (the BigDecimal.add() fiasco), plus the tendency to write everything as a member where a function would actually do nicely (BigDecimal.add() again!) makes Java indeed a fairly loosely typed and inflexible tool. Ah well, also Cobol gave job security.

Re:Why not use OCaml or Haskell?

[Anonymous Coward]

Spot the type error in this OCaml function:

let get_string file =
  (Marshal.from_channel file : string);;

Oh, wait, you can't... because you don't know that the function that writes data to this file is writing an integer.

Yes, this is a type error. A function that expects a string is being passed an integer. No, OCaml can't detect it at compile-time, even if the function that writes the data is right there in the same source file. (There's been some progress recently in fixing this, but it's not in the standard distribution yet.)

Of course, that's not the only reason why OCaml isn't a good choice for a major application. The real problem is that you can't find enough developers who know it. Having a programming language that's so great that you only need 10 programmers instead of 100 is not much help if you can find 100 Java programmers but only 3 OCaml programmers.

Re:Why not use OCaml or Haskell?

[IamTheRealMike]

The type system of Haskell doesn't let you prove anything radically more interesting than that of Java or C++ to be honest. Also Haskell mixes up a bunch of other random ideas with that type system so you have to take the bad from the good - eg lazyness and the unusual syntax.

Re:Why not use OCaml or Haskell?

[yogikoudou]

I don't think you can say that for the most part Java has static typing.
For example:

public class A {
        public A(){}
        public void f() {
                System.out.println("A::f");
        }
}
 
public class B extends A {
        public B(){}
        public void f() {
                System.out.println("B::f");
        }
}
 
public class Test {
        public static void main(String[] args) {
                A myA = new A();
                B myB = new B();
                myA.f();
                myB.f();
                myA = (A)myB;
                myA.f();
        }
}

This gives:

$ java Test
A::f
B::f
B::f

With static typing, that's in C++ for example when you don't use virtual, you don't get B::f() when the last myA.f() is called. That's because Java resolves the type of myA dynamically, and not statically.

C++ static example:

#include <iostream>
using std::cout;
using std::endl;
 
class A {
public: void f(){
                cout << "A::f()" << endl;
        }
};
 
class B : public A {
public: void f(){
                cout << "B::f()" << endl;
        }
};
 
int main(int argc, char *argv[])
{
        A *myA = new A();
        B *myB = new B();
        myA->f();
        myB->f();
 
        myA = (A*)myB;
        myA->f();
 
        return 0;
}

Now, this gives:

$ ./test-c++
A::f()
B::f()
A::f()

The second A::f() means that the type of myA is resolved statically.

If you make f() virtual, it is resolved dynamically, as in Java for the caller object (not for the parameters).
This will give you a B::f() on the last line, try it.

Please explain what you meant or stop posting BS when I'm just out of a course entitled "Comparing C++ and Java object models".

Searching for future bugs?

[noidentity]

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

Does it require a 1.21 gigawatt lightning bolt to power the future search feature?

Re:Searching for future bugs?

[RPoet]

I think you mean "jiggowatt".

Those that don't understand C will reinvent it

[Anonymous Coward]

It's called "lint".

People still use Java?

[Anonymous Coward]

Didn't Java become legacy software sometime in the late 90's? Who in their right mind would even start a new Java project nowadays?

Re:People still use Java?

[Anonymous Coward]

No, you got it all wrong. Java became USEFUL software sometime in the late 90's!

Re:People still use Java?

[ErroneousBee]

What, you maen someone created an application that wasnt a Java code IDE/editor/debugger/trace tool?

Its 10 years later, and there are still no serious desktop applications written in Java. What is wrong with Java that causes all GUI apps to have the look, feel and performance of Jade Goodie?

Re:People still use Java?

[justinstreufert]

One Java desktop app which I use all the time is Azureus. You might argue that Azureus (a bittorrent client) isn't "serious," but it is pretty cool.

Re:People still use Java?

[Marcus Green]

Why not do a little research? Go to any of your favorite job sites e.g. Monster, Jobserve etc and search on some lannguage keywords, perhaps C C++ C# Java. You will usually find that there are more posts that include the word java than any other. Maybe someone somewhere is using it.

Re:People still use Java?

[Anonymous Coward]

Actually there are rather a lot of these. Sun maintains a list of some of them here

Re:People still use Java?

[Anonymous Coward]

Oracle SQL Developer is written in Java, so is the Oracle Enterprise Manager client.

Re:People still use Java?

[Anonymous Coward]

Some cool desktop java programs:

FrostWire is a Peer to Peer (P2P) information sharing client for the Gnutella network.

Aqua Data Studio is a database query tool and administration tool that allows developers to easily create, edit, and execute SQL scripts, as well as browse and visually modify database structures.

Maple is a leading Computer Algebra System

Columba is a very nice email client

Rio Music Manager is and iTunes like app that comes bundled with every Rio mp3 player (can be downloaded for free too)

MagicDraw is a very impressive UML modeler.

Re:People still use Java?

[Anonymous Coward]

Other cool Java desktop apps:

Art of Illusion is a free, open source 3D modelling and rendering studio. It is stable and powerful enough to be used for serious, high end animation work. Many of its capabilities rival those found in commercial programs.

BlogBridge is a nice RSS agregator and reader.

GanttProject is a project management program similar to MS Project.

install4j is a powerful multi-platform Java installer builder that generates native installers and application launchers for Java applications. Awesome looks!

Jake2 is a port of the Quake II engine to java

Too much work...

[Anonymous Coward]

The detector code is 3x the size of the error. Though this is an example, what would it look like in real life apps, when the bug detector code is 100s or thousands of lines of bug prone code itself?

I wouldn't trust it. The people who write bad code will write bad debug detection code... especially if they are coders who have been outsourced and do not care if it works or not.

Re:Too much work...

[MillionthMonkey]

I wouldn't trust it. The people who write bad code will write bad debug detection code... especially if they are coders who have been outsourced and do not care if it works or not.

The code in javac is more than three times the size of my HelloWorld program, so I'm not sure it's compiling it correctly. Especially if Sun farmed out javac to some outfit in Bangalore. They won't care if it works. I'm scared to run my program now. What if it doesn't say "Hello World"? It might say "Goodbye world" and then delete my hard drive since the javac guys just don't care.

I'm just going to have to hand-assemble the bytecodes myself. I don't trust anybody!

Re:Too much work...

[Anonymous Coward]

Truth be told, the bug fixing code is incredibly simple. PMD and Checkstyle are little more than a visitor pattern using a generated parser and generic abstract syntax tree. The individual checks work inside this larger pattern and are about as complex as a regular expression most of the time.

Trust me. This kind of stuff can be written very quickly and in the old days it was. The vast majority of the code in these tools is the checks themselves which are numerous and individually small.

Not just bugs, but lint for bad practices...

[Speare]

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.

Re:Not just bugs, but lint for bad practices...

[Speare]

Should have known that the HTML and the C would have butted heads...

Regular expressions like: (<<|>>)\s*(8|16|32)

Also, run your code through more than one make of compiler if you can: each compiler has its own set of warnings, and if you can pass them all cleanly, you can get closer to a "best in breed" codebase.

What a strange thing from IBM

[roman_mir]

One would think that out of all people, IBM staff would be familiar with the ATM or the Halting Problem. I think that the bugs that are really important to find, are those that are not feasible to find with automated tools, and the bugs that this article is talking about are the simples ones.

Also wouldn't this 'static bug detection' be unnecessary if Java was a strong typed language? The idea of casting is of-course a powerful one, but it is this idea that is probably responsible for the most non-business related bugs in the code. This, and null pointers of-course (a strange name for an exception in a language that uses no pointers.)

In any case, I would rather see people do something than nothing, so I guess bug detectors better than no bug detectors, but in reality I would rather have the developers write good unit-tests.

Re:What a strange thing from IBM

[TheSunborn]

Java is a strong typed language, which just mean that if you got a reference to a class A, then you know that the object is of the type A, or of a class that extend A. (And similary for the buildin types)

But that is far from enough to be bug free. Just a simple example (Yes, a bit silly, but it shows the problem)

/** Add element 0, and the integer at position index and return the sum */
public static int myFunction(int[] myArray,int index) {
return myArray[0]+myArray[index];
}

Now the question? Is this function buggy? I would say no, because it does exactly what the documentation say it does, and it does handle all cases where the function is called with correct input.

So if this function was part of a bigger program, would that program have a bug in calling this funciton. That is: Does there exists input, that will cause this function, to be called with a index=myArray.length.

And to answer that question automatic is someware between very very diffucult, and imposible. (But for most* programs answering that question is posibly)

*I will argue that for at least 99.999% of all correct programs that are written to solve a pratical problem, making a static analysis that prove they are correct are in fact posible.

Re:What a strange thing from IBM

[roman_mir]

I made a mistake, I meant to say statically typed, that's why I was talking about casting. Casting allows dynamic typing and this is what I believe is one of the major contributors to the non-business bugs in code in case of Java.

Re:What a strange thing from IBM

[Anonymous Coward]

The halting problem is only intractible in the case of INFINITE memory. This is not true of any real computer (it's actually trivial in the case of finite memory: all you have to do is see the exact same machine state twice and you know the program loops forever).

Also, Java being strongly typed means little in terms of bug preventions. You eliminate some basic (usually silly) errors, buffer overflows, etc, but that's only the tip of the iceberg. Not all code is easy to unit-test, especially concurrent code. These tools serve to supplement a developer's toolbox.

BTW, the 'null pointer' is a bit of a misnomer. Java should've called it 'null reference' (as C# does).

Re:What a strange thing from IBM

[TheSunborn]

Well, java only allow casts that can be legal, and it return null if the cast fails. So if you have public class A { }
public class B { }
public void f(B myB) { A myA=(B)myB; }
This will not compile at all, because there is no way to cast a B to an A.

If you have
public class Base { }
public class Derived extends Base { }
public void g(Base myBase) { Derived myDerived=(Derived)myBase; }
The function g is ok, and if myBase is infact an instance of Derived, then all is ok. If it is NOT an instance of Derived, then myDerived vil be null, and any code that use myDerived will cast null pointer exception. You can't cheat the java type system.

This is unlike c++, which will accept any cast you ask it to do.

Re:What a strange thing from IBM

[Anonymous Coward]

You'll get a ClassCastException... not a NullPointerException.

Re:What a strange thing from IBM

[Anonymous Coward]

first - of course using a language with a better typing system than Java will prevent a lot of these bugs from even being possible. But language choice is often made at the managerial level, not at the technical level, and how many managers have heard of Haskell or OCaml?

second - with that said, of course the interesting and hard bugs to find are the ones that aren't trivially detectable with tools. But when you've got a team of coders of mixed abilities (see above, about the influence of the managerial level -- it's hard to objectively evaluate a programmer's competence, even if you are a skilled programmer yourself, and once a programmer is hired it's unlikely he'll get fired no matter how incompetent he is unless he does something illegal), the automated tool allows the more skilled programmers to spend their time finding the interesting and hard bugs, while the less skilled programmers run the tool and fix up their own code.

third - there's no necessary choice -- it's not like you need to choose either good test suites or automated bug testing. You'll catch more bugs with both than you will with either alone.

Re:What a strange thing from IBM

[Anonymous Coward]

Not really.

The Java "reference" behaves more like a pointer than a reference. Null pointer is the right terminology. Sun just created a lot of confusion by pretending that Java doesn't have pointers. Java has something very similar to a pointer but it *does not* have references.

Re:What a strange thing from IBM

[CableModemSniper]

One would think that out of all people, IBM staff would be familiar with the ATM or the Halting Problem.

Just use a language that isn't Turing complete, and therefore can be guaranteed to terminate. http://www.e-pig.org/.

Re:What a strange thing from IBM

[maraist]

You can't cheat the java type system.
You're kidding right.

Bar b = new Bar();
Foo f = (Foo)(Object)b;

Works just fine for me... Until you get the ClassCast Runtime Exception.

Now you might call this a contrived example.. Except that it's not.

How many thousands of function calls take Serializable or worse "Object" as a parameter? Virtually every IPC related activity does at some point. That includes all of j2ee, which are considered "enterprise" level coding frameworks.

Generics was a step in the right direction with compile-time enforcement of "many" of these opaque "Object" APIs.. But It definitely didn't penetrate some of the more important areas; just collections (which was at least the most [mis]used form of generalized types).

But Generics doesn't have any means of enforcement.

Collection myFoos = new ArrayList();
Collection myUnsafeFoos = myFoos;
Bar bar;
myUnsafeFoos.add(bar);
Foo foo = myFoos.iterate().next();

will throw a ClassCast Runtime Exception.

Now it's semi-trivial to write collections to enforce type-safety (just like synchornization).. But this is as effective as cooperative multi-tasking was in the 90's at reducing bugs.

Java has a lot of historical baggage that keeps it from being a refined and bug-resistant language.. And the proliferation of XML-configured reflective programming is really getting out of hand. That being said, I am not aware of any other development platform that is as versatile. .NET had a triffle of potential (being a rewrite of Java), except that it's got Big [Corporate] Brother to keep it from reaching it's full potential.

Re:What a strange thing from IBM

[maraist]

Sorry, HTML and less thans... :)

Collection<Foo> myFoos = new ArrayList<Foo>();
Collection myUnsafeFoos = myFoos;
Bar bar;
myUnsafeFoos.add(bar);
Foo foo = myFoos.iterate().next();

Re:What a strange thing from IBM

[NoOneInParticular]

... and given that the many useful classes give stuff back in the form of Object, this is all very helpful ...

In any case, C++ has all but abandoned the C-style form of casting, which forms the syntactical basis for Java's casting mechansims: currently C++ sports dynamic_cast (Java-style cast with dynamic type check, returns 0 if the cast fails), static_cast (does not do type checking, but still does a basic compile time check like java. It is present if there's no way that the cast can fail; at least if the programmer thinks that is the case), and reinterpret_cast (interprets bit_patterns as anything you want, the most liberal form of casting).

As usual in C++, you don't pay for what you don't use, if you don't need a runtime type-check, the language doesn't insist you should use one.

Re:What a strange thing from IBM

[roman_mir]

Well, java only allow casts that can be legal, and it return null if the cast fails.

Oh, really? After working with Java for the past 8 years, I sort of noticed that you can do this:

WhateverObject1 whateverObject1=new WhateverObject1();
WhateverObject2 whateverObject2=new WhateverObject2();
List list = new ArrayList();
list.add(whateverObject1);
list.add(whateverObject2);
SomeObject someObj = (SomeObject)list.get(0);

Now tell me again what will Java compiler do in this case if SomeObject is not the same as WhateverObject1?

Re:What a strange thing from IBM

[An Onerous Coward]

Two points:

Technically, "intractable" doesn't mean "mathematically impossible," but "too big to manage," so the solution you propose would fall under the "intractable" category.

Also, while you're probably already aware of this, the standard limitations apply to your solution: no external input can be available, and no race conditions can exist in the program.

Re:What a strange thing from IBM

[slamb]

One would think that out of all people, IBM staff would be familiar with the ATM or the Halting Problem.

First, I don't see the relevance, so I suspect you don't understand the halting problem[*]. You've probably heard it phrased as in the Wikipedia article: "a general algorithm to solve the Halting problem for all possible program-input pairs cannot exist. We say that the halting problem is undecidable over Turing machines." You've probably heard arguments reducing other problems to the Halting problem and concluded that automated reasoning about programs is impossible.

By some word juggling and de Morgan's laws, Wikipedia's statement is equivalent to "there exist program-input pairs for which the halting problem cannot be solved with a general algorithm." I'd say those should be quite rare if you're doing "reasonable" things.

The common examples of undecidable programs involve "finding counterexamples to famous conjectures in number theory". I'm guessing your programs don't do that. There generally should be straightforward indicators of your programs' progress - input file pointers, size of internal data structures, iterators. If IBM Research put all their effort into the Halting problem and their program still couldn't tell if your program terminates, it might be because your program is screwed up. Thus, "our program can't tell if your program halts for all input" probably means "rethink your algorithm", just as "your program does not halt for input X" does. The same goes for other properties which can be reduced to the halting problem.

It'd still be a hard thing to do, though. I think most existing checker tools examine only a function at once, and I'm not aware of any attempts to do anything so sophisticated even at that level.

the bugs that this article is talking about are the simples ones.

Simple but common, which make them great bugs for static analysis. But if you want fancier examples, look at these bugs the Stanford Checker (now Coverity) found in the Linux kernel.

Also wouldn't this 'static bug detection' be unnecessary if Java was a strong typed language? The idea of casting is of-course a powerful one, but it is this idea that is probably responsible for the most non-business related bugs in the code

Java is a strongly-typed language. If you cast something incorrectly, you get a ClassCastException. The runtime knows the type of every object. You may have meant "totally statically-typed language". In any case, the answer's still no - the System.gc() example that you found too simple is an obvious counterexample.

In any case, I would rather see people do something than nothing, so I guess bug detectors better than no bug detectors, but in reality I would rather have the developers write good unit-tests.

They're another way to find bugs, and the bugs they find are not a subset of those found by unit tests. There are a lot of classes of bugs that can't be found easily with unit tests (race conditions!). There are a lot of environments in which it is difficult to write unit tests (embedded code, kernel code, GUI code). And fundamentally unit tests require you to come up with the input that breaks it. If there's a case you never considered at all, they just won't have the same value as a second pair of eyes on your algorithm, which these static analysis tools effectively are.

Does this sort of reasoning sound familiar?

"Does it work in the normal case? Yup. If the list members, commas, and trailing null come to BUFSIZE-1 characters? Yup. BUFSIZE? Yup. ... What if an individual element overflows this smaller buffer? Oh, it can't, because that's over log(INTMAX) by

Re:What a strange thing from IBM

[roman_mir]

The halting problem is only intractible in the case of INFINITE memory. - factually wrong.

for(;;) { ...
    if (something is true) {
        break;
    } ...
}

No infinite memory, just uncertain state of 'something'.

Also, Java being strongly typed means little in terms of bug preventions. - I actually meant strong AND static typing. Static typing would prevent most non-business bugs. It would prevent serialization, reflection, inheritance and collection element casting errors. That is a lot of types of errors.

Re:What a strange thing from IBM

[roman_mir]

First, I don't see the relevance, so I suspect you don't understand the halting problem[*]. - because YOU don't see the relevance doesn't mean I don't understand something.

Judging by that first statement uou missed most of my point. My point is that there is no real advantage building extra tools to search for simple errors, while still not being able to combat real problems, like infinite loops, incorrect conditions, class cast exception, null pointer exception. ATM has relevance to all of the above-mentioned bug types, so there.

You've probably heard it phrased as in the Wikipedia article: - way to infer. I have probably studied the ATM and Halting problem at Stephen Cook's class (you may want to look him up, he was my UofT prof.)

You've probably heard arguments reducing other problems to the Halting problem and concluded that automated reasoning about programs is impossible. - I already answered tha in the first paragraph in this comment.

Simple but common, which make them great bugs for static analysis. But if you want fancier examples, look at these bugs the Stanford Checker (now Coverity) found in the Linux kernel. - my argument is that these specific types of bugs are due to the language defficiencies. Were Java using strong static typing, these 'bug detectors' would have been included in the compiler.

Java is a strongly-typed language. If you cast something incorrectly, you get a ClassCastException. The runtime knows the type of every object. You may have meant "totally statically-typed language". In any case, the answer's still no - the System.gc() example that you found too simple is an obvious counterexample. - yes, cowboy, you are right. You might have read the rest of the thread to notice that I fixed my wording.

Race conditions can just as well detected with unit-tests. Sure, people don't always write unit tests and when they write them, they don't always write them well or complete them. But this problem has to do with the development practice and no bug detector will find all problems, most of the problems will still have to be debuged and once you debug them, you add another unit test or a suite of unit tests.

Hey, I didn't say these bug detector tools were completely useless, but I would rather see people write good unit tests and think through their code than rely on bug detectors.

After all, if detecting race conditions and deadlocks was a trivial matter, it would have been done in the compiler.

Re:What a strange thing from IBM

[TheSunborn]

It will give you a ClassCastException.

Re:What a strange thing from IBM

[TheSunborn]

Now it depend on what the definition of cheating is. But going back to my original text which say

which just mean that if you got a reference to a class A, then you know that the object is of the type A, or of a class that extend A. (And similary for the buildin types)

So one could say, that you can try to cheat on the compiler, but It don't care becasue it knows the jvm will stop the actuelly type convension at runtime if it is wrong.

Re:What a strange thing from IBM

[roman_mir]

The compiler will give me a ClassCastException? :)))))))))) THE COMPILER? :))))))))))))))))))))

Ok, over and out.

Re:What a strange thing from IBM

[Anonymous Coward]

>>First, I don't see the relevance, so I suspect you don't understand the halting problem[*]. - because YOU don't see the relevance doesn't mean I >>don't understand something.

>Judging by that first statement uou missed most of my point. My point is that there is no real advantage building extra tools to search for simple >errors, while still not being able to combat real problems, like infinite loops, incorrect conditions, class cast exception, null pointer exception. ATM >has relevance to all of the above-mentioned bug types, so there.

Could you expand upon what you mean? I'm not sure I understand you. What is ATM? I haven't heard of it before.

It looks like you are saying:
* The halting problem is undecidable in general.
* Therefore, if we try to check for termination, we won't be able to show all our programs are terminating so there's no point in trying it for any.
* Furthermore, this will be true for other properties too (like deadlocks etc.)

Firstly, proving termination of reasonably coded functions is quite practical for everyday programs you write. When you write your functions down, you tend to think of it along the lines of "this iterator looks for the value in the list, when it finds it returns it and returns if it doesn't, so it won't loop forever", or "every time I make a recursive call, the function parameter gets smaller so it will terminate eventually". Termination proofs go along similar lines. If it's hard to prove (or impossible) to prove that a function terminates, how can you yourself as a programmer be sure it terminates (you must have some idea why it does if you wrote it)? For this reason, it really isn't that important that the halting problem is undecidable.

As for these problems: "like infinite loops, incorrect conditions, class cast exception, null pointer exception"
* Proving termination will find infinite loops.
* Incorrect conditions, class cast and null-pointer exceptions can be found with strong static checking and a verbose specification language (i.e. a more expressive type system). For instance, in Java, you can't even say that a function takes an integer and returns a negative number (with static checking). You can greatly increase the confidence in your code (and the need for unit tests) if you can have data-types such as "x is between 5 and 10", "x is odd", "x is a member of set y" etc. You need to automate mathematical proofs to use the more complex forms of these stronger specifications however, which is undecidable in general. However, there's no reason why sizeable amounts of the logic we use in everyday programming couldn't be automated in the future.

You mentioned dead-locks. Spin (http://www.spinroot.com/spin/Man/Manual.html) is able to detect deadlocks in code using model-checking (http://en.wikipedia.org/wiki/Model_checking). As a side note, purely function programs (e.g. everything is immuatable) do not suffer from deadlocks and race conditions.

Anyway, my main point (even if I misinterpreted you) is: even if proving termination is impossible in general, it doesn't mean we can't for programs we actually write in practice. This goes for many other kinds of programming bugs too.

Re:What a strange thing from IBM

[Anonymous Coward]

But "something" must either depend on external input, or internal storage. If it is internal storage, then without infinite memory you can "simply" enumerate all possible states of the program to see which ones terminate and which don't. However, this would take a huge amount of time for any but the most simple program (e.g. by limiting RAM to 32 bits you could make the problem tractable). Most computers have more than 32 bits of memory though :-)

Re:What a strange thing from IBM

[roman_mir]

Could you expand upon what you mean? I'm not sure I understand you. What is ATM? I haven't heard of it before. - Accelerating (universal) Turing Machine, ATM is a class of TM that is capable of solving complex problems, more precisely ATM = {| M is a TM and M accepts w} This means that this machine will test input w on ALL possible Turing Machine configurations M with the assumption of finding a Halt (accept/reject state.) ATM is undecidable and I am not going into Oracle TM, which could supposedely decide ATM. ATM cannot decide HALT, that's the main point.

proving termination of reasonably coded functions is quite practical for everyday programs you write - agreed, that is what complexity and descrete math is all about. But automatic induction will take the same amount of time to run as the actual code that is being tested, which means that for all inputs, there is no polynomial solution. Besides, real-life code may depend on states of other external components, such as user input/databases/network input/interrupts etc., which just multiply the number of total possible inputs.

If it's hard to prove (or impossible) to prove that a function terminates, how can you yourself as a programmer be sure it terminates (you must have some idea why it does if you wrote it)? For this reason, it really isn't that important that the halting problem is undecidable. - I, as a programmer have an understanding of the base case and of the induction, but in reality there can always be an input to the function that will go out of the boundaries of the function. You believe that such input is possible to find with an automated induction machine, I know it is possible to find, but I know that there is no feasible solution for all inputs. Basically your inference engine will have to use heuristics to rule out less likely input subtrees, but this means that there is no guarantee that the engine has covered every single possibility.

I understand that we can write code to detect some deadlocks and some infinite loops in compile-time. I also understand that the code that detects dead-locks and infinite loops in runtime always works better, because it can catch conditions, for which the input could not be tested by a compiler.

--
Again practically speaking I would rather see people write good unit-tests, and this will catch much more problems than these bug-detectors.

If these bug-detectors actually become good enough to be incorporated into compilers, then go nuts, use the compiler directive to try and find these bugs. But again, on my projects I wouldn't recommend going with bug-detectors over unit-tests and given the simple fact that projects have limited resources (limited time, money and people) there is always a compromise that needs to be made.

Re:What a strange thing from IBM

[roman_mir]

Sorry it should have been

{ <M,w> | M is a Turing Machine and M accepts w }

the angle brackets are a bitch to type in HTML.

Re:What a strange thing from IBM

[EsbenMoseHansen]

This is unlike c++, which will accept any cast you ask it to do.

Not really true. C++ suppports three types of casts and one obsolete form that combines those three in some form I never can remember:

• dynamic_cast
• static_cast
• reinterpret_cast

The () is really poor syntax and the usage is discouraged. (and shame on Java for adopting that syntax).

Of these, Java support dynamic_cast, expanded a bit to support primitive types. (which should never have been added, imho.)

Yes, C++ will accept nearly any cast, provided you ask it to :) So you can get unchecked casts (static_cast) platform_dependent casts (reinterpret_casts) and the Java style cast that fail graciously. The idiom is even somewhat nicer in C++.

// Java
if (myobject instance-of MyClass) {
MyClass newname = (MyClass) myobject;
// do stuff on newname;
}
// C++
if (MyClass newname = dynamic_cast<Myclass>(myobject)) {
// do stuff on newname
}

Re:What a strange thing from IBM

[revscat]

Collection<Foo> myFoos = new ArrayList<Foo>();
Collection myUnsafeFoos = myFoos;
Bar bar;
myUnsafeFoos.add(bar);
Foo foo = myFoos.iterate().next();

That's not the correct way to be doing things, anyway. Try this instead:

Collection<Foo> myFoos = new Collections.checkedCollection(new HashSet<Foo>(), Foo.class);

Using this your myUnsafeFoos.add(bar) would throw a ClassCastException.

Re:What a strange thing from IBM

[roman_mir]

So one could say, that you can try to cheat on the compiler, but It don't care becasue it knows the jvm will stop the actuelly type convension at runtime if it is wrong. - And there lies the main problem as I see it with Java. This problem is not a theoretical one, it has nothing to do with speed, it has nothing to do with inheritance. The main problem is that certain things are left to the runtime to be found: ClassCastException is not thrown by a compiler, it is a runtime exception. However if this exception occurs you maybe certain that the real problem is still a compile-time problem, i.e., it was a development problem that lead to this so called 'runtime' problem. Real runtime problems are not development related, they are real world related - blackouts, hardware failures, explosions etc.

The fact that Java allows this behaviour

A a = new A();
List l = new ArrayList();
l.add(a);
B b = (B)l.get(0);

to go unnoticed during compilation is the reason for most non-business problems found in applications.

Re:What a strange thing from IBM

[Anonymous Coward]

>>> Accelerating (universal) Turing Machine, ATM is a class of TM that is capable of solving complex problems, more precisely ATM = {| M is a TM and M accepts w} This means that this machine will test input w on ALL possible Turing Machine configurations M with the assumption of finding a Halt (accept/reject state.) ATM is undecidable and I am not going into Oracle TM, which could supposedely decide ATM. ATM cannot decide HALT, that's the main point.

OK, thanks for that.

>>> agreed, that is what complexity and descrete math is all about. But automatic induction will take the same amount of time to run as the actual code that is being tested, which means that for all inputs, there is no polynomial solution.

I'm confused. You're saying that testing if the code terminates (statically) will take more time to run than what? Even if it took a static checker hours to see if your program had no infinite loops (I'm not making any claim about this though), the guarantee would be worth the wait.

>>> Besides, real-life code may depend on states of other external components, such as user input/databases/network input/interrupts etc., which just multiply the number of total possible inputs.

This is similar to the comment I made about halting: just because it might be hard to prove termination of some things, doesn't mean you should ignore proving termination of the rest of your code. Anyway, you can still prove that a function interacting with an external system will terminate (e.g. I'm sure people writing firefox know why the browser won't hang when it communicates to the web server).

>>> I, as a programmer have an understanding of the base case and of the induction, but in reality there can always be an input to the function that will go out of the boundaries of the function. You believe that such input is possible to find with an automated induction machine, I know it is possible to find, but I know that there is no feasible solution for all inputs. Basically your inference engine will have to use heuristics to rule out less likely input subtrees, but this means that there is no guarantee that the engine has covered every single possibility.

Do you have an example function in mind (that isn't needlessly exotic) that you think would be hard to prove the termination of? Many recursive/looping functions can be written and checked for termination using structural recursion (http://en.wikipedia.org/wiki/Structural_recursion ); this means that all recursive calls must be structurally simpler than the previous call.

For example, Fibonacci can be defined:
f(0)=0
f(1)=1
f(n)=f(n-1)+f(n-2)

Here we are doing recursion using natural numbers. These will be inductively defined (0 is the base case, n+1 is the step case). Proving termination of this function is very simple as we just check that all recursive calls to f are structurally smaller than n (i.e. n should be smaller each time) and that the base case (0) is handled. If your recursive parameter was a list, you would check the list was smaller each time etc.

This kind of iteration is very common in programming. Anyway, most automated theorem provers (like PVS, Coq) do this kind of reasoning for you automatically and will not allow you to define functions that do not terminate.

>>> I understand that we can write code to detect some deadlocks and some infinite loops in compile-time. I also understand that the code that detects dead-locks and infinite loops in runtime always works better, because it can catch conditions, for which the input could not be tested by a compiler.

But you can check all possible inputs. That's how Spin works. It checks all possible threading scenarios that could occur statically and determines if a deadlock is possible. For proving termination checks, you are using inductive proofs to show that all possible inputs leads to termination without having to actually run them all (think of how you do inductive proofs in

Re:What a strange thing from IBM

[roman_mir]

I am writing this from my car, and I am in a hurry, so I won't reply to everything right now, maybe later, but this one:

Why would you not want a program to catch bugs for you? The only reason you write unit tests is because the language and tools you're using are not powerfully enough to detect these problems statically. I take an exception with this one.

Unit tests are not only about correctness of the language constructs, unit tests complement documentation, they are business constructs and no detector can do this for anyone ever because all business problems are different.

Of-course unit tests assert specific output on specific input but the the reason behind the output given this input has to do with the problem at hand, not with the language constructs or with your ability as a programmer to find concurrency bugs in applications.

Ok, later.

Re:What a strange thing from IBM

[Anonymous Coward]

>> I am writing this from my car, and I am in a hurry, so I won't reply to everything right now, maybe later, but this one:

>> Why would you not want a program to catch bugs for you? The only reason you write unit tests is because the language and tools you're using are not powerfully enough to detect these problems statically. I take an exception with this one.

>> Unit tests are not only about correctness of the language constructs, unit tests complement documentation, they are business constructs and no detector can do this for anyone ever because all business problems are different.

>> Of-course unit tests assert specific output on specific input but the the reason behind the output given this input has to do with the problem at hand, not with the language constructs or with your ability as a programmer to find concurrency bugs in applications.

Could you give an example of what you mean here (e.g. a description of a simple function and why you would always be required to write unit tests)? For example, if you wrote a function to sort a list in Java, you might write a function that maps a list to a (any) list. You would then write several units tests to check it works properly (sort([])==[], sort([2,1])==[1,2] etc.). The issue is that you can only check it works with a finite number of examples. This is akin to checking a maths equation works by trying out a few numbers and saying "well, it works for the ones I've tried so it's probably true for all of them".

In a theorem prover, you can write sort(x) such that it's specification says "it outputs a list which is a sorted version of x". You could then prove mathematically that your function actually does this and be confident that it actually does for all possible values. It's still a good idea to write some units tests to check your specification says what you think it says though (e.g. your notation of what it means to be sorted might be wrong, but once you've checked this you can reuse it for other functions) as your program will be provably correct but it might not do the task you think it does.

Re:What a strange thing from IBM

[wormgate]

Java frameworks will make this an awfully expensive pursuit.

Anyone can write pretty code to hibernate and make huge mistakes.
Same with pretty much every other framework.

In the given example...wouldnt the test have failed?

All hammers are not equal true. But you have to be able to carry
your toolbelt to work and at work without breaking your back
and your shops.

Re:What a strange thing from IBM

[angel'o'sphere]

Thats not cheating the Java type system.

Cheating is:


class A {}
class B {}

A a = new A();
B b = (B)a;


Without any exception!

In C++ you would need to add a "*" to the declarations and you could write it like above and it would WORK!!!!

In Java the assignment causes a ClassCastException in C++ the assignment works (Depending on C++ language standard). In C++ ypu get likely a crash as soon as you use a method on the object b ... that is cheating the type system, because the type system thinks: oki, b is of type A.

angel'o'sphere

Re:What a strange thing from IBM

[slamb]

My point is that there is no real advantage building extra tools to search for simple errors, while still not being able to combat real problems, like infinite loops, incorrect conditions, class cast exception, null pointer exception. ATM has relevance to all of the above-mentioned bug types, so there.

I got that. My point was that you don't need to determine if an arbitrary program is error-free in all of those categories to have a useful tool. If static checkers can point out a bunch of errors in a huge program and a bunch of places they're suspicious of, then they are useful. And they can. Did you follow that Stanford Checker link? It detected all of the classes of errors you mentioned. Sure, it missed many more errors of those classes, and actual humans had to give it some project-specific knowledge for that to happen, but it seems like a good investment - it saves more time than it takes.

Hey, I didn't say these bug detector tools were completely useless, but I would rather see people write good unit tests and think through their code than rely on bug detectors.

I'd rather see them put the time into whatever tool seems to be helping them most at the moment. And then when it reduces their debugging time, they can use the surplus to try other things. You seem to be making a lot of assumptions - that doing something perfectly is useful but doing it well is not, that the time available for program verification is constant, etc.

Re:What a strange thing from IBM

[glitch23]

This, and null pointers of-course (a strange name for an exception in a language that uses no pointers.)

It isn't that Java doesn't use pointers (it uses pointers everywhere to refer to objects), it's just that the programmer doesn't have to explicitly differentiate between pointers and non-pointers. Since everything is treated as a pointer there is no reason to have special syntax to address an object using a pointer (whether that be for referencing or dereferencing it).

Re:What a strange thing from IBM

[roman_mir]

Could you give an example of what you mean here (e.g. a description of a simple function and why you would always be required to write unit tests)? - do you work? Seriously? Here is an example: A service code at Bell Canada is a two character description of a program or a service or a piece of rental equipment. The current big project at Bell is called All In One (AIO) (all different order capture systems are being put into one large system.) There is a function, that makes a decision whether a newly activated receiver is within AIO or it is a Genesis receiver (legacy service.) This function has to retrieve model and package information for a receiver, retrieve and cache a list of AIO packages and decide whether the the currently activated receiver is AIO or not. The function retrieves data with a data controller (this is a Weblogic Integrator project, so it follows BEA WLI architecture practices,) it then caches the data if it is not cached yet and then it compares the data from the current receiver to the cached data and makes a decision on whether this receiver is AIO.

The unit test sets up the necessary data and the database tables, sets up receiver information and runs the function and makes assertions at the end. This unit test is a part of a unit test suite that tests various business functions for the project. The unit test asserts that the function correctly implements the current requirements. The unit test is tied to a specific requirement. If the requirement changes, the unit test will change first to accomodate the new requirement and then the function will be modified.

The database drives the functionality of what is AIO and what is not, by changing the database, the output of the program is modified for different receivers.
1. It is impossible to know what the exact data will be.
2. It is guaranteed that the data will be modified once in a while (first time it will be preset on the 14th of July.)
3. It is necessary to have the unit test check the boundary conditions, and so there is more than one unit test (actually it is the same unit test ran with different data sets on all known boundaries and some cases between the boundaries. The boundaries include empty set, one element in the set per model, an arbitrary number of elements in the set per model, where there is either none, one or an arbitrary number of models.)
4. There is no way to tell what the models will be, what the packages will be, so there is no way to test for ALL inputs. No amount of time given to an inference engine can ever finish testing a function for an unlimited input size.

Good night.

Re:What a strange thing from IBM

[roman_mir]

...and actual humans had to give it some project-specific knowledge for that to happen, but it seems like a good investment - it saves more time than it takes. - that remains to be seing, I am not easily convinced of that, maybe I am jaded but I have seen to many instances, where maintenance and usage of a tool is more of a hindrance than help for a project.

Re:What a strange thing from IBM

[revscat]

Foo myFoo = new Foo();
Bar myBar = new Bar();
List<Foo> myList = new ArrayList<Foo>();
myList.add(myFoo); // OK
myList.add(myBar); // Compiler error

Thank you, come again.

Re:What a strange thing from IBM

[DimGeo]

If memory is finite and the program is non-interactive, the stop problem is decidable. All you have to do is simulate the program with a fixed input and create a copy of *all* the memory (assuming that the input and the program counter are in that memory) at each step. If a certain memory snapshot repeats itself, the program will never stop. This, of course, means that the program cannot be interactive, because the input must be fixed and of fixed size before you begin the simulation.

There is a whole theory in mathematical logic dealing with the stop problem on interactive programs working with finite memory. Look up 'automata over infinite objects'.

Re:What a strange thing from IBM

[Anonymous Coward]

>>> Could you give an example of what you mean here (e.g. a description of a simple function and why you would always be required to write unit tests)? - do you work? Seriously?

I probably wasn't clear enough, but I meant: what unit tests would you still need to write if your language+tools were powerful enough to determine if your program met its specification at compile-time?

>>> Here is an example: A service code at Bell Canada is a two character description of a program or a service or a piece of rental equipment.

Thanks for the detailed example, but I'm not sure I understand it. Your saying that depending on input to the database in your unit tests, the results of the unit tests will change, making it harder to test statically?

>>> 3. It is necessary to have the unit test check the boundary conditions, and so there is more than one unit test (actually it is the same unit test ran with different data sets on all known boundaries and some cases between the boundaries. The boundaries include empty set, one element in the set per model, an arbitrary number of elements in the set per model, where there is either none, one or an arbitrary number of models.)

>>> 4. There is no way to tell what the models will be, what the packages will be, so there is no way to test for ALL inputs. No amount of time given to an inference engine can ever finish testing a function for an unlimited input size.

This is the perfect thing to tackle with induction, meaning that you can test all inputs in a reasonable amount of time (remember, you're not actually running the program for all results, just proving that it will work for all results). You prove the base case and inductive case and this gives you a proof for all cases.

Of course, it's going to be harder to do this if your inputs/specification are incredibly complex (such as a database). All your functions should be short, as simple as possible and strongly specified to make checking easier. I'm not saying all cases are easy, but the example you gave is fairly exotic.

Here are some small examples of imperative programs that have properties about them proven mathematically (e.g. a sorting algorithm sorts, a square root function finds the square root, a binary search function works):
http://why.lri.fr/examples/

For these examples, there is no need to write any unit tests at all, because you have proven for all possible inputs that it will always work. For instance, the binary search on an array example contains a proof that the algorithm will always return what you are searching for if it is in the tree and that there will never be any buffer overruns statically.

Re:What a strange thing from IBM

[roman_mir]

Well, see the example I gave is not exotic, it is very indicative of a real world problem and it is just one function out of hundreds in on component of a large project. Really, most problems in large real-life projects are not normal algorythms for sort/search/combinatorics, most unit tests are used to test business functions such as SQL statements and business algorythms that are basically pieces of business requirements. Certainly if all that we were writing was just simple sorts/searches/data structures/quickest paths/graph traversals, basically all the stuff from Knuth :) or just the theory that you get to learn at the university, then the automated tools would have covered everything nicely. But unit tests test pieces of business logic, like what I have to do at Bell, or what I had to do at Hydro One or ADP, or IFDS, or Avema, or Symcor, or Christie Digital or the banks or insurance companies (I am a contractor.) And it is all domain specific. So I regard unit tests very highly due to the fact that they are descriptions of business problems, not computer science algorythms. Normally on contracts I lead teams, create designs and develop software and set the minimum standards for the project, and these standards include common frameworks for unit testing. So I always insist on common approach to unit testing, and actually we have to often use unit testing frameworks to do some integration testing where possible. I may take a look at these bug detectors and see what it takes to set up and configure the tests. If these tests are not intrusive and the developers themselves do not have to do anything additional in the code to accomodate the tests I may in some projects add these detectors to the build procedure. But it is all case by case scenario and it will depend on many things like the deadlines, resources, complexity of the project, number of people on the project on whether the project a new one or is it an addition/modification of an existing one and whether there are actually bugs that are being discovered that are similar to the bugs that this tool can detect. So it will take sometime to build enough knowledge about what this detectors can do and whether they can help in specific situations before I will let my teams use them.

Well, back to work :) have a good one.

Re:What a strange thing from IBM

[maraist]

That's not the correct way to be doing things, anyway. Try this instead

You missed the part where I compared it to cooperative multi-tasking.. You are wrapping the collection at constructor time, BUT half (and I do mean half) of the time you don't have control over the constructor to an object.. Especially if you are writing middle-ware code, which is most of what Java does - at least good application designs write most of their code in the form of middle-ware.

Take Sort for example... It can't depend on the fact that even though it asks for a generified collection that there is any sort of type-safety involved.. The only thing it can do is pre-validate the data-type of the existing items in the collection that is passed to it. But that's a performance hit, and the ONLY thing that this will do is produce a more meaningful runtime exception.. i.e. instead of an exception in the comparator you get one in the sorter with an explicit "element in collection of type X was really Y" RuntimeException.

Caches, Marshellers / Serializers, IPC services, persistence sercies, etc. They all are middleware applications which throw really really confusing errors sometimes because they aren't passed the expected classes. And when I say confusing, I mean they don't often throw class-cast exceptions, but instead meta-data mismatch exceptions.. But that leads you to believe that you've missed an attribute in the XML configuration instead of the fact that you've adding an object of the wrong type to the middle-layer.

Ideally, generics would be fully enforced by the VM. What we currently have (even with the spettering of Collections.unmodifiable,synchronized,checked etc are weak-enforcement which at best provides spot cleanness of code.. But any static anylizer tool could have detected innappropriate local bugs.. The more critical bugs are inter-moule bugs. And APIs of that sort tend to be littered with innappropriate parameter-checking. If you don't think this is a problem, then what is the number 1 security loop-hole in most older C libraries? gets(). This function (for performance purposes) didn't verify the size of the string so it allowed the over-flowing of the buffer and overwriting of user-space memory. Most other languages handle strings in a less performant, but more robust manner, so this type of bug has mostly dissapeared.

In java, with the advent of dynamic proxies and aspect-oriented-programming, the situation is even worse, because inter-module libraries can proxy objects which don't even match the appropriate prototype/interface. So you actually wouldn't get a class-cast-exception, but instead an arbitrary exception (most likely an NPE) inside the InvocationHandler.

This is mostly a rant, but it's based on my growing frustration with the lack of type-safety in java frameworks... Yes, you're certainly free to not use those frameworks.. But with the increasing movement into container-managed services (tomcat, jboss, or even spring/pico-container), this type-looseness is becoming a growing problem.

Re:What a strange thing from IBM

[Anonymous Coward]

You might be interested in these articles:
http://www.stsc.hill.af.mil/crosstalk/2005/12/0512 CroxfordChapman.html
http://www.spectrum.ieee.org/sep05/1454

They're about a company called Praxis who build software from the ground up using formal verification techniques to write high integrity systems (i.e. not just basic algorithms). They claim that their approach creates software with less defects and is cheaper in the long run compared to traditional techniques.

Re:What a strange thing from IBM

[revscat]

Since your comment was neither modded up -- which it deserved -- nor replied to -- which is equally as disappointing -- I wanted to let you know that I, for one, have read it several times. It was insightful, and I have nothing to add other than "well said."

Re:What a strange thing from IBM

[notamac]

// class BigNum is a big (infinite precision) integer that is stored on the heap
BigNum x = 0;
while (true) { x ++; }

This is a program that will never have the same memory pattern, and (given infinite memory) will never terminate.
The stop problem is undecidable in general; in very special cases you will get a 'yes' or a 'no', but never in general.

Re:What a strange thing from IBM

[DimGeo]

Yes, I said, in a computing device with *fixed* memory.

are these actually worthwhile?

[buddyglass]

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?

Re:are these actually worthwhile?

[famebait]

Am I mistaken?

That depends on the quality of your code. It's easy enough
to find out, though: install one of the tools (it only takes
a few minutes), try it on some of your production code, and
see how many real bugs it finds. Most people are surprised
by the results, but I make no guarantees about yours.

It can also save time in catching subtle bugs, even if it
doesn't recognise them directly, by early on pointing out
trival mistakes that would make them hard to diagnose and
potentially spend hours barking up the wrong tree.

Re:are these actually worthwhile?

[xenocide2]

I'm not sure how that post is "Funny," but the things modern static analysis are typically written to catch are concurrency problems. Java isn't quite plagued as much by the incorrect usage of pointers in C that inspired the creation of lint, but multithreading code is still dangerous and difficult to get right. At the very least, these things are usually quite self-sufficient; you'd be a fool to turn them down a daily generated report even if it doesn't catch EVERY potential pitfall.

Re:are these actually worthwhile?

[ashtophoenix]

Although what you say may be true in that complex or not so straight-forward bugs are more difficult to find, I have seen many a time myself or another developer struggling with a bug for a good 2-3 hours and as soon as another set of eyes looks at the code, he/she points out something obvious, simple, that was wrong with the code. This I have seen more than a few times, surely. So I think there's still merit to a static analyzer/bug-finder, even though it may not be able to find complex problems.

Re:are these actually worthwhile?

[buddyglass]

Obviously it's not something I'd turn down or ignore, if it were already set up and integrated into my build scripts. It's just a question of whether it's worth the effort required to set it all up and get it running daily. Maybe the effort level to achieve that is relatively low, in which case it would be worth doing.

Re:are these actually worthwhile?

[owlstead]

Well, simply said, if you aren't mistaken, I would go back and grab C++, which can do more and for which there are more libraries for. In Java, it's a lot harder to make mistakes due to the inherent readability of the language, both for people, but also for tools. That said, it's still easy enough to make a mistake.

Please try the book "Java Puzzlers" if you are certain that you can find most Java bugs. I could figure out most bugs, although probably not on first sight. And definately not on first sight on a Friday afternoon. The funny thing is that I find most bugs in really "easy" pieces of code. You write those in a hurry, and are more bound to make mistakes. 90% of bugs are of the kind "jeez, I cannot believe I was that stupid." Currently, someone else is writing Unit tests for my code. It's amazing how many (small but irritating) mistakes one can make.

If I could, I would first put things through static analysis, then create developer tests, then have my code reviewed by somebody else and finally have unit tests written by yet another using only the specification. Finally I give it to some dumb programmers or users and let them play around with it. If a bug survives all that, it's a feature :)

To sum it all up: Yes.

Re:are these actually worthwhile?

[dubl-u]

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?

I think it depends on how good you are and how well you use the tools. My IDE (IntelliJ IDEA) has some static analysis built in and it's nice to be reminded of loose ends that I might otherwise forget. But I find it hugely helpful when working over code from non-expert programmers. I just run it and give them a list of the three thousand things they need to fix.

Automating the detection (and sometimes, repair) of stupid mistakes leaves me more time and energy to focus on the subtle and interesting ones.

Re:are these actually worthwhile?

[Llywelyn]

"In my experience, most bugs that could be detected by static analysis are usually caught relatively quickly anyway."

In my experience the *opposite* is true, at least for code that I am not writing myself.

For instance, since I started using FindBugs on our project (which is fairly large and complex as these things go, with ~5 development teams working on it and with many threads running at the same time), I've caught several potential deadlock issues that would have probably been uncaught until a deadlock happened (most likely after this is deployed), a small host of synchronization (e.g., inconsistent synchronization) and locking problems (e.g., running a bit of code outside of a try block but after the lock is acquired), some memory/performance problems (e.g., inner classes that should have been declared static), and other things of that nature.

I might, if I went through all of the code by hand, catch all of these issues and a few more, but a tool such as FindBugs gives me a better idea of where to look, and allows me to quickly make a bunch of useful changes without combing through each file that uses synchronization by hand. Sure, a dedicated review of the code would be best, but these are usually changes I can make quickly and easily, and some of these problems might have been difficult to find otherwise (e.g., inconsistent synchronization).

There is also the benefit in that, while giving me an idea of where to look, it helps me catch other issues that FindBugs does not directly detect.

Re:are these actually worthwhile?

[matfud]

Most are trivial to run on your code, in a one off fashion. Try one or two and see what results they give you. If they find a lot of issues then it may be worth your while investing the time to integrate one, or more, of them into your build system. If they don't then don't use them.

Re:are these actually worthwhile?

[Tofflos]

Yes.

They're a great way to learn about best practices. Instead of having to read a book you get your own "teacher" that points out common misstakes in your own code. How great is that!? The misstakes it finds arn't always what I would consider trivial either. Some are very subtle and can only be found be being "burned" by an all-night debugging-session.

I've tried PMD and it only takes five minutes to set up and you'll learn more about the intricacies of Java immediately AND save time later on by avoiding bugs.

PS! Set it up as part of your automated build-process. Read the warnings as if they were compiler messages.

Re:are these actually worthwhile?

[Anonymous Coward]

Well, I would definetely recommend trying FindBugs. It's easy to use, requires no extra constructs in your code (because it's a bytecode analyzer) and takes relatively little time to run. You don't even have to install it, it can run as a JNLP from the project homepage :) It's well worth a go, I don't claim to be a great java coder by any means but it's found several potentially fatal (possible NPE etc) bugs in my code that the compiler missed and I probably wouldn't have found until they happened otherwise.

Also it suggests performance optimisations, most of these should be fairly obvious to experienced coders (Vector vs ArrayList, String concatenation in a loop etc) but some of them are more obscure.

Just use a real compiler with good warnings

[Anonymous Coward]

And compile at the highest warning level. Code is not done until it compiles cleanly.

And always remember - "size_t" is "size_t" - NOT "unsigned int". You are NOT smarter than the defined types that are STANDARD and IMPLEMENTATION-DEFINED. Think so? Try compiling your code as a 64-bit application.

That's great...

[Anonymous Coward]

... until Sun relases a new JRE and all your old aplications do not work at all anymore when users install the new JRE. Unmaintained applications die altogether or require constantly uninstalling and installing various JREs to run them as well as new ones. That's the biggest bug of all in Java and makes any bug tracking useless, and programming in Java pointless.

C/C++ applications tend to work for decades and can be written to be far more reliably cross-platform.

Java sucks bad, face it.

Re:That's great...

[Anonymous Coward]

... until Sun relases a new JRE and all your old aplications do not work at all anymore when users install the new JRE. Unmaintained applications die altogether or require constantly uninstalling and installing various JREs to run them as well as new ones. That's the biggest bug of all in Java and makes any bug tracking useless, and programming in Java pointless.

C/C++ applications tend to work for decades and can be written to be far more reliably cross-platform.

Java sucks bad, face it.

The only thing that "sucks bad" is language fanatics like yourself. By the little text above any Java developer realize that YOU NEVER WORKED WITH JAVA IN YOUR LIFE. And then make the laughable claim of "cross-platformness" in C++, which is natively compiled (can you run linux executables in windows with no extra effort?) and doesn't even have a standard cross platform library.

I have worked with Java for some years now, and:

- The "problems" you describe don't exist;
- I am liking Java more and more after each version because it's always improving in ALL fronts;
- at this point in time, Java IS THE BEST PLATFORM for developing software. It has the most complete cross platform class library, the language construts enables the production of readable and safer code, the best tools, lots of open source projects (surpassed even C++ at sourceforce) and the greatest mindshare.

All opensource options, no exceptions, are either incomplete in tools, in libraries or in features, or have sub-optimal performance.

Re:That's great...

[Decaff]

... until Sun relases a new JRE and all your old aplications do not work at all anymore when users install the new JRE. Unmaintained applications die altogether or require constantly uninstalling and installing various JREs to run them as well as new ones. That's the biggest bug of all in Java and makes any bug tracking useless, and programming in Java pointless.

C/C++ applications tend to work for decades and can be written to be far more reliably cross-platform.

Odd. I have found exactly the opposite. Java is very well know for the excellence of its backward compatibility, and to say 'all your old applications don't work anymore' is just plain false. Java would not have had the huge success it has had if this were not the case, so your statement is plainly wrong.

On the other hand, C/C++ version bugs are well known and well documented - just think of the issues involved with gcc versions and linux kernel compilations. I have a very simple C++ app that compiled and ran fine on one version of gcc, but broke on another.

If you simply exchange C/C++ for Java, and vice versa, throughout your post, it then makes sense.

Re:That's great...

[Anonymous Coward]

See, it's funny because he accused the other guy of being a language fanatic.

Re:That's great...

[Anonymous Coward]

GCC did not even come close to implementing the C++ standard until 3.2 - Your program was not C++, it was implemented in the C++-like dialect that earlier versions of g++ implemented.

This is often the case for pre-standard C++ programs.

Re:That's great...

[Decaff]

GCC did not even come close to implementing the C++ standard until 3.2 - Your program was not C++, it was implemented in the C++-like dialect that earlier versions of g++ implemented.

This is often the case for pre-standard C++ programs.

(1) It was indeed C++.

(2) This has been an issue with C/C++ - compilers that are allowed to label themselves as C/C++ that aren't compatible. This is not the case with Java.

Re:That's great...

[Anonymous Coward]

Oh yes they do exist, I have seen dozens of applications die from one JRE to another... 1.4 killed apps that ran on 1.3, 1.5 killed apps that ran on 1.4... I'm sure the trend will continue.

If Java is cross platform then why is there a different JRE installer for each OS? It is not cross platform at all. It is a piss poor substitute for the band-aid of virtualisation.

C/C++ properly written, is far more cross platform than Java. And you only need to compile it once for each platform.

Clearly you are a youngin that has been indoctrinated by educators because it seems that java is all they will teach nowadays. I fail to understand why. I assume its laziness, lack of funding and loss of touch with the real world.

Show me an operating system written in java. Well? There you go.

Someone below refers to Fedora 5 compilation issues. Well if you do not try to compile code on RedHat's abomination of an operating system you'll do just fine.

I have compiled the same code on FreeBSD, QNX, Slackware and Windows year after year with little to no modification. Mostly just configuration parameters. It only needs to be compiled once to run and performs thousands of times better than any java application ever will.

I am not an open source zealot, I am a steadfast windows user and I'll admit I'm a QNX fanboy. Both proprietary platforms. The same code will compile fine on both. Not only that it will run lightning fast and will not stop working, unlike java.

On the other hand it seems you are clearly some kind of head-in-the-sand, ignore the truth, my teacher told me so it must be true, java zealot.

C++ binaries compiled and run on QNX have sub-optimal performance compared to java (on any platform)? Now there is clueless zealotry and blind faith.

Get some real world experience, you'll see I'm right.

Re:That's great...

[Jagungal]

Clearly you are a youngin that has been indoctrinated by educators because it seems that java is all they will teach nowadays. I fail to understand why. I assume its laziness, lack of funding and loss of touch with the real world.

I find it amusing that all of the people posting about their positive experiences with Java have user id's less than 50000, meaning they have been around here quite a while.

  The trolls are all anonymously sprouting FUD .... maybe the anonymous Trolls need to come out of thier holes and visit the real world now and then.

Re:That's great...

[handsome b]

You've clearly never ever developed anything in Java before. Perhaps you've heard the saying "Do not hold strong opinions about things you do not understand"... I've been developing a fairly large Java application for over 5 years, and the old beta versions that were written for Java 1.3 work unmodified on the Java 1.6 beta.

Your statement is 100% false, face it.

Re:That's great...

[Anonymous Coward]

Oh yes they do exist, I have seen dozens of applications die from one JRE to another... 1.4 killed apps that ran on 1.3, 1.5 killed apps that ran on 1.4... I'm sure the trend will continue.

No, they don't exist. So I guess we are even now, my word against yours.

Clearly you are a youngin that has been indoctrinated by educators because it seems that java is all they will teach nowadays. I fail to understand why. I assume its laziness, lack of funding and loss of touch with the real world.

I am the poster of the previous post and as a matter of fact I studied C and a bit of C++ for OO concepts in college, along with some other languages, and NONE of them were Java because my college was an "all Microsoft" college.

I started working with Java out of my free will, no one told me to, and I was surprised to find an excellent platform to develop with.

If Java is cross platform then why is there a different JRE installer for each OS? It is not cross platform at all. It is a piss poor substitute for the band-aid of virtualisation.

This one was lame! hahahaha. Each OS has it's own way of managing the applications and being an executable the user can just click on and the application magically appears in the control panel of Win XP makes things easier. Just convenience.

C/C++ properly written, is far more cross platform than Java. And you only need to compile it once for each platform.

That's a very big "IF", especially in the internet age.

I have compiled the same code on FreeBSD, QNX, Slackware and Windows year after year with little to no modification. Mostly just configuration parameters. It only needs to be compiled once to run and performs thousands of times better than any java application ever will.

I have run the same application written in Java (just run, not recompiled) on Windows XP, Solaris, AIX and Linux and and it's easier to maintain than any C++ code will ever be.

I am not an open source zealot, I am a steadfast windows user and I'll admit I'm a QNX fanboy. Both proprietary platforms. The same code will compile fine on both. Not only that it will run lightning fast and will not stop working, unlike java.

On the other hand it seems you are clearly some kind of head-in-the-sand, ignore the truth, my teacher told me so it must be true, java zealot.

C++ binaries compiled and run on QNX have sub-optimal performance compared to java (on any platform)? Now there is clueless zealotry and blind faith.

Ok, this is a big sequence of idiocies. Please reread the previous post and understand what I said. And all your claims of "lightining fast", "never stops working", have absolutely no grounds on reality.

The mere deletion of a shared library or the replacement for a newer version is enough to make an application to stop working. I use Linux and I have seen this happening.

BTW, is Openoffice "lightning fast"? Is X.org "lightning fast"? Is KDE "lightning fast"? These BIG applications running on Linux are FAT and SLOWER than should be.

Get some real world experience, you'll see I'm right.

I have been working with Java for the last 5 years and in IT for the last 8 years.

Re:That's great...

[Anonymous Coward]

BTW, is Openoffice "lightning fast"?

No its horrifically slow, its a java application. Buahahahahaha! You kill me, thanks for the laugh.

Get a clue.

Re:That's great...

[Anonymous Coward]

Ok, this is a big sequence of idiocies. Please reread the previous post and understand what I said. And all your claims of "lightining fast", "never stops working", have absolutely no grounds on reality.

Gee, I wonder why I've never seen data aquisition software to control GHz sampling rates written in Java?

I wonder why I've never seen an operating system written in Java?

I wonder why I've never seen a proper webserver written in Java?

I'm sorry if you cannot accept the reality that java is a language for toy applications.

It is not platform independent, it is not reliable.

Re: the comment about randomly deleting libraries? (gee that's a real good idea...) Only pussies rely on third party libaries to make their code work. That is a total copout. But tehn I guess Java is perfect for that, good for slackers with 8 years in IT with no idea of the historey of reliable mission critical software.

Re:That's great...

[Anonymous Coward]

No its horrifically slow, its a java application. Buahahahahaha! You kill me, thanks for the laugh.

All those C++ sources then are just for decoration, aren't they?

OpenOffice was always slow and was always written in C++.

Re:That's great...

[Anonymous Coward]

I find it amusing that all of the people posting about their positive experiences with Java have user id's less than 50000, meaning they have been around here quite a while.

OK, slashdot user id's are a measure of programming knowledge? Give me a break. I'd say its more a of a measure of slackers who aren't willing to spend the time to write quality portable code.

Show me a java application that actually does something useful in a mission critical environment that performs better than a C/C++ application for the same task and is truly platform independent. I'm sure you'll find that challenge quite impossible.

I'm sure I was posting to newsgroups from a vax terminal long before slashdot existed. Just because I have chosen not to register here has no meaning whatsoever.

Re:That's great...

[Anonymous Coward]

Re: the comment about randomly deleting libraries? (gee that's a real good idea...) Only pussies rely on third party libaries to make their code work. That is a total copout. But tehn I guess Java is perfect for that, good for slackers with 8 years in IT with no idea of the historey of reliable mission critical software.

I am sure that an "Anonymous Coward" on slashdot knows everything about "mission critical software". If you want to talk about what Java is capable of then STUDY before posting crap on the internet.

You don't even research before making blind claims and want to call other people "slackers". You need to reevaluate your life, loser.

Re:That's great...

[Anonymous Coward]

You've clearly never ever developed anything in Java before. Perhaps you've heard the saying "Do not hold strong opinions about things you do not understand"... I've been developing a fairly large Java application for over 5 years, and the old beta versions that were written for Java 1.3 work unmodified on the Java 1.6 beta.

Your statement is 100% false, face it.

You've clearly never developed a java application that handles binary files on disk before.

Did your application work on 1.4? 1.5?

Just because your application does not call anything that has changed does not mean that countless others do not.

I have seen dozens of java applications that do more than draw pretty picures and handle text broken by each and every JRE release.

My statement is 100% true. Face it.

And to comment on bug-finding utilities: if you fully understand exactly what your application is doing at every point, and do not rely on someone else's code (read libraries or classes) and know exactly how it will be used, there will be no bugs.

Automated testing and QA is worthwhile however, such as testing a cobol application re-write with a C++ application.

Re:That's great...

[Anonymous Coward]

Posted by Anonymous Coward:

I am sure that an "Anonymous Coward" on slashdot knows everything about "mission critical software". If you want to talk about what Java is capable of then STUDY before posting crap on the internet.

The irony of this post does not escape me - funny stuff. Most entertaining.

You have yet to show me java data aquisition software, operating systems, webservers... I know "mission critical software" quite well, used internationally and subject to multiple sets of federal regulations.

Java is still for toys and trinkets, sorry that offends you.

You need to reevaluate your job, loser.

Re:That's great...

[mjtaylor24601]

"if you fully understand exactly what your application is doing at every point, and do not rely on someone else's code (read libraries or classes)..."

you'll drop dead before you ever finish writing it.

Re:That's great...

[syousef]

Well you've obviously never written anything in a complex Java environment. I've seen apps I've worked on break in 1.5 where they worked fine in 1.4.2_08. This caused our team huge headaches because it was an applet problem that had already been installed on a lot of client machines, some external to the organisation I worked for.

I don't know the GP from a bar of soap, but if you're going to call someone a liar how about you check your facts first.

Re:That's great...

[iapetus]

Show me a java application that actually does something useful in a mission critical environment that performs better than a C/C++ application for the same task and is truly platform independent. I'm sure you'll find that challenge quite impossible.

Because it's a ridiculous challenge, perhaps, and ignores a whole range of things that are actually more important? I've seen plenty of Java applications that do something useful in a mission critical environment, and there are no C/C++ applications for the same task because the Java one works just fine. You've also completely ignored the question of ease of development and maintainability, which is worth far more than raw performance in a real-world environment where throwing an extra CPU at the job is cheaper than hiring another developer to bug-fix.

Re:That's great...

[Jagungal]

OK, slashdot user id's are a measure of programming knowledge?

  No but AC posting is often the measure of a clueless troll, not always but in your case it seems to fit well.

Show me a java application that actually does something useful in a mission critical environment that performs better than a C/C++ application for the same task and is truly platform independent.

If you look you will find there are plenty of java applications that do what they need to do, are as fast as any C/C++ application , are robust, easy to maintain and are cross platform. In fact Java applications are most likely doing a whole bunch better these days compared to C/C++ applications in the business arena.

Your attitude is very 90's, Java has come a long way since then. I suggest you grow up and have another look at whats out there.

Re:That's great...

[Decaff]

Well you've obviously never written anything in a complex Java environment. I've seen apps I've worked on break in 1.5 where they worked fine in 1.4.2_08. This caused our team huge headaches because it was an applet problem that had already been installed on a lot of client machines, some external to the organisation I worked for.

It is great the way that posters assume things! I work on substantial Java applications daily - apps with hundreds of thousands of lines of code.

There are very complex Java applications that run unchanged on different versions of Java - JBoss, NetBeans for example. These are app servers and IDEs - it is hard to think of apps that are more complex. I have never seen a single app break between Java 1.4 and 1.5.

Re:That's great...

[syousef]

It is great the way that posters assume things! I work on substantial Java applications daily - apps with hundreds of thousands of lines of code.

Talk about the pot calling the kettle black. You called the GP a liar because his experience didn't match yours. How dare you then come back and point the finger at someone making assumptions you hypocrite!

There are very complex Java applications that run unchanged on different versions of Java - JBoss, NetBeans for example. These are app servers and IDEs - it is hard to think of apps that are more complex


I have never seen a single app break between Java 1.4 and 1.5.

Well I have. "It works for me on my machine so stuff you" is nonesense that no professional should be uttering, let alone calling a perfect stranger a liar because they've seen something you haven't.

Explain my experience then. I'm either lying (and I happen to know for a fact that I'm not, and would gladly prove it if it didn't require breaking my contract and if I thought it would sway you one bit).

JBoss and Netbeans are just two technologies. Most of my experience happens to be with Eclipse though I have used Netbeans, and Weblogic though I've also used Tomcat and JBoss. So what. There are more technologies out there that neither of us have used than you could shake a stick at and to make the assumption that no applications have broken just because you haven't seen it is both arrogant and ignorant.

What do you do when your users complain there's a bug you can't reproduce? Shut your eyes, put your hands over your ears and shout "la la la la la" at the top of your voice? /. stupidity never ceases to amaze me.

Re:That's great...

[Decaff]

Talk about the pot calling the kettle black. You called the GP a liar because his experience didn't match yours. How dare you then come back and point the finger at someone making assumptions you hypocrite!

No, I did not call the GP a liar. I am careful with wording.

Well I have. "It works for me on my machine so stuff you" is nonesense that no professional should be uttering, let alone calling a perfect stranger a liar because they've seen something you haven't.

Again, I did not call him a liar.

Explain my experience then. I'm either lying (and I happen to know for a fact that I'm not, and would gladly prove it if it didn't require breaking my contract and if I thought it would sway you one bit).

Then why are you bothering posting if you can't prove it? I am not saying you are lying. It is certainly possible to write apps that break from one JRE to another, but it is also pretty simple to ensure they don't - the release period between JREs are long, and the guidelines are clear. But if you can't provide actual evidence, what is the point?

JBoss and Netbeans are just two technologies. Most of my experience happens to be with Eclipse though I have used Netbeans, and Weblogic though I've also used Tomcat and JBoss. So what. There are more technologies out there that neither of us have used than you could shake a stick at and to make the assumption that no applications have broken just because you haven't seen it is both arrogant and ignorant.

They aren't just two technologies - they are illustrations of a wide range of aspects of the JRE - GUI, multithreading, file handling, networking, concurrency. If anything should break between releases, these should.

I did, of course, not say that no applications have broken. I said I have not seen any that have broken, and this includes very complex apps.

What do you do when your users complain there's a bug you can't reproduce? Shut your eyes, put your hands over your ears and shout "la la la la la" at the top of your voice? /. stupidity never ceases to amaze me.

I fix the bugs. I deal with them. I write my apps and test them on different JREs. To write an app so tied in to one JRE that it breaks on a new one is, these days, inexcusable and a sign of bad development practice. If Tomcat and NetBeans can manage for this not to happen, so can everyone else. There has rarely been a technology that is so backwards compatible as Java.

Re:That's great...

[syousef]

The GP complained that he'd seen Java apps break. You said you hadn't and that you couldn't imagine more complex apps. You were definitely implying he was a liar. This isn't a court of law so burdens of proof don't apply here. To me your intent was very clear.

In your latest post again you insist that because you haven't in your very limited experience seen Java apps break, that it's rare. It's not.

Google for the following phrase:
java 1.5 breaks application

You get such links as:
http://developer.apple.com/qa/qa2006/qa1474.html
http://forums.macosxhints.com/showthread.php?t=475 31

That's just the tip of the iceberg and I'm not going to do any more work proving that things have broken because with your attitude I don't see you admitting to a mistake.

Guess what happens if you use any 3rd party product that is in any way incompatible. You need to get another version of that product.

Now you're obviously not interested in reality. In your mind because you haven't had the displeasure of working on something that's been badly broken by a JRE release all is good. Enjoy living your fantasy but don't force it down other people's throats or belittle them when they point out that they've seen it happen.

Re:That's great...

[Decaff]

The GP complained that he'd seen Java apps break. You said you hadn't and that you couldn't imagine more complex apps. You were definitely implying he was a liar. This isn't a court of law so burdens of proof don't apply here. To me your intent was very clear.

No, I was clearly saying that complex apps obviously don't break with version changes.

In your latest post again you insist that because you haven't in your very limited experience seen Java apps break, that it's rare. It's not.

Yes, a very limited experience based on being a developer for 30 years and using Java since it came out.

You get such links as:
http://developer.apple.com/qa/qa2006/qa1474.html
http://forums.macosxhints.com/showthread.php?t=475 31

That's just the tip of the iceberg and I'm not going to do any more work proving that things have broken because with your attitude I don't see you admitting to a mistake.

Oh for goodness sake! This suggests that you really don't understand the issue! Those links you showed aren't the 'tip of the iceberg' - they are most of it. Of course things wont work if you compile specifically for a later version of the JRE and then expect it to run on them. That is a crazy as expecting an app compiled for MacOS/X to run on Mac OS 7!

This is not an issue of JRE upgrates breaking existing apps - it is an issue of using a JDK upgrade and not taking into account the fact that the compiler produces code for the equivalent JRE. There is nothing wrong with than, and a simple switch can change this.

Guess what happens if you use any 3rd party product that is in any way incompatible. You need to get another version of that product.

Only if that 3rd party product relies on a later JRE or JDK, in which case it is entirely reasonable.

Now you're obviously not interested in reality. In your mind because you haven't had the displeasure of working on something that's been badly broken by a JRE release all is good. Enjoy living your fantasy but don't force it down other people's throats or belittle them when they point out that they've seen it happen.

I haven't worked on something that has been badly broken by a JRE release, because few people have. You haven't shown any such thing. All you have shown what happens if someone compiles for a later JRE and tries to run it on an earlier one. Do you seriously expect all your clients to automatically upgrade to JRE 1.5? Of course not. It is your responsibility as a developer to take into account the versions of runtimes your clients use. If you update your compiler (javac), it is your fault if things break.

Re:That's great...

[Jagungal]

You get such links as:
http://developer.apple.com/qa/qa2006/qa1474.html
http://forums.macosxhints.com/showthread.php?t=475 31

That's just the tip of the iceberg and I'm not going to do any more work proving that things have broken because with your attitude I don't see you admitting to a mistake.



  This is quite laughable. Both of these links have nothing to do with the fantasy that you are trying to propogate.

  Your credibility = 0

Re:That's great...

[vidnet]

This is quite laughable. Both of these links have nothing to do with the fantasy that you are trying to propogate.

    Your credibility = 0

I second the zero. Cough up some code, troll, or admit that you're a 15 year old who recently wrote a CS101 fibonacchi generator in C++ and thus you hate java because all cool c++ gurus on teh intarwebz do.

Re:That's great...

[syousef]

This is quite laughable. Both of these links have nothing to do with the fantasy that you are trying to propogate.


The "fantasy" I'm trying to propogate? You're truely dillusional and brainwashed if you believe that upgrading or changing your JRE can't break your apps. Have fun living in your fantasy. A credibility raiting from a fool is of no interest or consequence to me.

Re:That's great...

[syousef]

Look I've seen code break. You haven't. I don't care if you get a team of 30 coders with a combined experience of 900 years to tell me their apps haven't broken. I've seen apps break, and not only when the code's compiled for a later JRE. We've had to develop specific workarounds and re-release stuff due to this. I can't show you because I'm bound by an employment contract and I'm not about to embarass my employer even if I wasn't. That you don't believe me doesn't make an inkling of difference to my life. Enjoy your fantasy.

If you are going to reply at all the first thing I challenge you to do is explain this migration guide by Sun for Java 1.3 to 5.0:
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf ...complete with a whole section on runtime issues

More references. Again not the best. Wish I could show you my good example but see above.
http://forum.java.sun.com/thread.jspa?threadID=731 921&messageID=4212821
http://www.codecomments.com/archive251-2005-5-4986 00.html
http://forum.java.sun.com/thread.jspa?threadID=432 494&messageID=2042086
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4783788
http://helpdesk.wisc.edu/page.php?id=2891
http://www.javalobby.org/java/forums/t18329.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6204839

The above links very clearly show installing the latest JRE is not sufficient to run all your old code. With many Java applications, you can't just remove all older versions of a JRE and upgrade to the latest.

I also recall that if your code is applet based, the tags used to invoke the JRE changed after Microsoft dumped their custom JVM due to the legal action between Sun and MS.

The bottom line is that you're calling anyone who has seen anything break due to a newer JRE a fool and a liar based on your "30 years of experience". I know for a fact that this is false. Your arrogance is astounding and your insistance on this makes me wonder what you've been doing for 30 years since I know of no complex environment where the runtime backward compatibility is so fantastic that you don't need to test a new version to be sure it works for your application.

Re:That's great...

[syousef]

Here you go. Get your info straight from Sun. See the section on runtime errors.
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf [sun.com]

Getting your adolescent friends to second your opinion or creating a second account to bolster yourself is completely juvenile.

For your info I'm over 30, have a bachelor and masters, and have been doing this for some years...all of which has no bearing on the truth of what I've said of course.

Re:That's great...

[Decaff]

First, let me say that you seem to have a tendency to respond to what you think I wrote, not what I actually did.

I have never said that no apps ever break with JRE upgrades, or that you never need to test things with different JREs

What I have actually said is that issues with JRE updates are rare. Java is one of the most backward-compatible systems ever produced. Nothing you have said and no links you have provided have demonstrated otherwise. You seem to be considering matters of how to access JREs or how to package applets as if they were somehow related to the Java language and compatibility. They aren't. You have provided a very minor list of issues that may occur when people upgrade from Java 1.3 (released 6 years ago!) with Java 1.5. That minor list simply emphasises how few programs are going to break, and the minor matters involved.

I realise you are not in a position to give a personal example, but that does not help the debate. Until you can give some specific reason, I can't see any point in continuing.

If anything, this conversation has helped prove my point - that the suggestion made by a poster a while back that 'all your old aplications do not work at all anymore when users install the new JRE' is utter nonsense. (note the use of the word 'all' - not 'some', or 'a very few', but 'all'!).

It it is so obviously nonsense that I can't see why anyone is bothering to argue against it.

Re:That's great...

[syousef]

First, let me say that you seem to have a tendency to respond to what you think I wrote, not what I actually did.

Let me say you have a tendancy to word things so as to imply other things, then back down when confronted with facts.

What I have actually said is that issues with JRE updates are rare.

I say bollox to that.

Java is one of the most backward-compatible systems ever produced.

It's one of the most widely used systems that has been designed with backward compatibility in mind, I grant you that.

Nothing you have said and no links you have provided have demonstrated otherwise.

Yes typically if someone wants to be stubborn nothing convinces them to change their opinion.

You seem to be considering matters of how to access JREs or how to package applets as if they were somehow related to the Java language and compatibility. They aren't.

Wait a second there and get your straw man out of my face. You are claiming that Java (I presume that includes the runtime) is "one of the most backward compatible systems ever produces" then you takl about Java the language separately as if that's all you were ever speaking off. The grand parent didn't go into language syntax, he said JREs broke. Make up your mind what you're arguing and stop trying to employ such obvious sophistry.

You have provided a very minor list of issues that may occur when people upgrade from Java 1.3 (released 6 years ago!) with Java 1.5.

Shall I go and chase down every change between minor versions that caused something to break? I've demonstrated my point which is that it's not all that rare. If Sun thought it was important enough to produce a document, and most sane developers feel the need to retest with new JREs I'd say compatibility is an issue.

Go find some 1.0.2 code from the .com bust and try and run that without any kind of change. If it's complex I'd give you even odds it breaks.

That minor list simply emphasises how few programs are going to break, and the minor matters involved.

I think if I went and pulled down 1000 examples you'd claim they're only minor. The word fanboy comes to mind.

realise you are not in a position to give a personal example, but that does not help the debate. Until you can give some specific reason, I can't see any point in continuing. ...and yet you do continue.

If anything, this conversation has helped prove my point

Only if you're in the habit of ignoring problems and hoping they'll go away.

that the suggestion made by a poster a while back that 'all your old aplications do not work at all anymore when users install the new JRE' is utter nonsense. (note the use of the word 'all' - not 'some', or 'a very few', but 'all'!)

I think you know perfectly well that all was an exaggeration. Java is designed with the intent of backward compatibility. However many many apps do break. You just dismiss it as so rare no one should bother worrying about it.

Summary of this debate. You spot a post where someone points out Java isn't always compatible between releases and that this can cause a headache. You say I've rarely seen things break. I say I have seen things break quite a bit and provide what examples I'm free to. You insist these are minor and choose to ignore them.

Good luck. I live in the real world. If I depend on something, I expect some breakage between versions and test and fix accordingly. I think that's a much better solution than yours which is to tell people its rare. Not just for Java. For any software btw not just Java: Every version of Windows breaks some apps. I'm not saying don't use any piece of software but I am saying don't pretend change doesn't break things no matter how well done.

Another nifty static analysis project

[tcopeland]

...is Sun's Jackpot, headed up by Tom Ball. What's neat about Jackpot is that it does problem fixing, too, using a domain specific language. From the interview:

    $object.show() => $object.setVisible(true) ::
            $object instanceof java.awt.Component;

Feeding that DSL snippet to Jackpot will transform all Component.show() calls to Component.setVisible(true). Very, very cool stuff. Of course, you don't always want to make the transformation, but in the cases where you do, Jackpot looks like a great solution.

doesn't findbugs do this

[josepha48]

I think findbugs does this. I've started using it and it found lots of bugs in my code. As a result I have learned a few things about java, just by using it and fixing my bugs.

Re:doesn't findbugs do this

[tb25549]

Jackpot does bugs similar to findbugs, but then writes the change back to your source code (after you accept the preview). It's not just a bug finder but a bug fixer, too.

No libraries?

[SuperKendall]

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.

C++?

[Anonymous Coward]

There seems to be nice ones for Java and C. But does anyone knows what is out there for C++, appart of the commercial service of Coverity?

Re:C++?

[Anonymous Coward]

http://www.polyspace.com/

Re:C++?

[baconstandards]

QAC++ made by Programming Research Its by far the best static analysis tool out there. They also make QAC which again i find to be the best startic analysis for C. Very useful when coding for embedded systems i believe they also make QAJ, but i dont think its as good as their main two tools

Why a seperate tool?

[roman_mir]

If this bug detection is as good as they say, it should be part of the compiler. If it is not good enough to be part of the compiler, I wouldn't bother with it.

Re:Why a seperate tool?

[bytesex]

Amen. What do they mean with 'patterns' in this case anyway, or is it just a fashionable excuse to name-drop the term 'pattern' again ? The one example they're giving is so easy to circumvent, and so difficult, therefore, to detect, that I wish them all the luck in the world if they're planning to concentrate on this. I'd go for easier options, me, indeed as part of the compiler:

boolean b; if (b = false) { ... }

while (in.readline() != null) { String str = in.readline(); } // seriously, I came across this once.

That sort of thing; what they're trying to do is write a Gang-of-four-validator. Helpfull for CMM level 5 corporations, but a project of such magnitude is better left to the likes of IBM. Until then, I'm afraid I'm going to look at it with a pinch of scepsis.

Re:Why a seperate tool?

[matfud]

Many of these checkers are basically advanced pattern matchers. They contain a set of pattern templates that will match code (or bytecode) that contains bugs. They check for, as an example, a variable that is used without a check (if(null!=bla)) but may not be assigned. The compiler does not catch this because the variable is not marked final. Its a trivial pattern to check for.

They can also perform some concurrency checks. Such as looking for a pair of locks that are obtained in different order in different parts of your code. Or for waiting threads that can never be woken up (i.e. nothing calls notify on the lock). Note that in java the second example is not necessarily a bug.

Some of the patterns have high false positives, some are almost guarenteed to find a bug. Unfortunately these tests can be quite expensive to perform and are not guarenteed to find issues. I think this is why they are not in the compiler. The compiler tells you about everything that can be guarenteed to be a problem. In java the compiler tells you if you break the language specification. It does not tell you if you do stupid things that the language spec allows you to do.

matfud

Re:Why a seperate tool?

[roman_mir]

Which supports my original statement: I wouldn't bother with these detectors, I would rather insist on updated unit-tests and add more unit-tests as new bugs are discovered and fixed (including race-conditions.)

Re:Why a seperate tool?

[matfud]

Unfortunately you cannot write unit tests that will find all race conditions. They may find some (common one that will occur often) but unless they can run forever they will not find all. These detectors are a useful tool, nothing more, nothing less. They are not supposed to replace good unit tests. However they can find issues that units tests cannot. Even if your unit tests give you 100% coverage that only means that they exercise all of your code. It does not mean they excersie all of your code in all situations. These code checkers can help a bit. Since most are fully automated there is little reason not to use them (i.e. no coding required for you to use them)

matfud

Re:Why a seperate tool?

[roman_mir]

Of-course unit-tests can't find all race conditions. But this bug-detector won't find all race conditions either.

Again, I wouldn't bother with it in most real-life situtations. We all have deadlines and resource limitations. Besides Java is mostly used on the back-end today and it is mostly used within some J2EE container. Manual thread management should be avoided as a matter of principle in these situations and the resources that are shared must be thread safe. The best thing to do is to avoid complexity where possible rather than try and solve an already existing problem.

However I had to work on various projects where I had to manipulate threads and shared resources by myself outside of any container. More than that, I had to coordinate Java threads with C++ threads that were used as middle-tier and connected driver functionality of C code to Java front-end. And in that situation there was no way any automated tool could help me with all the complications, I just had to think my way through the problems and debug them and as I was debugging them I created the necessary unit-tests. The bottom line is I think these tools are too primitive for really complex situations and at the same time they are too much for most of coding that is done in Java and J2EE. So again, I would rather see people write and maintain good unit-tests.

Re:Why a seperate tool?

[matfud]

I can only suggest that you try one and see what it does for you.

J2EE is a framework that tries to hide multithreading issues from the coder. As such (and per recomendation by sun) you should try to avoid creating your own threads. However threading issues still affect you. Perhaps it is a cache you need all servlets/beans/whatever to use. You may be able to use a third party library you may not. Even if you do use a third party library are you 100% confident that it has no synchronization/threading issues? These tools can help.

I have noticed that many coders do not understand all of the issues presented by thread handling, concurrency and re-entrent behaviour. I don't have time to check all code and even if I could I do not have a memory that enables me to correlate all calls to an entity. These checkers can check all of your code and they can remember all useages of an entity. They are thorough in a way that humans can not be. Give it a try you may be surprised.

matfud

Re:Why a seperate tool?

[roman_mir]

Perhaps it is a cache you need all servlets/beans/whatever to use. - taken care of by the EJB container. If you are talking about static caches (such as collections) there are thread safe patterns to handle them.

Even if you do use a third party library are you 100% confident that it has no synchronization/threading issues? These tools can help. - help with what? You are giving a blanket statement here that the tools will help with something. I say don't bother unless there is a problem. Sure, if there is a problem do what you want, load these tools, try them. I bet at the end you will end up debugging by hand.

I have noticed that many coders do not understand all of the issues presented by thread handling, concurrency and re-entrent behaviour. - this is what J2EE is about: removing these problems from your average programmer list of issues. The average programmer who has problems with these concepts shouldn't have to think about them, and that is one of the points that J2EE covers.

Now memory leaks, those are interesting problems. But I guarantee that memory leak detection falls into the ATM Halting category and can be detected or detected/resolved in runtime much easier than in compile time (that is IF the coder doesn't find the problem right away.)

I would say that a profiler tool would be much more useful for any coder, beit average, novice or a guru than this bug detector.

Re:Why a seperate tool?

[MoeDrippins]

"If this [unit test] is as good as [you] say, it should be part of the compiler. If it is not good enough to be part of the compiler, I wouldn't bother with it."

Your statement is ludicrous. That something isn't part of the compiler does not make it not useful. Taken ad absurdum, do you *ONLY* use the tools that are part of your compiler, and not, say, your IDE? Eclipse, IDEA, etc. have many useful tools that help solve problems, preempt issues, help you out... do you not use those? Why not use the tools if you are given the chance to do so?

Re:Why a seperate tool?

[matfud]

Profilers are very usefull. Unit tests are very usefull. Static code checkers are also usefull. Try one. Unless your codebase is perfect they will find issues with it. Many of the issues will not be bugs (depending on the options you set on the checker) but will likely indicate a poor or overly complex coding style. It will likey take 30 mins of your time to assess the utility of the checker. It may save you far more time then that. I partially agree with you that the checkers are not as good as some of thier proponents make them out to be but they do serve a useful purpose. I still have not integrated any into the build system I use (a big task for us) however I have run a few and they have found problems in our code. Note that they have not found all problems in our code. We still have bugs even after copious unit tests, profiling, static analysis. They can rule out some issues that unit tests cannot, they can rule out some issues before you need to take a debugger/profiler to your code. They can find some issues that you are remarkably unlikely to find by other means.

As for halting, the theory sates that you cannot come up with a general algorithm that will prove all code/input pairs halt. This does not mean that a generic algorithm cannot prove that halting occurs for a specific code/input pair. Event if, for the pair you are using, the general algorithm cannot prove the code halts it does not mean that the code fails to halt. It only means that the algorithm used cannot prove that it halts. This would be a reason to investigate the code further.

help with what? You are giving a blanket statement here that the tools will help with something. I say don't bother unless there is a problem. Sure, if there is a problem do what you want, load these tools, try them. I bet at the end you will end up debugging by hand.
Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. It is a blanket statement I made and I made it for the following reason: Even if the static checker finds no issues with the code that is failing it has just ruled out a large number of code issue categories. Is there a downside to this?

matfud

Re:Why a seperate tool?

[roman_mir]

Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. - that's a pretty bizarre inference. No, I write unit tests either before or during development of the actual business code. But these bug detectors don't make much sense if normal testing and operations show no problem.

Even if the static checker finds no issues with the code that is failing it has just ruled out a large number of code issue categories. Is there a downside to this? - yes, there is a downside. Every extra step in the process takes more time and resources. And most of the time these bug detectors will do zip for your normal project. You don't sit there with a profiler before you need to.

Ok, gotta go, they are running a fire alarm test here.

Re:Why a seperate tool?

[matfud]

Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. - that's a pretty bizarre inference. No, I write unit tests either before or during development of the actual business code. But these bug detectors don't make much sense if normal testing and operations show no problem.

It was taken directly from your statement:
I say don't bother unless there is a problem.
  that you shouldn't invest in preventative measures, as they are an expense, without reason to do so. You write unit tests. Why?. Becuase they can help rule out some bugs before they end up in the wild. I presume you also write integration and regression tests. These catch different kinds of errors to unit tests. Running static checkers can catch other categories of problem. Why not use them. Admittedly I would not put them into the normal build system (our codebases take too long to commit as it is) but why not in the nightly build along with your code coverage metrics?

Obviously my arguments havn't convinced you so I shall leave you in peace.

matfud

Re:Why a seperate tool?

[roman_mir]

Your statement is ludicrous. That something isn't part of the compiler does not make it not useful. - a logical fallacy. I didn't say that anything that is not part of a compiler is not useful.

Taken ad absurdum, do you *ONLY* use the tools that are part of your compiler, and not, say, your IDE? Eclipse, IDEA, etc. have many useful tools that help solve problems, preempt issues, help you out... - you are saying this, not me. I didn't say Eclipse is not useful because it is not part of the compiler. I don't know where you are coming from, what I said was very precise: this bug detector maybe useful and if it is, it should become part of the compiler. If it is not good enough to become part of a compiler, I will not use it. It is as simple as that. Why wouldn't I use some extra add on bug detector tool if it is not part of a compiler? Couldn't bother. There are many things that I could do, but I am not about to go out of my way to do them. It is a resource issue.

do you not use those? Why not use the tools if you are given the chance to do so? - I use tools that I find are useful to me. I personally think that unit tests, profilers and a compiler with its own syntax and context verifier are more useful than some third party 'bug detector' and are more cost efficient. But its my own feeling just based on my own years of work. YMMV.

Re:Why a seperate tool?

[roman_mir]

Found a wireless connection in the parking lot :) Everyone has evacuated and they won't let us back into the building today.

It was taken directly from your statement: - this is my attitude towards profilers and debuggers. Don't bother with them, unless you know there is a problem. I developed this attitude over the past 10 years of work related experience and it serves me just fine. YMMV.

that you shouldn't invest in preventative measures, as they are an expense, without reason to do so. You write unit tests. Why?. - unit tests are not preventative measures. They are a proof that the code satisfies certain conditions, gives certain output given a specific set of input. Unit tests make sense from point of view of business functions. Unit tests guarantee very specific things and it makes sense to guarantee them. Unit tests will not find bugs for you, they won't profile for you, they only check that certain conditions satisfy.

NOONE ELSE can write the unit tests for you when you are developing a project. Unit tests are also complementary documentation, they don't explain what the code is doing, they document what the code is supposed to do under certain conditions.

I insist that unit tests are much more important than bug detectors, because unit tests describe business behaviour, and I equate the bug detectors to profilers and debuggers.

Ok, cheers, I am going home now.

Re:Why a seperate tool?

[owlstead]

This is a stupid argument, because running these automated tools is pretty easy. I mean, it can find bugs without all this tedious unit-test writing. Of course, it does not relieve you from writing unit tests, and neither does it mean that it will find every possible bug. But most of the time it only takes limited amount of configuring in your software street, and every time you build something, you check out the bugs that have been found. In other words, the finding of bugs is almost for free. So why not use it? Even if they are bugs that never occur, you won't make them in other situations where they do matter, after they have been flagged.

Re:Why a seperate tool?

[roman_mir]

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.

Re:Why a seperate tool?

[owlstead]

I specifically told in the post that it does not replace unit writing. Just that it is pretty easy to run, regardless of unit-testing. It's not that hard to configure these tools, especially when you are doing it for a whole team. I've switched on PMD and walked through an entire project in one day, switching off the more useless (in my opinion) tests as I went along. This takes much less time than writing Unit tests. So why not combine both. What kind of brainless moderator put my posting down as flamebait anyway?

Re:Why a seperate tool?

[roman_mir]

What kind of brainless moderator put my posting down as flamebait anyway? - the same kind that put the original post in this thread offtopic?

use these chechers

[jilles]

I've used lint4j, pmd, checstyle and indeed findbugs. These tools are very useful. The biggest problem is finding the time to fix the issues. It's tempting to skip the minor issues but then this is where you need to be strong.

I'd recommend that serious java developers integrate the above mentioned tools into their nightly builds and treat the identified issues as real bugs.

Re:use these chechers

[owlstead]

As long as you take time to look at each bug. E.g. in PMD, it will find every field and local variable that could have been declared final. I don't even want those bugs as a warning. I want those as a tip, that does not show up as a warning for each build. It will not matter in 99% of the cases. Also, these kind of bugs should be automatically fixed, since they can be (maybe with a review screen beforehand, to exclude the ones that don't need fixing.

Re:use these chechers

[dnebin]

One of the first things I did as my new role as software lead was to standardize on using lint4j, pmd, checkstyle, and findbugs (and JUnit test cases and Cobertura coverage analysis) as a mandatory component of the software development process. Software released into test must be clear of any warnings/errors reported by these tools (or heavily documented as to why the code cannot be fixed, so far we haven't had any instances of this).

Obviously this doesn't guarantee a bug-free release, but it does ensure that any bugs in the release are really bugs and not just some errant coding issue.

The benefits we've realized so far is a reduction in these kinds of issues, but most of all it is helping the junior developers hone their skills. By fixing the errors they're getting, as they code up new modules they tend to have fewer of these errors to deal with.

Custom Bug Detectors are in IntelliJ

[johnBurkey]

IntelliJ Idea (http://www.jetbrains.com/), a java IDE, has had "custom bug detectors" in it for a while. And you can add your own, via the plugin api, and you can select which ones you want on/off, and its part of the tool, like it should be. You get a GUI for fixing it, that matches compiler based syntax errors, etc. Makes me wonder if IntelliJ features came first, or this open-source project did. Anyone know?

Re:Custom Bug Detectors are in IntelliJ

[Dave Griffith]

As the guy who developed most of the bug detectors in IntelliJ, I can answer that. The first releases of FindBugs came slightly before IDEA added its InspectionAPI. Since then, I've used FindBugs as a source of bug-finding ideas, as well as PMD, Parasoft's JTest, and some other static analysis tools. I don't know if FindBugs has similarly cross-polinated back some of IDEAs detectors, but wouldn't be too surprised if it had.

Re:Custom Bug Detectors are in IntelliJ

[johnBurkey]

Well nice job on the IntelliJ work- whats really great about it is the integration- the very things the guys have been talking about here. Also, the easy UI to turn off the religious ones your particular team doesn't like, which removes the chaff enough so you get commentary you need, and not the stuff you don't. Any issues or new things for the discussion here?

Re:Custom Bug Detectors are in IntelliJ

[Dave Griffith]

Thanks, I'm pretty proud of it myself. As for adding anything to the discussion here, I'm not sure there's much to add. The people who have used static analysis tools understand their value without being harangued, and those who haven't don't understand how valuable they can be (particularly with editor-level integration). The wierd thing with discussions like these is how mistaken people are about just how common various sorts of bugs are. People remember the complicated race conditions and deadlock bugs they fought, but in practice the vast majority of non-business bugs are shallow and local, often little more than single-line typos, and easily detectable by simple pattern matchers or dataflow engines.

One additional thing to say is that with appropriate integration, static analysis can work over a lot more than what we traditionally think of as "source". The inspections in IDEA cover not just Java, but XML, HTML, CSS, and property files. There is also a commercial extension to IDEA, Inspection-JS that provides inspections over JavaScript. Every file in your project should have an extra pair of eyes looking it over.

Custom bug detector I wrote for FindBugs last week

[wpugh]

As an example of turning bug instances into bug patterns, I always read through the list of bugs fixed in each version of the jdk1.6.0 builds. In build 89, a bug was fixed in the serialization of ArrayBlockingQueue.

I wrote a FindBugs bug detector to look for similar cases: a class with transient fields, but no readObject or readResolve method to restore the field. I had to tune the detector a bit (for example, raise the priority if it is set to a non-default value in the constructor). I'm still doing some tuning, but at the moment the new detector reports warnings in 47 jdk 1.6 b89 classes, 18 of which are confirmed to be bugs. This took me a total of 5 hours of work.

Bugs listed below (these have been reported to Sun); this detector isn't in the current 1.0 release of FindBugs, but is available is the latest CVS snapshot, and will be in the next release.

  Bill Pugh

-----

java.security.Timestamp and java.security.CodeSigner:
        they have a transient myhash field used to cache the hashCode that is
        initialized to -1. If you serialize/deserialize one of these
        and invoke hashCode on the result, you'll get an incorrect hashCode of 0.

javax.management.AttributeList
        has a transient boolean field tainted. If you add something other than an Attribute
        to an AttributeList, serialize/deserialize it, and then invoke asList(), you get back
        a List that contains something that isn't an Attribute. If you call asList() on
          the original AttributeList, you get an exception.

javax.management.relation.RoleList
javax.management.relation.RoleUnresolvedList
        problems isomorphic to the above problem

sun.util.BuddhistCalendar
        has a transient field yearOffset that is initialized in the constructor. If you
        serialize/deserialize a BuddhistCalendar, you get back a broken BuddhistCalendar
        that computes dates incorrectly (off by 543 years)

javax.swing.DefaultDesktopManager
        has a transient field floatingItems that is initialized to an empty array of Rectangles, and
        it sure looks like the code is assuming that floatingItems is assumed to be nonnull, so
        if you serialize/deserialize it, it will be broken (of course, I can never be sure if
        anybody seriously intends for awt/swing objects to be serialized.

com.sun.rowset.CachedRowSetImpl
com.sun.rowset.FilteredRowSetImpl
com.sun.rowset.JdbcRowSetImpl
com.sun.rowset.JoinRowSetImpl
com.sun.rowset.WebRowSetImpl
com.sun.rowset.internal.CachedRowSetReader
com.sun.rowset.internal.CachedRowSetWriter
com.sun.rowset.internal.InsertRow
com.sun.rowset.internal.SyncResolverImpl
com.sun.rowset.internal.WebRowSetXmlReader
com.sun.rowset.internal.WebRowSetXmlWriter
com.sun.rowset.providers.RIOptimisticProvider
        all initialize in their constructors transient fields pointing to resource bundles
                for providing localized error messages, and the resource bundle will be null if the
        an object is deserialized and serialized.

javax.smartcardio.CommandAPDU
        has 3 transient fields (nc, ne and dataOffset) that are computed by the call to parse in the constructor
        from the apdu array. However, if the object is serialized/deserialized, the fields will have their
        default values.

server side

[jessicalandy]

This would be a nice server side. Wouldn't it be wonderful to have something server side that would check new configurations in cases like new wrodpress setups, or other software. It would be nice to have something test lamp, database queries made in intial set up. Would be great to be able to test different versions of software along with current databse and server configurations. Might save some stupid hard to figure out errors that are easily seeable from a little java type script like this one.

Re:Custom bug detector I wrote for FindBugs last w

[Dave Griffith]

Nice one! I'll be adding it to IntelliJ IDEA on the train to work this morning.