Корректность верности в Java с помощью аннотаций?

Существует ли существующая библиотека, которая позволяет мне аннотировать метод Java как @Const, так что компилятор (используя apt я предположим) будет отмечать ошибку, если он обновляет поле или вызывает метод non @Const на поле; и аннотировать параметр как @Const, так что метод accepting не может вызывать какой-либо из своих методов не @Const или обновлять любое из его полей?

(В принципе, попытка добавить const-correctness к Java с помощью аннотаций, есть некоторые очевидные детали, которые не рассматриваются в вышеприведенном вопросе, такие как назначение/из параметра @Const-typed и т.д.)

Я нашел это: http://confluence.atlassian.com/pages/viewpage.action?pageId=182158080, но похоже, что он доступен только как часть IDEA.

Следуя просьбе разъяснения ниже, здесь пример кода, чтобы показать, что я имею в виду:

class Person {
  private String name;
  private String address;

  @Const public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  ... etc. for address
}

Теперь, если я определяю метод, например:

void processPerson(@Const Person p)

строка, такая как: p.getName() будет ОК в processPerson, так как getName был помечен как метод @Const. Но вызов p.setName() из processPerson будет помечен как ошибка.

Обратите внимание, что это сильно отличается от final: если параметр был определен как final Person p, любое присвоение p было бы незаконным, но оно все еще отлично подходит для изменения того, к которому относится p (либо используя p.setName(...) или даже более прямо, с p.name = ....

Ответ 1

JSR-305 якобы делает именно то, что вы ищете
Лично я посмотрю, могу ли я использовать Hibernate Validator - Bean Validation (JSR-303) для этого. Это замечательная маленькая библиотека (не зависит от спящего режима, она небольшая), и она творит чудеса, чтобы ваши данные были чистыми. См. Документацию .
Недавно google guy также начал "Контракты для Java" , но это может быть еще не качество производства.

Ответ 2

Взгляните на Checker Framework, в которой в основном есть шашки, которые пытаются обнаружить дефекты программного обеспечения [JSR-305] с помощью расширяемого типа аннотационной системы [JSR-308].

У него есть средство проверки неизменяемости (фактически 2), которое позволяет вам комментировать код с аннотациями неизменности, такими как @Mutable, @Immutable и @Readonly. Этот инструмент отличает неизменяемый экземпляр от ссылки только для чтения.

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

аннотировать параметр как @Const, так что метод accepting не может вызывать любой из своих методов не @Const или обновлять любое из его полей?

Будет выглядеть так:

void addFriend(@ReadOnly Friend friend) { this.friends.add(friend); }

позволяет мне аннотировать метод Java как @Const, так что компилятор (используя apt я предположим) будет отмечать ошибку, если он обновляет поле или вызывает метод non @Const в поле; и

Это было бы похоже на пример в вопросе:

public String getName(@ReadOnly Person this) {
  return name;
}

Здесь @ReadOnly указывает, что приемник (экземпляр this, метод которого вызывается) НЕ должен быть изменен. Несмотря на кажущийся дополнительный параметр, метод по-прежнему называется как обычно:

@ReadOnly Person person = new Person();
person.getName();

Ответ 3

Я обожаю комментарий @AlexR, это можно сделать с помощью AspectJ, что-то вроде этих строк:

public aspect ConstAspect{
declare warning : withincode(* *(..,@Const (*),.. ) ) : "Calling Const Method..";
}

Это неверно для ваших требований, но я в основном хочу показать подход. В приведенном выше случае любой метод, который имеет @Const по параметру, помечен предупреждением. С лучшей точкой соединения все проблемы, вызывающие озабоченность, могут быть отмечены ошибкой.

Ответ 4

const был в С++. Очевидно, что Java явно бросила его нарочно. И теперь люди, растущие без особого опыта, думают, что это хорошая идея.

Как только вы отметили один метод как const, он распространится, как рак, довольно скоро вы окажетесь const почти все. Было бы лучше иметь not-const.

Совершенно бесполезно. Он только привлекателен академически, никому не помогает в реальной программе.