Я работаю над библиотекой, где мы хотим определить, какая часть нашей библиотеки используется. И.Е. мы хотим знать, сколько методов в нашей библиотеке является общедоступным, но никогда не вызывается.Java Code Use Checker
Цель: Статический анализ Определите, сколько строк кода вызывает каждый открытый метод в пакете A в текущем проекте. Если количество вызовов равно нулю, метод следует указывать как таковой.
Я верю, вы ищете это затмение плагин ->UCDetector
Из документации (оплата уведомления до второй маркированной точки)
на большие масштабы, если вы хотите сделать объект уровня статического анализа, см на этом инструменте от IBM ->Structural Analysis for Java. Это действительно полезно для объектного анализа библиотек, API и т. Д.
Вот несколько списков инструментов покрытия кода Java. Я не использовал любой из них лично, но он может получить начала:
Проблема с инструментами покрытия кода заключается в том, что они работают во время выполнения, так что вы можете пропустить «редкие» коды кода. – Thilo
Не совсем то, что вы ищете, но:
что-то подобное выполняются с помощью инструментов покрытия кода (например, Cobertura). Они не выполняют статический контроль исходного кода, но прибегают к байт-коду для сбора показателей во время выполнения. Конечно, вам нужно управлять приложением таким образом, чтобы он выполнял все шаблоны использования и мог пропустить более редкие коды кода.
На статическом фронте анализа, может быть, эти инструменты могут помочь вам (проект Apache использует их для проверки совместимости API для новых выпусков, кажется, что задача несколько связанных с тем, что вы пытаетесь сделать):
Я не думаю, что вы можете измерить, как «часто» необходим класс или функция.
Есть несколько простых вопросов:
Заключение:
Я не знаю, что вы пытаетесь достичь.
Если вы хотите отобразить свои зависимостей в коде, то для этого вам нужны другие tools. Если вы пытаетесь измерить выполнение кода, для Java есть profiler or benchmarks. Если вы статистический выродка, вы будете довольны RapidMiner;)
Удачи вам в этом!
Я бы предложил JDepend показать вам зависимости между пакетами и классами, отличные для поиска циклических зависимостей! http://clarkware.com/software/JDepend.html (он имеет затмение плагин: http://andrei.gmxhome.de/jdepend4eclipse/
, а также PMD для других метрик http://pmd.sourceforge.net/
Клиентское использование рефлексивных вызовов является одним из отверстий в статическом анализе для рассмотрения. Поскольку нет никакого способа точно знать, что конкретный метод не вызывается через какую-то причудливую схему отражения. Таким образом, может быть, комбинация времени выполнения и статического анализа может быть лучше.
Proguard может быть вариант тоже (http://proguard.sourceforge.net/):
«Некоторые виды использования ProGuard являются:
Смотрите также http://proguard.sourceforge.net/manual/examples.html#deadcode
Вы можете написать свои собственные утилиты для этого (в пределах часа после прочтения этого), используя библиотеку анализа ASM байткода (http://asm.ow2.org). Вам нужно будет реализовать ClassVisitor и MethodVisitor. Вы будете использовать ClassReader для анализа файлов классов в вашей библиотеке.
Поддержание карты для подсчета. Ключи представляют методы (см. Ниже). Вот несколько кодов:
class MyClassVisitor {
// ...
public void visit(int version, int access, String name, ...) {
this.className = name;
}
public MethodVisitor visitMethod(int access, String name, String desc, ...):
String key = className + "." + name + "#" + desc;
if (!map.containsKey() {
map.put(key, 0);
}
return new MyMethodVisitor(map);
}
// ...
}
void class MyMethodVisitor {
// ...
public visitMethodInsn(int opcode, String name, String owner, String desc, ...) {
String key = owner + "." + name + "#" + desc;
if (!map.containsKey() {
map.put(key, 0);
}
map.put(key, map.get(key) + 1);
}
// ...
}
В принципе, это все. Ваша работа начинается с чего-то типа:
Map<String,Integer> map = new HashMap<String,Integer>();
for (File classFile : my library) {
InputStream input = new FileInputStream(classFile);
new ClassReader(input).accept(new MyClassVisitor(map), 0);
input.close();
}
for (Map.Entry<String,Integer> entry : map.entrySet()) {
if (entry.getValue() == 0) {
System.out.println("Unused method: " + entry.getKey());
}
}
Наслаждайтесь!
Если метод A вызывает метод B, метод B будет отмечен как «использованный», даже если метод A не используется, поэтому это не совсем правильный способ подсчета. Вам нужно сделать переходное закрытие на «использованном». –
У IntelliJ есть инструмент для обнаружения методов, полей, классов, которые могут иметь более ограниченные модификаторы.Это также имеет быстрое исправление, чтобы применить эти изменения, которые могут сэкономить вам много работы. Если вы не хотите платить за это, вы можете получить 30-дневную лицензию eval, которая более чем достаточно времени для изменения вашего кода, а не то, что вам нужно делать очень часто.
BTW: IntelliJ имеет около 650 проверок кода для улучшения качества кода, около половины имеет автоматические исправления, поэтому я предлагаю потратить пару дней, используя его, чтобы реорганизовать/убрать код.
Пожалуйста, взгляните на Dead Code Detector. Он утверждает, что делает именно то, что вы ищете: поиск неиспользуемого кода с использованием статического анализа.
Похоже, вы хотите что-то вроде Cobertura или Emma, которое контролирует ваше приложение, а не полагается на набор тестовых покрытий? –