Аннотация:
В данной статье описывается простое решение задачи аннотирования java bytecode для более безопасного его использования (в том числе из компилятора Kotlin). Читатель может познакомится с основами методов абстрактной интерпретации и суперкомпиляции. Плата за простоту метода — экпоненциальная сложность в общем случае. Однако простота метода облегчает его реализацию, тестирование и т.д., и может служить своеобразной точкой отсчета для создания более быстрых, но более сложных его версий.
Здравствуйте, Ключников Илья Григорьевич, Вы писали:
>Другой распространенной и близкой по духу ошибкой было ClassCastException, вызванное отсутствием типовых параметров – эта проблема была решена (по мнению многих, отнюдь не самым элегантным образом) в Java 1.5.
Даже во времена Java 1.4 ClassCastException небыл такой проблемой, как NPE. Помимо решения ошибки приведение генерики ещё и сильно очищают код от шума, потому что типы выносятся из использования в объявление.
Во введении ничего не сказано про Guava/Java 8 Optional.
Стоило так же раскрыть основную проблему анализа NPE, которая заключается в том что источник ошибки (null значения) и исключение находятся, зачастую, совсем не рядом в коде.
"разыменование" какой-то C++ термин для указаний. В Java он что значит?
Что слышно про аналогичные решения? http://aprove.informatik.rwth-aachen.de/eval/JBC-Nonterm/
На сколько практично применение такого инструмента в промышленых проектах?
Здравствуйте, Blazkowicz, Вы писали:
B>"разыменование" какой-то C++ термин для указаний. В Java он что значит?
"Разыменование" — попытка сказать по-русски в одно слово dereference. В Java — доступ к внутреннему содержимому объекта, вызов метода на объекте, чтение и запись полей объекта (Получаем NullPointerException, если соответствующая переменная — null). На фоне терминологии C++ этот термин несколько корявый, но лучшего, по-видимому, нет. Термин dereference в таком смысле используется как раз в статьях про вывод @NotNull/@Nullable и в статьях по анализу кода на Java. Как примеры употребления:
Здравствуйте, lambdamix, Вы писали:
L>"Разыменование" — попытка сказать по-русски в одно слово dereference. В Java — доступ к внутреннему содержимому объекта, вызов метода на объекте, чтение и запись полей объекта (Получаем NullPointerException, если соответствующая переменная — null). На фоне терминологии C++ этот термин несколько корявый, но лучшего, по-видимому, нет. Термин dereference в таком смысле используется как раз в статьях про вывод @NotNull/@Nullable и в статьях по анализу кода на Java. Как примеры употребления: L>
Есть множество инструментов для Java, которые находят ошибки в программах, связанные с использованием null. Конечная цель Kanva-micro, описанного в статье, и автоматического вывода аннотаций в IntelliJ IDEA — та же самая: находить ошибки в коде. Только в этом случае нахождение ошибок разделено на две стадии (застадировано). Вначале выводятся свойства того, как библиотеки, используемые в проекте, работают с null — эти свойства выводятся в форме аннотаций (форма здесь не так важна). А затем эти выведенные свойства используются при проверке кода, который пишет программист (когда он использует методы из библиотек). В IDEA принято, что большинство анализов (code inspections) могут показать ошибку/предупреждение почти моментально (за исключением некоторого количества глобальных анализов по всему проекту) — программист печатает код и сразу же видит ошибки. Отдельное аннотирование библиотек и использование этой информации в редакторе позволяют делать в том числе и inspection того, как программист работает с библиотечными методами на предмет NPE сразу же в редакторе. А dataflow analysis в IDEA очень мощный. Собственно говоря, вывод аннотаций сам по себе не пытается искать никаких ошибок в анализируемом коде, он собирает информацию, которая окажется полезной потом — при анализе (другого!) кода в редакторе.
Все известные мне другие инструменты (находящие NPE) не ориентированы на такой сценарий интеграции с IDE — их основной сценарий: человек нажимает кнопку, ждет (как правило, достаточно долго) и получает какие-то ошибки. Наш же подход — отдельное аннотирование библиотек + отдельный анализ исходников, в которых используются библиотеки — позволяет добиться интерактивности.
А так, да — существуют инструменты, находящие NPE — FindBugs, PMD, Julia Analyzer и т.д. Что-то они делают лучше, что-то хуже) Из тех инструментов, в которых я копался, разбираясь с их внутренним устройством, только FindBugs в некоторой степени выводит в явном виде nulllability параметров для библиотек, но делает он это очень поверхностно.
Здравствуйте, lambdamix, Вы писали:
L>Все известные мне другие инструменты (находящие NPE) не ориентированы на такой сценарий интеграции с IDE — их основной сценарий: человек нажимает кнопку, ждет (как правило, достаточно долго) и получает какие-то ошибки. Наш же подход — отдельное аннотирование библиотек + отдельный анализ исходников, в которых используются библиотеки — позволяет добиться интерактивности.
Правильно ли я понял, что ваш байт-код анализатор ориентирован на 3rd party, в то время как анализатор IDE выводит nullability из исходников проекта? И тем самым они друг-друга дополняют.
Здравствуйте, Blazkowicz, Вы писали:
L>>Все известные мне другие инструменты (находящие NPE) не ориентированы на такой сценарий интеграции с IDE — их основной сценарий: человек нажимает кнопку, ждет (как правило, достаточно долго) и получает какие-то ошибки. Наш же подход — отдельное аннотирование библиотек + отдельный анализ исходников, в которых используются библиотеки — позволяет добиться интерактивности. B>Правильно ли я понял, что ваш байт-код анализатор ориентирован на 3rd party, в то время как анализатор IDE выводит nullability из исходников проекта? И тем самым они друг-друга дополняют.
