Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
Recently we have released PVS-Studio 7.00, the key innovation of which was the Java analyzer. The release has proved to be successful, as a big wave of beta-testing had come before that. Some of our clients who are using C++ or C# analyzers started to implement a check of Java code in their projects almost from the beta-stage. They were sending us interesting errors, which have been found in their code, as it usually happens during the first launches. There were also requests to finalize some integrations. However, some potential users were writing the following things: "Your analyzer will certainly be good. In a couple of years. When you debug it. In the meantime, we will not download and check it out". For me it sounds so strange and irrational that I decided to write this post and answer by giving a link in future.
So, at first glance, the idea to wait for a couple of years, while the product regains its feet, seems logical. Do I want to get money so much that I even make up an article-disclaimer? :-). Money is not the issue here. It's a bit insulting for me that our PVS-Studio product is used as a reason NOT to do something.
Well, let's start from the beginning. Any code analyzer includes two important components.
The first one is directly code analysis technologies. This includes Data Flow Analysis, Symbolic Execution, Type Inference, and others. Here you can read in details about technologies of code analysis, which are used in PVS-Studio. Why I am giving a link to our article posted two years ago, when nothing had been resolved about the Java analyzer? Firstly, because these technologies don't depend on the target language. Secondly, our Java analyzer uses the code from the C++ analyzer, with the help of which these technologies are implemented.
The second component is infrastructural tools. No matter how wonderful the code analysis technologies are, without auxiliary components a tool turns out to be stupid. The report has to be saved in a convenient form (let alone a convenient format), sent to colleagues at nights. When introducing an analyzer into an existing project one has to do something with old warnings. Finally, ways of introducing into the development process can be different. So, for more than 10 years we have learned to understand infrastructural issues related to code analysis very well. That's why we don't need to spend time on more research here.
Why did I write all this? If you'd like to change nothing in your development process for a couple of years and you don't want to use static analysis (no matter ours or not) then, sure, you can comfort yourself thinking that the "product is raw". Nevertheless, it has nothing to do with reality.
So, just download PVS-Studio and find bugs in your project. Even the time spent on trial, will pay off many times.
0
0
0
0