Это большой взлом, но это функциональный обходной путь:
Вызовите точку останова местоположения 'триггера' 1 и точку останова местоположения цели 2. Мы хотим, чтобы точка останова 2 срабатывала, если и только если выполнение прошло точку останова 1.
Установить условные контрольные точки на каждом.
Для точки останова 1 установите условие как System.setProperty("breaknow", "breaknow") == "". Это условие никогда не будет выполнено, но установит системное свойство, которое мы можем прочитать в точке останова 2.
Для точки останова 2 установите условие как System.clearProperty("breaknow") != null. Это условие будет срабатывать при установке системного свойства, а также сбрасывать его (чтобы мы могли повторить при необходимости).
Как я уже сказал, это взлом, но, похоже, работает. Я отправил запрос на улучшение Eclipse для реализации связывания или объединения точек останова в качестве встроенной функции (https://bugs.eclipse.org/bugs/show_bug.cgi?id=390590). К сожалению, у меня нет пропускной способности для ее реализации, но, возможно, когда-нибудь мы получим поддержку более чистого решения.
Одно предупреждение (которое применяется ко всем условным точкам останова, а не только к этой уловке). Из моего опыта выясняется, что установка условной точки останова не позволяет JIT компилировать интересующий метод, вместо этого запускать его в интерпретируемом режиме. Или, возможно, он разрешает первый этап C1 JIT, но не позволяет оптимизировать компилятор второго уровня C2?
В любом случае вы должны знать, что отлаживаемый метод будет работать значительно медленнее с условной точкой останова. Обычно это не проблема, но при отладке очень узких внутренних циклов я обнаружил, что лучше вернуться к (небрежному) методу if (x) { // Do somthing useless and set a breakpoint here}.