Skip to main content

javac: new feature ==> add more synchronization/deadlock checks

14 replies [Last post]
amitkulz
Offline
Joined: 2005-09-22

is it possible to add synchronization/deadlock checks in the compiler itself? Sort of like findbugs and lint4j does...

Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
peterahe
Offline
Joined: 2004-11-22

I don't think javac can compete with the best
lint tools out there and I don't think it should.

We will continuously add more and more lint checks,
but for the really fancy once like deadlock detection
and null pointer checks, I think it should be done
by compiler plug-ins. Apt in Tiger allows you to write
compiler plug-ins. They are called annotation
processors. In Mustang, these features will be
extended as we change how you spell "apt".

In the future, I see pluggable types as the right
tool for the job:
http://blogs.sun.com/roller/page/gbracha?entry=a_few_ideas_on_type

amitkulz
Offline
Joined: 2005-09-22

First off, thanks to coxcu and peterahe for your response(s)...Peter,I skimmed over Gilad Bracha's pdfs.

A side note, being out of touch with Java (and programming for that matter) since January 2002 till mid-2005, what books would you folks recommend to get to speed so I can understand things which Gilad talks about?

Will the Eclipse/NetBeans folks independently write these compiler plugins?

amit

jwenting
Offline
Joined: 2003-12-02

The compiler can't know in which scenarios you're going to use your class, and therefore can't be expected to guarantee thread safety.
Thread safety isn't a code syntax or grammar issue anyway and therefore not the compiler's responsibility (just as it's not up to the compiler to guarantee you can never get an NPE when calling a method with a null argument).

Indeed put down the debugger and learn to design your software with thread safety in mind.

coxcu
Offline
Joined: 2003-06-11

jwenting,

Since I submitted this RFE, we obviously differ.

Add Nice Option types to Java to prevent NullPointerExceptions
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5030232

Still, if standardized annotations could be developed, then it would be easier to read and honor the threading constraints of classes. This is true for both programmers and tools.

The compiler isn't the right tool for checking and propagating threading constraints, but I welcome the help that tools could give me. I'm not qualified to create these standard annotations, but I bet there is someone on the JSR 250 EG that is.

- Curt

amitkulz
Offline
Joined: 2005-09-22

roscopeco/jwenting,



Have you checked findbugs/lint4j? It gives you possible places where it thinks you maybe causing unintended deadlocks.



How does designing a class correctly interfere with actual code? Design is one thing, and implementation of that design is another. We do not function at 100% all the time. Like coxcu says for NPE, language support is critical for certain features. If you run findbugs/lint4j on your own projects, I bet you a dollar, you will find many bugs. I read a story someplace which stated that Joshua Bloch who published the Effective Java book found some bugs in his code (related to the same things he was telling us to avoid) after running some such tool.



Why did they add Generics if not to avoid programmer mistakes due to incorrect casting.



coxcu,
My question is if both findbugs/lint4j can spot possible problems in threading/sync why can't this work be shifted into the mainstream compiler, and force everybody to really look over that part of the code? I would think they should also allow some sort of annotation to suppress false positives.

coxcu
Offline
Joined: 2003-06-11

[i]"if both findbugs/lint4j can spot possible problems in threading/sync why can't this work be shifted into the mainstream compiler, and force everybody to really look over that part of the code"[/i]

I'm not sure what you mean. If you are suggesting that the checks would get greater scrutiny as part of javac than as part of another tool, I doubt it. I bet the average programmer is more likely to wade through the FindBugs source than through the javac source. There are also modularity arguments to be made here.

If you are suggesting that people would be more likely to pay attention to warnings issued from javac, I disagree there, too. Eclipse has a very useful set of warnings, even without the FindBugs plugin. I usually turn those up to 11, but I'm sure the default represent the preferences of more typical users.

I totally agree that annotation to supress false positives is crucial for such tools.

amitkulz
Offline
Joined: 2005-09-22

I was referring to the second paragraph in your reply i.e. "people would be more likely to pay attention to warnings issued from javac"

The defaults are what is used by most people, but if I run into trouble, I would switch on the strict checks of javac, and try to look over places where my threads are messing up.

There is no lint like tool provided by Sun AFAIK. I maybe wrong, if I am, please let me know which tool is appropriate.

In the next 5 years the industry is moving to threads, I don't have a clue how to debug using threads. Help me and others like me out there.

Thanks

coxcu
Offline
Joined: 2003-06-11

See javac -Xlint options.
http://java.sun.com/j2se/1.5.0/docs/tooldocs/#basic

That would probably qualify as a lint-like tool.

As time progresses, applications [b]will[/b] become increasingly multi-threaded. As time progresses, developers will also spend more time with IDEs and less time with command-line tools. That's why I think the warnings issued by IDEs are more important.

amitkulz
Offline
Joined: 2005-09-22

Ok I stand corrected..

Now if anybody goes to the javac page

http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/javac.html

You will see a -Xlint:fallthrough, this is pretty trivial (this is sloppy code) but was added to avoid programmer mistakes.

My argument is that a similar [b]-Xlint:checkthreads[/b] be added to javac.

How will the IDE's report warnings if there are no thread checks done by the underlying compiler in the first place? I am using NetBeans 5.0 beta right now, and have set the compiler to be JDK b52 of Mustang.

coxcu
Offline
Joined: 2003-06-11

[i]"How will the IDE's report warnings if there are no thread checks done by the underlying compiler in the first place?"[/i]

If the thread checks are done by another (as in not javac) tool, then that tool should have an API, too. Apt seems like an obvious candidate for checking threading information encoded via annotation.

apt
http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html

I'm sceptical of the possibility of detecting threading bugs by just examining unannotated source or object code. There are some bugs that could be caught that way, but a far larger class of bugs could be detected with more information about intent.

amitkulz
Offline
Joined: 2005-09-22

I agree that not all such thread checks will be caught at compile time, but the remaining should be caught at runtime. I suspect that the VM has some of these checks right now.

Findbugs/lint4j has some of these checks built-in, I think that is why (do they actually catch them at runtime and report at compile time?) they prefer to work on .class files. Shouldn't these checks be shifted to javac, to get more exposure?

jwenting
Offline
Joined: 2003-12-02

Hardly. You'd have to have the compiler run the class through every conceivable scenario it could be used in.

Specialised tools can be used to do checks on a specific use of a class, a compiler would have to guarantee the class was safe for any use at all times.

amitkulz
Offline
Joined: 2005-09-22

Not every person is likely to make use of findbugs or lint4j when the dual/quad cores etc come along in the next few years. I agree that the compiler should also enable correct use of a class at [b]all[/b] times. So If javac doesn't support these checks how will it enforce this contract?

We will need help in debugging multi-threaded programs, and not through a debugger. I just spent a week tracking down a couple of simple problems at work, when it becomes multi-threaded I will be spending more and more time. Time spent debugging by the average programmer should be reduced.

roscopeco
Offline
Joined: 2005-05-08

Put down that damn debugger, get a decent book, and remember the old saying about bad workmen...

;)