Если вам действительно «нужно проанализировать исходный код», то библиотеки, позволяющие проверять байт-код, не подходят.
В противном случае вам действительно нужно точно определить свою задачу. Либо вы собираетесь анализировать классы, независимо от того, будете ли вы смотреть на их исходный код или байтовый код, либо вы хотите проанализировать исходный код и подумать о том, чтобы сделать это, сначала скомпилировав, а затем проанализировав скомпилированный результат. В последнем случае вам нужно сравнить усилия на обоих этапах с альтернативным решением, которое может, например, включать прямой анализ исходного кода.
Анализировать байт-код довольно просто, проще, чем анализировать исходный код, поэтому байт-код создается до выполнения программ Java. Чтобы ответить на ваш конкретный вопрос, да, все три библиотеки предлагают вам способ анализа инструкций и связанной с ними информации. Какой из них лучше всего соответствует вашим потребностям, это вопрос, который выходит за рамки Stackoverflow.
Помогает ли анализ байтового кода, зависит от ваших конкретных требований. Когда дело доходит до доступа к полям и методам, вы можете получить большинство из них, используя этот подход. Только встроенные константы времени компиляции не имеют происхождения. Когда дело доходит до использования типа, вы должны учитывать, что не каждый артефакт исходного кода имеет существующий аналог в байтовом коде, например расширяющиеся приведения не производят фактического кода, а локальные переменные обычно не имеют объявленного типа (не считая отладочной информации), а только подразумеваемого типа, который зависит от того, как они фактически используются. У них также нет информации о Generics, если не включена отладочная информация.
person
Holger
schedule
16.09.2015