Comments on: A use case for Java 7 http://blog.objectteams.org/2011/06/a-use-case-for-java-7/ Everthing Object Teams - adding team spirit to your objects. Fri, 18 May 2012 09:16:44 +0000 http://wordpress.org/?v=2.5.1 By: Help the JDT Compiler helping you! - 1: Resource Leaks at The Object Teams Blog http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-33072 Help the JDT Compiler helping you! - 1: Resource Leaks at The Object Teams Blog Thu, 26 Jan 2012 14:32:26 +0000 http://blog.objectteams.org/?p=111#comment-33072 [...] the JDT team was finishing up work on the new try-with-resources statement introduced in Java 7. So I was thinking: shouldn’t the compiler help users to migrate from notoriously brittle handling of resources [...] [...] the JDT team was finishing up work on the new try-with-resources statement introduced in Java 7. So I was thinking: shouldn’t the compiler help users to migrate from notoriously brittle handling of resources [...]

]]> By: stephan http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17990 stephan Tue, 14 Jun 2011 22:51:05 +0000 http://blog.objectteams.org/?p=111#comment-17990 "Best thing to do is contact the main developer on FindBugs and start a dialog there." I tried to contact William Pugh regarding null annotations, but never got an answer. Others have reported the similarly. "I would love to see more complete static code anlaysis in eclipse" I'm trying to help here and there. Do you have any particular checks in mind? The big rule for JDT is, however, all analyses must be fast and general. "and in particular known issues turned on by default." I agree. “Best thing to do is contact the main developer on FindBugs and start a dialog there.”

I tried to contact William Pugh regarding null annotations, but never got an answer. Others have reported the similarly.

“I would love to see more complete static code anlaysis in eclipse”

I’m trying to help here and there. Do you have any particular checks in mind? The big rule for JDT is, however, all analyses must be fast and general.

“and in particular known issues turned on by default.”

I agree.

]]> By: stephan http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17988 stephan Tue, 14 Jun 2011 22:42:31 +0000 http://blog.objectteams.org/?p=111#comment-17988 Coming back to the original topic of my post: I think try-with-resources is actually a useful addition to the language, because it helps you to be more explicit by saying: "this block is responsible for the given resources". This helps connecting intent with enforcement, so we can write better code right away. And the occasion has shown the relevance of this particular kind of problem. In this context analysis tools can help us stay on track, no more, no less. Coming back to the original topic of my post: I think try-with-resources is actually a useful addition to the language, because it helps you to be more explicit by saying: “this block is responsible for the given resources”. This helps connecting intent with enforcement, so we can write better code right away. And the occasion has shown the relevance of this particular kind of problem.

In this context analysis tools can help us stay on track, no more, no less.

]]> By: David Carver http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17986 David Carver Tue, 14 Jun 2011 22:26:00 +0000 http://blog.objectteams.org/?p=111#comment-17986 Best thing to do is contact the main developer on FindBugs and start a dialog there. I know he's run his tools against the eclipse code base. Also there is a FindBugs plugin that you can use to run it locally within eclipse, so you can do some comparisons that way. I would love to see more complete static code anlaysis in eclipse, and in particular known issues turned on by default. Best thing to do is contact the main developer on FindBugs and start a dialog there. I know he’s run his tools against the eclipse code base. Also there is a FindBugs plugin that you can use to run it locally within eclipse, so you can do some comparisons that way.

I would love to see more complete static code anlaysis in eclipse, and in particular known issues turned on by default.

]]> By: stephan http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17985 stephan Tue, 14 Jun 2011 22:15:25 +0000 http://blog.objectteams.org/?p=111#comment-17985 Stating that "every case it has detected for my use cases has been exactly correct" doesn't really say much about completeness :) OTOH I know that tools specialized just in static analysis can of course detect more problems than a compiler. I was just curious to learn *how* much deeper they look. E.g., what if a reference to an InputStream is passed around from one method to another? Normally it would take s.t. like annotations to express which method is responsible. In the academic world people talk of ownership models for expressing things like that. Stating that “every case it has detected for my use cases has been exactly correct” doesn’t really say much about completeness :)

OTOH I know that tools specialized just in static analysis can of course detect more problems than a compiler.

I was just curious to learn *how* much deeper they look. E.g., what if a reference to an InputStream is passed around from one method to another? Normally it would take s.t. like annotations to express which method is responsible. In the academic world people talk of ownership models for expressing things like that.

]]> By: David Carver http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17981 David Carver Tue, 14 Jun 2011 21:57:13 +0000 http://blog.objectteams.org/?p=111#comment-17981 It's pretty complete in detecting the cases. It is a byte code interpreter, but so far every case it has detected for my use cases has been exactly correct. Compared to what FindBugs and PMD detect, the JDT compiler is way behind. It’s pretty complete in detecting the cases. It is a byte code interpreter, but so far every case it has detected for my use cases has been exactly correct.

Compared to what FindBugs and PMD detect, the JDT compiler is way behind.

]]> By: stephan http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17967 stephan Tue, 14 Jun 2011 18:12:55 +0000 http://blog.objectteams.org/?p=111#comment-17967 @David: You might have noticed: the JDT compiler, too, is a static code analysis tool :), just developed with more emphasis on performance ("performed on each keystroke") than on completeness of analyses. That said: can you report how complete FindBugs is wrt detecting not-closed streams? What if the reference to the stream is shared by many, as sp8472 mentioned? My motivation for pushing some of these things into the JDT compiler is twofold: (1) for more immediate feedback, always, without the need to install additional tooling. (2) for optimal integration with quickfixes. This holds for un-closed resources, null-related problems, unused objects and things like that. @David: You might have noticed: the JDT compiler, too, is a static code analysis tool :), just developed with more emphasis on performance (”performed on each keystroke”) than on completeness of analyses.

That said: can you report how complete FindBugs is wrt detecting not-closed streams? What if the reference to the stream is shared by many, as sp8472 mentioned?

My motivation for pushing some of these things into the JDT compiler is twofold: (1) for more immediate feedback, always, without the need to install additional tooling. (2) for optimal integration with quickfixes. This holds for un-closed resources, null-related problems, unused objects and things like that.

]]> By: David Carver http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17966 David Carver Tue, 14 Jun 2011 17:47:56 +0000 http://blog.objectteams.org/?p=111#comment-17966 You should also consider running static code anlysis tools like FindBugs. It'll catch the situations where you are not closing your streams. You should also consider running static code anlysis tools like FindBugs. It’ll catch the situations where you are not closing your streams.

]]> By: stephan http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17964 stephan Tue, 14 Jun 2011 17:27:48 +0000 http://blog.objectteams.org/?p=111#comment-17964 @sp8472: First, yes, the ability to use @SuppressWarnings is precondition to making this RFE useful in practise. But each time you use @SuppressWarnings it should make you think: I'm leaving the grounds where the compiler can help me. Perhaps I should restructure my code? If a reference is handed around to too many folks it's just as in real life: all responsibility will just diffuse, everybody will expect "someone else" will take care. In this regard too much freedom will get us nowhere. So the new construct should actually push you towards a design where for each resource indeed one method is in charge (if this is not already the case). In the RFE I already elaborated a bit on how the analysis could detect, which method this is supposed to be. makes sense? @sp8472: First, yes, the ability to use @SuppressWarnings is precondition to making this RFE useful in practise.

But each time you use @SuppressWarnings it should make you think: I’m leaving the grounds where the compiler can help me. Perhaps I should restructure my code?

If a reference is handed around to too many folks it’s just as in real life: all responsibility will just diffuse, everybody will expect “someone else” will take care. In this regard too much freedom will get us nowhere.

So the new construct should actually push you towards a design where for each resource indeed one method is in charge (if this is not already the case). In the RFE I already elaborated a bit on how the analysis could detect, which method this is supposed to be.

makes sense?

]]> By: sp8472 http://blog.objectteams.org/2011/06/a-use-case-for-java-7/#comment-17961 sp8472 Tue, 14 Jun 2011 17:05:25 +0000 http://blog.objectteams.org/?p=111#comment-17961 And what if you're reading only part of the output stream, and other clients will read the remainder? Then someone else has the responsibility of closing it... So perhaps this would need a @SuppressWarnings for such cases? Of course, once you add one of those, then it can no longer detect that you actually close it in another client... And what if you’re reading only part of the output stream, and other clients will read the remainder? Then someone else has the responsibility of closing it… So perhaps this would need a @SuppressWarnings for such cases? Of course, once you add one of those, then it can no longer detect that you actually close it in another client…

]]>