#java #annotations #nullable #eclipse-jdt #type-mismatch
#java #аннотации #обнуляемый #eclipse-jdt #несоответствие типов
Вопрос:
Пытаюсь понять, почему служебный класс, единственной целью которого является перенос null, ожидает @NonNullable
аргумент. Приведенный ниже пример приводит к неожиданным (для меня) ошибкам несоответствия нулевого типа в Eclipse.
Несоответствие нулевого типа (аннотации типа): требуется ‘@NonNull IoSession’, но это выражение имеет тип ‘@Nullable IoSession’
Я бы не написал код таким образом, но я застрял между стандартами кодирования стороннего разработчика, в которые я пытаюсь внести свой вклад, и реалиями сторонней библиотеки, интерфейс которой я пытаюсь реализовать, поэтому я застрял, пытаясь сделать всех счастливыми, при этом заставляя все работать.
Учитывая конкретную сигнатуру метода обратного вызова, каков наилучший способ корректной обработки реализации при создании наименьшего количества предупреждений компилятора (перед применением подавления). Перед попыткой java.util.Optional
я просто выполнял простые проверки null, но, как вы знаете, компилятор по-прежнему предупреждает о
Потенциальный доступ к нулевому указателю: это выражение имеет тип ‘@Nullable’
несмотря на нулевую проверку … другим сторонним стандартом кодирования является отсутствие ошибок или предупреждений компилятора при использовании минимально возможного подавления для достижения этой цели.
import static java.util.Optional.ofNullable;
import java.util.Optional;
import org.apache.mina.core.buffer.IoBuffer;
import org.apache.mina.core.session.IoSession;
import org.apache.mina.filter.codec.CumulativeProtocolDecoder;
import org.apache.mina.filter.codec.ProtocolDecoderOutput;
import org.eclipse.jdt.annotation.NonNullByDefau<
import org.eclipse.jdt.annotation.Nullable;
@NonNullByDefault // @NonNullByDefault required and enforced by frameworks coding standards (3rd party)
public class MyClass extends CumulativeProtocolDecoder {
@Override // implementation of 4th party callback, necessitating @Nullable annotation
protected boolean doDecode(@Nullable IoSession s, @Nullable IoBuffer i, @Nullable ProtocolDecoderOutput o) {
Optional<IoSession> session = Optional.ofNullable(s); // Null type mismatch (type annotations): required '@NonNull IoSession' but this expression has type '@Nullable IoSession'
Optional<IoBuffer> in = Optional.ofNullable(i); // Null type mismatch (type annotations): required '@NonNull IoBuffer' but this expression has type '@Nullable IoBuffer'
Optional<ProtocolDecoderOutput> out = ofNullable(o); // Null type mismatch (type annotations): required '@NonNull ProtocolDecoderOutput' but this expression has type '@Nullable ProtocolDecoderOutput'
return true;
}
}
Комментарии:
1. Я не понимаю предупреждений. В Java нет аннотаций
Optional
2. Таким образом
@NonNullByDefualt
, аннотация к классу должна приводить к наследованию аргументов без аннотаций@NonNullable
по умолчанию. Похоже, что существуют две разные парадигмы обработки нулевых значений, которые не идеально сочетаются друг с другом.3. Да, я так думаю. Государства javadoc, применяющие эту аннотацию к объявлению, приводят к тому, что ссылки на типы, которые содержатся в объявлении и для которых в противном случае отсутствует нулевая аннотация, должны рассматриваться как @NonNull .
4. Я боялся, что могу задать немного политический вопрос. Я думаю, что в этом случае я собираюсь отказаться от стандартов кодирования сторонних разработчиков, поскольку я предоставляю конкретную реализацию для интерфейса стороннего разработчика, и не имеет смысла разрешать стороннему пользователю диктовать аннотации в этом контексте, поскольку конечный результат в конечном итоге оказывается противоположным предыдущемунамерение. Это пакеты OSGI, и то, что у меня здесь, больше похоже на проблемы с контрактом, где несоответствия типов являются лишь симптомом этого запаха.