Инструмент анализа изменений кода Java — например, сообщите мне, изменилась ли сигнатура метода, реализация метода

Существует ли инструмент diff специально для Java, который не просто выделяет различия в файле, но является более сложным?

Под более сложным я подразумеваю, что он потребует 2 входных файла, один и тот же файл класса разных версий и скажет мне такие вещи, как:

  • Имена полей изменены
  • Добавлены новые методы
  • Удаленные методы
  • Методы, сигнатуры которых изменились
  • Методы, реализации которых изменились (не интересуются более подробной информацией)

Погуглил и ничего подобного не нашел... Я полагаю, что это может быть полезно для определения того, потребуют ли изменения зависимостей перестроения конкретного модуля.

заранее спасибо

Изменить:

Я полагаю, я должен уточнить:

Я не беспокоюсь о графическом интерфейсе для этого инструмента, я заинтересован в том, чтобы его вызывать программно.

А что касается моих рассуждений:

  • Чтобы потренироваться, если мне нужно пересобрать определенные модули/компоненты, если их зависимости изменились (что может сэкономить нам около 1 часа на компонент)... Более подробное объяснение, но я не считаю это важным.
  • Чтобы их можно было использовать для анализа изменений, внесенных в определенные компоненты, которые мы пытаемся заблокировать и на которые мы полагаемся как на более стабильные, мы пытаемся обеспечить, чтобы сигнатуры методов в конкретном компоненте изменялись очень редко.

person Ed .    schedule 26.07.2012    source источник
comment
Это легко сделать с помощью системы контроля версий, такой как Subversion или Git. Я не понимаю, как и почему вы хотите передать эту информацию в Maven. Почему бы вам просто не хотеть восстанавливать каждый раз?   -  person duffymo    schedule 26.07.2012
comment
Да, поэтому я знаю, что есть инструменты для сравнения текста, которые я мог бы использовать, но меня больше интересует библиотека, которая сообщает о перечисленных выше различиях, которые затем можно вызвать, чтобы выяснить, что нужно построить. Что касается того, почему я хочу это знать, объяснение моих рассуждений займет некоторое время, и я надеюсь, что это не повлияет на ответы. Спасибо.   -  person Ed .    schedule 26.07.2012
comment
Не знаю ни одного. До сих пор не вижу веских причин для этого. Отказ от автоматизированной сборки на несколько секунд показался бы мне пустой тратой времени.   -  person duffymo    schedule 26.07.2012
comment
stackoverflow.com/questions/1664823/   -  person Walter Laan    schedule 26.07.2012
comment
Это то, что я ищу! Спасибо, если вы хотите опубликовать ответ, я соглашусь.   -  person Ed .    schedule 26.07.2012
comment
@ Эд. Неудивительно, что все такие инструменты были заброшены ›5 лет назад. Вы должны делать это с тестовыми примерами и не полагаться на какие-то волшебные инструменты, которые должны что-то выяснить. Например, изменение реализации почти невозможно обнаружить. Тело метода могло остаться без изменений, но, скажем, была обновлена ​​версия сторонней библиотеки, что могло привести к сбоям в работе метода. Итак, просто напишите тестовые примеры.   -  person kan    schedule 26.07.2012
comment
@kan Да, справедливое замечание - я думаю, изменения в реализации были немного амбициозными!   -  person Ed .    schedule 26.07.2012


Ответы (1)


Вы сказали выше, что Clirr — это то, что вам нужно.

Но для тех, у кого немного другие потребности, я бы рекомендовал JDiff. У обоих есть плюсы и минусы, но для своих нужд я остановился на JDiff. Я не думаю, что это удовлетворит ваш последний пункт, и его сложно вызвать программно. Что он делает, так это генерирует полезный отчет о различиях API.

person Daniel Kaplan    schedule 19.12.2012