# Ваш Java анализатор сырой: подождем пару лет

Совсем недавно мы выпустили PVS\-Studio 7\.00, ключевым нововведением которого стал Java анализатор\. Выпуск оказался удачным, так как перед ним была большая волна бета\-тестирования\. Некоторые наши клиенты, кто пользуется C\+\+ или C\# анализаторами, стали внедрять проверку Java кода чуть ли не с бета\-стадии себе в проекты\. Присылали нам интересные ошибки, которые находились у них в коде, как это часто бывает при первых запусках\. Просили доработать те или иные интеграции\. Но некоторые потенциальные пользователи писали следующие вещи: "Ваш анализатор наверняка будет хорош\. Через пару лет\. Когда вы его отладите\. А пока мы не будем качать и смотреть"\. Для меня это звучит столь странно и иррационально, что я решил написать этот пост, а в будущем просто отвечать ссылкой\.

![0609_Use_Java_ru/image1.png](https://import.viva64.com/docx/blog/0609_Use_Java_ru/image1.png)

Итак, на первый взгляд, мысль подождать пару лет, пока продукт встанет на ноги, кажется логичной\. Неужели мне настолько хочется денег, что я даже придумаю статью\-опровержение? :\-\)\. Деньги здесь ни при чем\. Мне слегка обидно, что наш продукт PVS\-Studio используется как повод что\-то НЕ делать\. 

Но начнем по порядку\. Любой анализатор кода включает в себя два важных компонента\. 

Первый – непосредственно технологии анализа кода\. Сюда относится [Data Flow Analysis](https://pvs-studio.ru/ru/blog/terms/7004/), Symbolic Execution, Type Inference и другие\. Подробнее о технологиях анализа кода, которые используются в PVS\-Studio, можно прочитать [здесь](https://pvs-studio.ru/ru/blog/posts/cpp/0466/)\. Почему я даю ссылку на нашу статью двухгодичной давности, когда еще про Java анализатор ничего не было решено? Да потому, что, во\-первых, эти технологии не зависят от целевого языка\. А, во\-вторых, наш анализатор Java использует код из C\+\+ анализатора, с помощью которого и реализованы эти технологии\.

Второй – это инфраструктурные инструменты\. Какими бы чудесными ни были технологии анализа кода, без вспомогательных компонентов инструмент оказывается бестолковым\. Отчет нужно сохранить в удобном виде \(не говоря уж про удобный формат\), рассылать коллегам по ночам\. При внедрении анализатора в существующий проект что\-то надо делать со старыми срабатываниями\. Наконец, способы встраивания в процесс разработки тоже могут быть разными\. Так вот за более чем 10 лет мы научились понимать вопросы инфраструктуры при анализе кода очень хорошо\. И нам не надо тратить время на дополнительные исследования здесь\.

К чему я это все написал? Если вы хотите еще пару лет ничего не менять в своем процессе разработки и не использовать статический анализ \(неважно, наш или не наш\), то, конечно, вы можете утешать себя мыслью, что "продукт сырой"\. Но к реальности это не имеет никакого отношения\. 

Просто [скачайте](https://pvs-studio.ru/ru/pvs-studio/download/) PVS\-Studio и найдите ошибки в своем проекте\. Ведь даже время, потраченное на триал, окупится многократно\.