Редактировать : Билет, который я связал в этом ответе был помечен как проверенный / исправленный. Он был интегрирован в последнюю версию Oxygen, , как описано в примечаниях к выпуску . Ниже я оставлю свой первоначальный ответ, поскольку в нем содержится много полезной информации о том, как JDI и JDT работают вместе в Eclipse.
Я собираюсь начать с окончательного ответа на ваш вопрос, чтобы вам не приходилось читать подробности, если вы этого не хотите. В принципе, это возможно, но с большим количеством вопросов, на которые нужно ответить в первую очередь. Если вы хотите пропустить это и перейти прямо к билету, здесь вы идете , но я рекомендую вам продолжить.
Eclipse использует JDI (в самом низу этой страницы) для регистрации точек наблюдения в JVM. Это делается с помощью методов EventRequestManager (реализация обеспечивается самой JVM, а не Eclipse), которые создают точки наблюдения, то есть EventRequstManager.createModificationWatchpointRequest. Единственное, что принимают эти методы, это Field (обратите внимание, что это не класс Field). Короче говоря, Eclipse не может сделать это напрямую через Java. Не бойтесь, Java также не обрабатывает условные точки останова. Они также реализуются через Eclipse напрямую, вместо того, чтобы полагаться на Java. Однако есть некоторые предупреждения, которые делают условные контрольные точки гораздо более сложными для реализации, чем условные контрольные точки.
Давайте рассмотрим простые, условные точки останова. Чтобы они работали, вам нужен контекст, в котором вы можете выполнить фрагмент кода. Без контекста выполнения для кода мы не сможем оценить выражение / операторы во фрагменте, так как у нас нет способа разрешения переменных, значений, типов и т. Д. Это делается с помощью анализатора AST , который обрабатывает код Java в реальных инструкциях. Помните, что в условие можно ввести несколько операторов, а не одно выражение. Затем оценщик использует контекст (в частности, IJavaStackFrame) для оценки самого выражения после его синтаксического анализа.
Теперь подумайте об условной точке наблюдения, потому что эта последняя точка очень важна. Что такое контекст выполнения точки наблюдения? Доступ к переменным может происходить не только в пределах одного и того же класса, но и в других классах (например, protected и членах пакета), а также во внутренних классах (через MyClass.this.myField). Это означает, что:
- локальные переменные никогда не бывают согласованными, поскольку доступ к полю можно получить несколькими способами,
- переменные-члены класса, из которого вызывается доступ, никогда не являются непротиворечивыми, поскольку к полю можно получить доступ из нескольких классов,
- импортированные классы, доступные в контексте выполнения, никогда не согласуются по той же причине, что и (2), и
- доступ к самому полю никогда не бывает согласованным, поскольку для этого может потребоваться квалификация с экземпляром, именем класса,
super или с чем-то вроде MyClass.this.myField (для доступа к внутреннему классу).
Возможность реализации такой функции ограничена. Вам было бы трудно реально оценить неизменяемый условный оператор для точки наблюдения, поскольку абсолютно ничего в контексте выполнения не будет согласованным. Это означает, что код не может быть легко проанализирован и интерпретирован без специального значения, примененного к частям кода, например:
myField всегда совпадает с this.myField или super.myField или MyClass.myField или MyClass.this.myField, в зависимости от того, где осуществляется доступ к полю.
Это немного усложняет ситуацию, особенно в системе, которая уже является относительно сложной. Пример кода условной точки останова можно найти здесь (поиск по getEvaluationEngine с помощью Ctrl + F). Теперь возьмите это и добавьте предварительную обработку выражения, основанного на наборе правил о том, где мы находимся и где находится поле, и выполнение каких-либо действий может стать сложным.
AFAIK, вы не можете сделать что-то вроде: «если старое / новое значение - это, приостановить», потому что эта информация просто недоступна из информации, которую вы можете получить в кадре стека (и, следовательно, из отладчика ). Выражение, присваиваемое значению, было оценено по времени попадания в точку наблюдения, но его результат недоступен отладчику, поэтому он не доступен для оценщика на самой точке наблюдения. Сначала должен быть выполнен шаг для выполнения присваивания, затем выражение должно быть оценено после шага. Это было бы ужасно грязно и, честно говоря, довольно глупо.
В любом случае, если вы хотите заявить о своей поддержке этой функции, вы можете использовать этот билет Eclipse . Тем не менее, он существует с 2005 года (8 лет на данный момент) и имеет ограниченную поддержку со стороны сообщества. ТБХ, я не вижу, чтобы это зашло слишком далеко, особенно без дополнительного разъяснения ожиданий, связанных с такого рода запросом функции, и без каких-либо серьезных конструктивных соображений, поставленных вначале.