Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Finding Bugs Is Easy

timothy posted more than 11 years ago | from the roll-the-log-over dept.

Bug 66

daveho writes "My advisor and I are working on a tool to automatically find bugs in Java programs. One of the interesting results of our work is that we've found hundreds of real bugs in production code using extremely simple techniques. We believe that automated tools, if used more widely, could prevent a lot of bugs from making it in to production systems."

cancel ×

66 comments

Sorry! There are no comments related to the filter you selected.

So (1)

lh0628 (517993) | more than 11 years ago | (#5827086)

Just out of curiosity, what did you use when debugging this program?

Prebugging (1)

yerricde (125198) | more than 11 years ago | (#5832061)

what did you use when debugging this program?

The most productive debugging happens in the design phase. Keeping each independent module small, simple, and focused, makes it harder to make a mistake.

Looks really kewl. (4, Interesting)

DeadSea (69598) | more than 11 years ago | (#5827175)

I just downloaded this and started playing around with it on my Java utilities [ostermiller.org] .

At first I was frustrated that it needs a jar file. On my hard drive my code is just sitting in directories. So I made a jar file out of my code just for this program.

Then I was frustrated that the GUI wouldn't show me the source, but then I realized that I had compiled without debugging information in my classes (no line numbers and such). I recompiled and remade the jar file and it started showing me the source.

Most of the errors that it finds in my stuff aren't really errors. I get a lot of complaint about "should be declared package" when package is the default and I don't specify a modifier. I also get errors about ignored exceptions for things like this:
} catch (IOException x){
// This can't happen.
// The input and output streams were constructed
// on memory structures that don't actually use IO.
}

I think it may have found a few bugs though. Its complaining about at least one thing not being threadsafe. Also complaining about an inner class being static when it probably shouldn't be.

Now I want an Ant task for this so that I can make sure it runs on my code every time I compile. It is sort of like extended compiler warnings. Pretty helpful.

Re:Looks really kewl. (2, Informative)

addaon (41825) | more than 11 years ago | (#5827363)

Why don't you just write the exception

} catch(IOException x) {
assert(false);
}

I'm sure that would make the error go away.

Re:Looks really kewl. (2, Insightful)

DeadSea (69598) | more than 11 years ago | (#5828166)

That would do it. How about this one?

Uninitialized read of labels in constructor:
if (labels == null){
// setlocale inits labels
setLocale(Locale.getDefault());
}

Its complaining because I'm comparing it to null? I think its a bug in the analysis.

Of course, it would be nice if there were a document that would tell you how to manipulate your code to hide things that you have determined not to be errors from the analyzer. Maybe a list of errors that you have already looked at. Possibly comments you can put in your code.

Re:Looks really kewl. (2, Informative)

splattertrousers (35245) | more than 11 years ago | (#5828906)

True, it might be a bug in the analysis, but checking for nulls is not a great practice. Try using the "null object" pattern. Mark Grand describes [mindspring.com] it thusly:

The Null Object pattern provides an alternative to using null to indicate the absence of an object to delegate an operation to. Using null to indicate the absence of such an object requires a test for null before each call to the other object's methods. Instead of using null, the Null Object pattern uses a reference to an object that doesn't do anything.

The null instance of whatever class your labels variable is could do the locale stuff. (Or maybe it wouldn't work in your case; it's hard to say without the context.)

Re:Looks really kewl. (1)

joto (134244) | more than 11 years ago | (#5829987)

If it's in a constructor, both you and the compiler should know equally well whether it's initialized. Of course, this being java, it's always initialized to null (unless you've already initialized it to something else of course), so the test is kind of pointless when compared to a C/C++-checker, but being null might still be an error if you didn't intend it, and if you want it to be null, you can initialize it explicitly.

The fix is of course to remove the check. Then you don't read uninitialized memory. Why would you want the check in a constructor anyway?

Re:Looks really kewl. (1)

DeadSea (69598) | more than 11 years ago | (#5830306)

Its a static variable. It may have been initialized by a previous instance, it may not have been.

Re:Looks really kewl. (1)

joto (134244) | more than 11 years ago | (#5832214)

Ahh, then I guess I would fill in a bugreport, maybe... :-)

Re:Looks really kewl. (1)

Randolpho (628485) | more than 11 years ago | (#5831629)

Just a guess, but is it complaining because of a lack of guaranteed initialization?

Even though Java is *supposed* to initialize to null, there is no real guarantee that this will actually happen. Without explicit initialization to null, some JVM could just give you whatver data was in some register, which is more than likely *not* null. It's good that it's complaining, if that's the complaint.

Initial values of variables (3, Informative)

fforw (116415) | more than 11 years ago | (#5832485)

Even though Java is *supposed* to initialize to null, there is no real guarantee that this will actually happen.

wrong. The JavaTM Virtual Machine Specification - Second Edition [sun.com] says the following :

2.5.1 Initial Values of Variables

Every variable in a program must have a value before it is used:

  • Each class variable, instance variable, and array component is initialized with a default value when it is created:
  • For type byte, the default value is zero, that is, the value of (byte)0.
  • For type short, the default value is zero, that is, the value of (short)0.
  • For type int, the default value is zero, that is, 0.
  • For type long, the default value is zero, that is, 0L.
  • For type float, the default value is positive zero, that is, 0.0f.
  • For type double, the default value is positive zero, that is, 0.0.
  • For type char, the default value is the null character, that is, '\u0000'.
  • For type boolean, the default value is false.
  • For all reference types (2.4.6), the default value is null (2.3).
  • Each method parameter (2.5) is initialized to the corresponding argument value provided by the invoker of the method.
  • Each constructor parameter (2.5) is initialized to the corresponding argument value provided by an object creation expression or explicit constructor invocation.
  • An exception-handler parameter (2.16.2) is initialized to the thrown object representing the exception (2.16.3).
  • A local variable must be explicitly given a value, by either initialization or assignment, before it is used.

Re:Initial values of variables (1)

jrumney (197329) | more than 11 years ago | (#5838627)

In reality, not every JVM follows that part of the spec. I have come across at least one that didn't, and IIRC it was even one of Sun's ones.

Re:Initial values of variables (1)

fforw (116415) | more than 11 years ago | (#5841315)

In reality, not every JVM follows that part of the spec. I have come across at least one that didn't, and IIRC it was even one of Sun's ones.

well.. As the VM spec says otherwise, it's a bug. Elevating that bug to an exception/restriction makes no sense.

(Are you sure the variable was not initialized? or was it some Serialization-effect?)

Re:Initial values of variables (1)

jrumney (197329) | more than 11 years ago | (#5842476)

There was no serialization involved, these were static members.

Though it may be a JVM bug, I need my code to work, so working around it does make sense.

Re:Initial values of variables (1)

fforw (116415) | more than 11 years ago | (#5848786)

Though it may be a JVM bug, I need my code to work, so working around it does make sense.

keeping your code work makes sense.
saying java variables aren't initialized not.

Re:Initial values of variables (1)

jrumney (197329) | more than 11 years ago | (#5851599)

Maybe one day you'll graduate from University and discover the real world, where if an implementation of the JVM does not initialise variables properly, then java variables cannot be relied on to be initialised.

Re:Looks really kewl. (1)

CognitivelyDistorted (669160) | more than 11 years ago | (#5869840)

The paper explains the rationale for each check. For "read of uninitialized field in constructor", the idea is that since the field has the default value, it makes no sense to read it, so the code is at best useless. In another post I think you said it was a static field, so it looks like you've discovered a bug in FindBugs.

Re:Looks really kewl. (1)

splattertrousers (35245) | more than 11 years ago | (#5828858)

} catch (IOException x){
// This can't happen.
// The input and output streams were constructed
// on memory structures that don't actually use IO.
}

If it really can't happen, why not this:

} catch (IOException canNotHappen) {
throw new RuntimeException( "Exception that cannot happen actually did happen" + canNotHappen );
}

That way, if it really does happen, you'll find out about it.

Re:Looks really kewl. (1)

LadyLucky (546115) | more than 11 years ago | (#5841009)

That's what I do, except use an InternalError instead. Then you *really* get to know about it ;-)

I've never understood why if you have an exception that cannot happen anyone would ever want to ignore if it did. It makes no sense! You would want to know if it happened in the noisiest, loudest way! Some plonker will come along and change your code and the exception will then be able to occur.

Re:Looks really kewl. (1)

CharlieG (34950) | more than 11 years ago | (#5830215)

Even though package is the default, declare it anyway - Good practice.

Other rules of thumb for any programming language

Use the strictest compiler setting you can, and clean up any errors it finds

Don't do automatic type casting - heck, things like variants and auto type casting is what helped give VB a bad name in some circles - folks were screaming for strict casting back in VB4, and finally started to get in in VB.NET

I'd like to read more... (1)

RevRagnarok (583910) | more than 11 years ago | (#5827187)

  • From page:
  • Presentation slides from Finding Bugs is Easy, invited talk, MASPLAS 2003
I get error 403 - permission error. I'll look at the other PDF later tonite I hope.
  • - RR

Bugs in Java code? Inconceivable! (3, Funny)

wowbagger (69688) | more than 11 years ago | (#5827243)

Bugs in Java code? Inconceivable!

I thought it was impossible to write bugs in Java - nature's most perfect language! After all, all the Java bigo^H^H^H^Hzealot^H^H^H^H^H^Hexperts have always said that all software problems would vanish if we would just use their perfect language.

(/me removes tongue from cheek)

I just hope that the myriad and varied Java bigots out there will take this to heed: No language can prevent you from making mistakes.

(NOTE: I most emphatically do NOT assert that a language cannot make certain classes of errors more difficult to make!)

(NOTE 2: I also do not assert that all people who use Java, or promote the use of Java are bigots.)

There is no substitute for experience, careful design, and methodical testing.

Re:Bugs in Java code? Inconceivable! (1)

DeadSea (69598) | more than 11 years ago | (#5827331)

Anybody who claims that you can't write a bug in Java has no experience and isn't very creative.

Re:Bugs in Java code? Inconceivable! (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5827806)


/me applies my foot to your ass.

You are gay^H^H^H a raging faggot.

(NOTE: Welcome to my foes list.)

Re:Bugs in Java code? Inconceivable! (1)

pmz (462998) | more than 11 years ago | (#5827859)

Bugs in Java code?

Yup. While bounded arrays help remove certain classes of bugs, for example, the "null pointer exception" stepped in exactly where "segmentation fault" left.

The complexity of programming has been pretty constant since FORTRAN was adopted over assembler. "Object-oriented" removed some complexity but added its own, so the net gain is small. Maybe "aspects" will finally save us...maybe not.

Re:Bugs in Java code? Inconceivable! (1)

drgnvale (525787) | more than 11 years ago | (#5836049)

>>The complexity of programming has been pretty constant since FORTRAN was adopted over assembler

I don't know... my programs have gotten much simpler since I started programming in Scheme. Except for having to write a lot of my own data structures. But thats no worse than C.

Re:Bugs in Java code? Inconceivable! (1)

John Miles (108215) | more than 11 years ago | (#5851040)

The complexity of programming has been pretty constant since FORTRAN was adopted over assembler.

Man, there is no way I'd buy that. Ever see a copy of K&R sitting next to Stroustrup on the shelf?

Re: Inconceivable! (1)

leonbrooks (8043) | more than 11 years ago | (#5829701)

Bugs in Java code? Inconceivable!

Now, the Java inventors were Sicilians; and everybody knows that you can't trust Sicilians... so you can't take the language that's before them! But... they would have expected you to know that, so you clearly can't take the language that's in front of you...

"You think that's good? Wait 'till I get going!" (-:

Re:Bugs in Java code? Inconceivable! (1)

stj (607714) | more than 11 years ago | (#5831855)


No language can prevent you from making mistakes.
Assuming that it even existed, you can always make something that realizes a totally different task from the intended - that might be actually beneficial - I could use a teleporter for example. >:->

Damn straight it's easy to find bugs... (0, Flamebait)

JimDabell (42870) | more than 11 years ago | (#5827267)

...you can even order some over the internet! [microsoft.com]

Okay low blow, but joking aside, what's newsworthy about this? Is there something that sets it apart from run-of-the-mill linters?

semantic heuristic checks? (0)

Anonymous Coward | more than 11 years ago | (#5827312)

it seems to me that some bugs will be nearly impossible to find unless you use a debugger (or, heaven help you, printf()). you can make all your heuristics for checking code, but ultimately that race condition or off-by-one error or other crazy obscure corner case that appears once in a billion iterations won't be found by a glorified lint.

speaking of lint, how is this new or better than pc-lint [keil.com] , advertised in dr. dobbs every issue for at least the past six years? i mean, other than the fact this new tool does java.

someone enlighten me!

Reading UGH (4, Interesting)

Henry V .009 (518000) | more than 11 years ago | (#5827387)

I'm reading the UNIX haters guide that got posted recently, and I just wanted to post this:
There are two schools of debugging thought. One is the "debugger as physician" school, which was popularized in early ITS and Lisp systems. In these environments, the debugger is always present in the running program and when the program crashes, the debugger/physician can diagnose the problem and make the program well again.


Unix follows the older "debugging as autopsy" model. In Unix, a broken program dies, leaving a core file, that is like a dead body in more ways than one. A Unix debugger then comes along and determines the cause of death. Interestingly enough, Unix programs tend to die from curable diseases, accidents, and negligence, just as people do.

Re:Reading UGH (2, Insightful)

Anonymous Coward | more than 11 years ago | (#5827995)

Your comment didn't make any sence to me until I reallized you are talking about C not UNIX.

in favor of autopsy (1)

michaelggreer (612022) | more than 11 years ago | (#5828203)

Bugs that crash a program are relatively easy to find. If, instead, the program continues in a non-determined fashion, the bug turns into a subtle one. Subtle bugs are nastier, hence the emphasis on autopsy. Users prefer crashing bugs too: I would rather my web-browser crash outright than submit something random to my bank.

Re:in favor of autopsy (1)

tungsten alloy (664361) | more than 11 years ago | (#5830053)

Really? Why is it not the bank's responsibility to make sure it's getting valid input and not "something random"? If I attempt to transfer a random string of text from one account to another, I don't suppose it's very likely to be all numbers and to also be a valid amount. If my bank is that stupid, I'll find another bank.

Re:in favor of autopsy (1)

rabidcow (209019) | more than 11 years ago | (#5831857)

Forget the bank analogy then. It's still true.

Would you rather have your text editor hit a bug and write random garbage over your term paper, or would you rather it just crash?

Re:in favor of autopsy (1)

tungsten alloy (664361) | more than 11 years ago | (#5840414)

I'll take closing and re-opening a file over having to restart the application. I'm just lazy that way.

Re:in favor of autopsy (1)

rabidcow (209019) | more than 11 years ago | (#5841156)

I'll take closing and re-opening a file over having to restart the application.

Huh? What makes you think that's an option, and how would it make any sense?

It writes corrupted data. You are not aware of this. You close the file. You open it again, maybe a few days later. You find out your hard work is hopelessly lost.

vs.

It crashes. You are immediately aware of this. You reopen the app and the file. Maybe you've lost back to the last time you saved, at most.

Re:in favor of autopsy (0)

Anonymous Coward | more than 11 years ago | (#5841277)

Text editor? I think they've got all the bugs out of cat anyway.

Bank analogy not flawed (2, Insightful)

CompVisGuy (587118) | more than 11 years ago | (#5837804)

Imagine that your de-stabilised browser submits a 'random' but 'valid' (under the rules of the bank's error checking code) -- for example you say 'pay the cable co. $40' but your browser transmits 'pay the cable co. $400'.

I don't know which side of the autopsy/physician debugging argument I'd sit on. I quite like Matlab's approach (which I believe is similar to Lisp's), in that you can choose to enter debug mode when an error occurs, and you can then interactively probe you code to find out why it ended up in that state. This is particularly useful when you have (as I do) numerically-intensive code that might take several days to complete running -- you don't want to get to 3.9 days into a 4 day job and find out there was a bug in the very last command your code was to run without being able to figure out exactly why the error occurred -- the write-run-debug cycle would be very long indeed!

So, I can see the benefits of both approaches. I guess having a choice is important, and knowing when to opt for which flavour of error handling.

...and? (1)

dacarr (562277) | more than 11 years ago | (#5827401)

Many languages have tools such as this. Lint comes to mind, and GCC tells you where it gags if it can't compile a piece of code for some reason.

Re:...and? (4, Informative)

michaelggreer (612022) | more than 11 years ago | (#5827586)

Javac and Jikes will tell you where it can't compile. This is higher level stuff like "such-and-such should be final" and "you have implemented equals but not hashcode." Code will run, and probably run fine, with these, but they may lead to subtle bugs difficult to track down. Compile-time or formatting bugs are easy to find. Bugs that express themselves in non-obvious ways are what we need more tools for.

In answer to another post, of course good design and good coding are best. This tool does not seek to replace thought, but push us towards proper coding

The obvious solution... (3, Funny)

Lendrick (314723) | more than 11 years ago | (#5827405)

Please note that FindBugs is alpha-quality software. You may find bugs in it, and the features and source code may change significantly in future releases.

...is to run it on itself.

FindBugs? (3, Funny)

Copperhead (187748) | more than 11 years ago | (#5827649)

What kind of name is "FindBugs"? What self-respecting Open Source project would ever name itself after what it actually does? That's so wrong!

They need to pick a name like "||gazm", "JizMop", or "Mozilla" like all the other cool OS projects. I'm sure they'll learn their lesson soon.

Re:FindBugs? (3, Funny)

pmz (462998) | more than 11 years ago | (#5827934)

"||gazm"

What a perfect name for a logic-based language or boolean calculator!

Re:FindBugs? (2, Funny)

Ratbert42 (452340) | more than 11 years ago | (#5828224)

Go with the crowd and just name it Firebird.

The Author really wanted to name it Firebird..... (1)

whazzy (620752) | more than 11 years ago | (#5838806)

but I heard that an AOL backed organization is already pursuing the name.(I am really,really new here!)

History, repeat thyself. (2, Insightful)

pmz (462998) | more than 11 years ago | (#5827661)

Why not call it "Lint"?

Automated tools like lint are an invaluable part of any software project and should be used at various points in a project's lifecycle. However, the bugs they find tend to be shallow (typecast problems, immediate memory violations, etc.). This is a certain improvement in software quality, but even Java programs can have side-effects from class to class that twist the mind of even the best programmer.

"Finding bugs is easy" makes sense in the context of my backyard but definitely not in programming.

Re:History, repeat thyself. (2, Insightful)

crisco (4669) | more than 11 years ago | (#5830666)

Speaking of, wasn't there some research posted to /. a few months back that indicated logic errors on the part of the programmer often occured around the smaller errors that programs like this one and lint often catch?

Been there, done that (4, Informative)

Tal Cohen (4834) | more than 11 years ago | (#5828647)

While working in IBM Research, we were developing a tool to do just that; I do believe it was significantly richer than this one. The first versions were aimed specifically at J2EE, and searched for really 'high-level' bugs -- anything from bad patterns to violations of the J2EE spec. The initial results of this effort are already included in WebSphere Studio Application Developer 5.0, as part of the Verifiers. More powerful versions will appear in future releases of WSAD.

Re:Been there, done that (2, Informative)

YetAnotherAnonymousC (594097) | more than 11 years ago | (#5829046)

IIRC, Oracle also has a tool like this. I think it is called "Code Coach"

Jlint (4, Interesting)

mmynsted (552933) | more than 11 years ago | (#5828680)

OK.

Why not contribute to the existing, GPL, OpenSource, Java Lint? Why start a new project?

http://artho.com/jlint/

--MM

Re:Jlint (1)

psychofox (92356) | more than 11 years ago | (#5838813)

Perhaps because jLint is written in C++, not Java.

Re:Jlint (1)

CognitivelyDistorted (669160) | more than 11 years ago | (#5869891)

Because it's research. Researchers need to be able to implement exactly the features they want to study, not what the developers and user base of an OSS project want. It's about the ideas, not the code. But I'm sure the authors would be pleased if JLint used their ideas.

bah. (0)

Anonymous Coward | more than 11 years ago | (#5828847)

Port it to C, find hundreds of bugs in the linux kernel, fix them. Then we'll talk.

The real value (2, Interesting)

Dr. Bent (533421) | more than 11 years ago | (#5829666)

The real value of tools like this is that they act as a sort of Instant Code Review. Just as you can use unit tests to quickly verify the (partial) correctness of your system, you can use tools like this to quickly find bad code so that it can be corrected before it causes more problems. Obviously, just like unit tests are not a complete replacement for QA, this is not a complete replacement for code reviews, but every little but helps.

And although it would be useful everywhere, I would think that a tool like this would fit nicely into an extreme programming shop, where the developers are already used to using automated tools on thier code.

Re:The real value (1)

joto (134244) | more than 11 years ago | (#5830146)

I would say that the real value of tools like this is that they teach you a lot about regexps and scripting. Because that's what you have to do to run them on a large project.

You have to have scripts that deduct from coding style the author of each part of the project, and then invokes the code-checking tool with the right options to catch the types of errors that particular programmer is likely to make, but not giving 1999 false positives for each real error.

Ok, I'm playing the devils advocate here, but I can't say I have found much value in using e.g. flexelint on a large project where most code isn't written by myself. Sure, it finds errors, but the time I'm looking at false positives could just as well have been spent testing or debugging, or refactoring, or redisigning, or...

Sure, I still do some static testing, but to be really useful, it needs to be done from the start. Putting it in your build system is not such a bad idea, at least if your project doesn't already take a day to compile...

Re:The real value (2, Informative)

Dr. Bent (533421) | more than 11 years ago | (#5830459)

You obviously have not used _this_ tool on anything.

I was easily able to it up and running to test a 1000 class project that I've been working on for about two years now. It took all of 5 minutes from the time I read the article on slashdot to the point where I was fixing bugs that I had missed in two years of constant debugging, testing and refactoring. No scripts, no regular expressions, just point at the .jar and go.

Now, granted, they were some fairly simplistic bugs, and it's questionable whether or not they would have ever floated to the surface as an actual bug report. But they would still be in the code now if it wasn't for this tool.

Re:The real value (1)

joto (134244) | more than 11 years ago | (#5832218)

Thanks for the recommendation!

Something else worth a look (2)

JediTrainer (314273) | more than 11 years ago | (#5831393)

Another great tool that deserves a look (besides those already mentioned) is PMD [sourceforge.net] . I use PMD at work to find all sorts of cruft that can be cleaned out of older Java sources. It can be run inside your favourite IDE (to highlight the offending lines) or as an ANT task (generating a report in XML or HTML). Generally I've found it to be a great help, and the coders have been very responsive to my (many) feature suggestions and bug tickets. Most of the things it's found have been general cleanups (ie unused variables or imports), but it also helped find a number of bugs in our code too.

Eclipse IDE (1)

jtheory (626492) | more than 11 years ago | (#5831540)

Eclipse [eclipse.org] (also free and currently my IDE of choice) has more and more of these kinds of features built-in with each release.

It's still mostly cleanup stuff, but it looks like they're moving towards having more of this stuff included by default. Currently you can set the error level (ignore, warning, error) when you do a build for unused imports/parameters/classes/methods/fields, circular dependancies, unreachable code, methods with constructor names, overridden methods that aren't package visible, hidden catch blocks, non-static access to static variables, using a char array in String concatenation, etc..

Checks on general threading practices and lock sequences would be cool... that seems to be a dangerous area for new Java programmers. Ever seen a servlet with doGet() and doPost() synchronized? No, it didn't scale very well.

Suggestions to daveho (2, Funny)

jtheory (626492) | more than 11 years ago | (#5831688)

I know it's expanding quickly, but the main thing the FindBugs homepage is missing is a list of the errors that FindBugs identifies.

I got a few hints from the screenshots and changelist... but I need more!

* infrastructure for doing dataflow analysis
* tracking of locks for inconsistent synchronization detector
* a few general cleanup fixes in the screenshot

The first 2 especially sound interesting... but not quite enough for me to download a 0.5 version release and slog through the source code.

Halting (2, Insightful)

Jason1729 (561790) | more than 11 years ago | (#5831824)

How did you solve the halting problem? Or does it not check for potential infinite loops?

Jason
ProfQuotes [profquotes.com]

Re:Halting (1)

yerricde (125198) | more than 11 years ago | (#5832095)

How did you solve the halting problem?

Some cases of the halting problem are straightforward to accept or reject.

Re:Halting (2, Insightful)

blancolioni (147353) | more than 11 years ago | (#5833550)

Checking for infinite loops is not some magical process that brings Turing's ghost down to blow your computer up. All the halting problem shows is that it's impossible to do in general. The specific is a different matter.

Your statement is unnecessarily negative, unhelpful, and a bit silly.

PMD (1)

insac (623145) | more than 11 years ago | (#5835554)

"...However, many of the
detectors we have implemented, such as inconsistent
synchronization and mutable static fields, are not
present in PMD. Like our tool, PMD uses Visitors
to implement its pattern detectors. One nice
feature of PMD is that patterns may be implemented
as XPath expressions, so that new checks can be
added without the need to write a new Visitor
class...."

I'm wondering if they mean that their "detectors" (inconsistent synchronization and mutable static fields) can't be written in PMD XPath...

Otherwise I don't see it as a PMD problem.. they could easyly contribute two new PMD rules and everyone could use them..

Let's hope they (or the PMD devolepers) will soon contribute that.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>