Статья:
Adding notnull to the Java Programming Language

Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Авторы:
Dmytro Sheyko

Аннотация:
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Здравствуйте, Аноним, Вы писали:

А>Статья:


А>Авторы:
А>Dmytro Sheyko

А>Аннотация:
А>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


Очень интересная идея. Плохо только, что Sun ее в ближайших версиях компиляторов не реализует (если реализует вообще).

Если по смыслу, то не уверен, что лучше использовать аннотации для объявления notnull. Да, проблема компиляции старых программ, в которых использовалось "notnull" в качестве идентификатора есть, но ,имхо, она не столь уж и значительна. Использование ключевого слова как-то более естественно.

Здравствуйте, Аноним, Вы писали:

Я на Java не пишу,но проблема общая для всех языков, так что статья была всё равно интересна.
Особенно стало интересно как за счёт компилятора решить подобную задачу в другия языках.
А вот почему автор даже не зарегистрировался на сайте не понятно.

Здравствуйте, adontz, Вы писали:

A>Я на Java не пишу,но проблема общая для всех языков, так что статья была всё равно интересна.
A>Особенно стало интересно как за счёт компилятора решить подобную задачу в другия языках.
A>А вот почему автор даже не зарегистрировался на сайте не понятно.


dshe ...

Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:


DS>Авторы:
DS> Dmytro Sheyko

DS>Аннотация:
DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Дмитрий, на мой взгляд можно обойтись без изобретения нового модификатора.
Возможно вы в курсе, но если нет, то советую почитать например книжку Мартина Фоулера (Martin Fowler) Refactoring. Improving the Design of Existing Code. Там в частности расматривается решения проблем с нулевыми указателями (Introducing Null Object и Special case design pattern). На мой взгляд упомянутые там решения изящнее и носят более общий характер. Но тем не менее, мне было интересно прочитать и Вашу статью.

Cпасибо

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Dmytro Sheyko, Вы писали:

DS>>Статья:


DS>>Авторы:
DS>> Dmytro Sheyko

DS>>Аннотация:
DS>>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

А>Дмитрий, на мой взгляд можно обойтись без изобретения нового модификатора.
А>Возможно вы в курсе, но если нет, то советую почитать например книжку Мартина Фоулера (Martin Fowler) Refactoring. Improving the Design of Existing Code. Там в частности расматривается решения проблем с нулевыми указателями (Introducing Null Object и Special case design pattern). На мой взгляд упомянутые там решения изящнее и носят более общий характер. Но тем не менее, мне было интересно прочитать и Вашу статью.

Cпасибо за интерес к статье.

На мой взгляд, паттерны Null Object и Special Case не являются исключающими альтернативами notnull'у. Они (паттерны и notnull) могут прекрасно уживаться вместе. notnull претендует на то, чтобы быть средством дополнительного контроля на этапе компиляции, таким же как и типы. Тогда как Null Object — это способ избежать многократных проверок на null. Конечно, можно принципиально отказаться от использования null литерала в пользу Null Object'ов. Однако, это не всегда возможно и целесообразно.

Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:


DS>Авторы:
DS> Dmytro Sheyko

DS>Аннотация:
DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Кстати, кто-нибудь знает Open Source Java-компилятор, поддерживающий аннотации (и, желательно, генерики)?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Dmytro Sheyko, Вы писали:

DS>>Статья:


DS>>Авторы:
DS>> Dmytro Sheyko

DS>>Аннотация:
DS>>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

А>Дмитрий, на мой взгляд можно обойтись без изобретения нового модификатора.
А>Возможно вы в курсе, но если нет, то советую почитать например книжку Мартина Фоулера (Martin Fowler) Refactoring. Improving the Design of Existing Code. Там в частности расматривается решения проблем с нулевыми указателями (Introducing Null Object и Special case design pattern). На мой взгляд упомянутые там решения изящнее и носят более общий характер. Но тем не менее, мне было интересно прочитать и Вашу статью.

А>Cпасибо

Я б советовал написать мало-мальски серъездный код (большую систему) с использованием этого синтаксиса. Я думаю что в ней будут постоянные приведения к notnull типу.....

Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:


DS>Авторы:
DS> Dmytro Sheyko

DS>Аннотация:
DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


Возможно, я высказываю дилетанскую мысль, но я бы предложил иную концепцию.
ключевое слово nullable для объектных переменых (или как правильнее сказать?),
которым можно присвоить null, Остальные объектные переменные пусть считатся not initialized с соответсвующем сообщением компилятора, если объектной переменной при создании или позже присваиваешь явно null или
когда обычной объектной переменной присваиваешь помеченное nullable (результат nullable-функции, выражения с участием nullable-переменых, итп итд), пишется uncaught NullPointerException. на этапе компиляции.
Мне кажется это проще. Но конечно это должно быть с совместью.Т. е. для классов, помеченых notnull, можно сделать либо Ваш вариант либо то, о чём говорю я. А остальной код пусть работает в "старой" среде умолчаний и "правил игры".
ЗЫ:
Я вообще не люблю null присваивать.
А исключения я обрабатываю try{code}catch(Throwable t){errorprocessing) (в конце (или вместо) списка у меня частенько "Throwable перехватывается". Это хорошо или плохо? (В плане эффективности, устойчивости/стабильности кода ?)

Здравствуйте, Волк-Призрак, Вы писали:

ВП>Возможно, я высказываю дилетанскую мысль, но я бы предложил иную концепцию.
ВП>ключевое слово nullable для объектных переменых (или как правильнее сказать?),
ВП>которым можно присвоить null, Остальные объектные переменные пусть считатся not initialized с соответсвующем сообщением компилятора, если объектной переменной при создании или позже присваиваешь явно null или
ВП> когда обычной объектной переменной присваиваешь помеченное nullable (результат nullable-функции, выражения с участием nullable-переменых, итп итд), пишется uncaught NullPointerException. на этапе компиляции.
ВП>Мне кажется это проще.

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

ВП>Но конечно это должно быть с совместью.Т. е. для классов, помеченых notnull, можно сделать либо Ваш вариант либо то, о чём говорю я. А остальной код пусть работает в "старой" среде умолчаний и "правил игры".

Правильно ли я тонял, что ты предлагаешь классы, в которых предполагается использование данного расширения явно помечать notnull? И в таких классах все ссылочные переменные (аргументы и возвращаемые значения ??) по-умолчанию становятся ненулевыми? Я не думаю, что это хорошо поскольку для того, чтобы понять смысл какого-либо объявления (поля или метода) необходимо будет еще и смотреть, с каким модификатором был объявлен класс. Также простая установка/снятие notnull модификатора с класса будет приводить к радикальному изменению семантики объявлений, содержащихся в классе.

Здравствуйте, dshe, Вы писали:

D>Здравствуйте, Волк-Призрак, Вы писали:


D>Правильно ли я тонял, что ты предлагаешь классы, в которых предполагается использование данного расширения явно помечать notnull? И в таких классах все ссылочные переменные (аргументы и возвращаемые значения ??) по-умолчанию становятся ненулевыми? Я не думаю, что это хорошо поскольку для того, чтобы понять смысл какого-либо объявления (поля или метода) необходимо будет еще и смотреть, с каким модификатором был объявлен класс. Также простая установка/снятие notnull модификатора с класса будет приводить к радикальному изменению семантики объявлений, содержащихся в классе.

За модификаторами будет смотреть синтаксический анализатор и компилятор. А вообще этот notnull в любом виде может стать очередной красной тряпкой, вроде Windows vs Linux, или "софтверным патентам — да!" vs "софтыерным патентам — смерть!".
Документировать такое (использование notnull) надо, разумеется, особенно, "на видном месте.
И такой вопрос при том виде notnull-класса появляется — можно ли ссылочной переменной notnull-класса присвоить null? По логике этого расчирения (notnull classes) — нет. А по логике сериализации — да.
Так что для notnull class должно использоваться ключерое слово default, после которого идёт выражение, возвращающее ссылку того класса, который объявляется.
Например вот так:

public notnull class Person implements Serializable default new Person("","","") {

private String firstname="";
private String middlename="";
private String lastname="";
private nullable WorkPlace thework=null;

public Person(String first,String last, String middle){
//бубубу, ляляя, присвойте имена
thework=Workplace.nojob;//nojob==null, may be.
}

public Person(String first,String last, String middle, Workplace work){
//бубубу, ляляя, присвойте имена
workplace=work;
}

}

Но тогда потребуется ключевое слово ___isdefault;
boolean var1=___isdefault referenceexpression;
Или конструкции типа
boolean var2=reference.equals(default);
Но тогда notnull классы должный всегда сопровождаться default.
Знвчит можно убрать слово notnull из объявления класса а оставить default.
однако тут есть вот какая загвозка.

class Person default new Person()

Person(){
//Инициализация по умолчанию.
}

Person parent;

Person(string name, Person parent)
{};

}

всё, приехали. бесконечный цикл инициализации — parent нельзя присвоить null.
Компилятор нужно "научить" таким ситуациям:
Если в классе с default есть нестатические члены того же типа, что и объявляемый класс,
то выдать ошибку наподобие
"Infinity initialization error: reference variable parent mast be declared as nullable.".

Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:


DS>Авторы:
DS> Dmytro Sheyko

DS>Аннотация:
DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Кстати, вот несколько интересных ссылок по теме:

Declaring and Checking Non-null Types in an Object-Oriented Language

Bug ID 5030232: Add Nice Option types to Java to prevent NullPointerExceptions

Здравствуйте, Волк-Призрак, Вы писали:

ВП>Здравствуйте, dshe, Вы писали:

D>>Здравствуйте, Волк-Призрак, Вы писали:


D>>Правильно ли я тонял, что ты предлагаешь классы, в которых предполагается использование данного расширения явно помечать notnull? И в таких классах все ссылочные переменные (аргументы и возвращаемые значения ??) по-умолчанию становятся ненулевыми? Я не думаю, что это хорошо поскольку для того, чтобы понять смысл какого-либо объявления (поля или метода) необходимо будет еще и смотреть, с каким модификатором был объявлен класс. Также простая установка/снятие notnull модификатора с класса будет приводить к радикальному изменению семантики объявлений, содержащихся в классе.

ВП>За модификаторами будет смотреть синтаксический анализатор и компилятор.

Речь идет не о компиляторе, а о человеке (разработчике). Уточню свою мысль -- я полагаю, что у разработчиков это вызовет ряд неудобств, поскольку такое объявление

    // ...
    public void method(String arg) {
        // ...
    }
    // ...

Имеет разный смысл в зависимости от того, находится ли оно в notnull классе или в классе "старого стиля". Метод либо принимает ненулевой параметр (в notnull классе), либо может принимать null (в классе "старого стиля").

ВП>Например вот так:
ВП>

ВП>public notnull class Person implements Serializable default new Person("","","") {

ВП>private String firstname="";
ВП>private String middlename="";
ВП>private String lastname="";
ВП>private nullable WorkPlace thework=null;

ВП>public Person(String first,String last, String middle){
ВП>//бубубу, ляляя, присвойте имена
ВП>thework=Workplace.nojob;//nojob==null, may be.
ВП>}

ВП>public Person(String first,String last, String middle, Workplace work){
ВП>//бубубу, ляляя, присвойте имена
ВП>workplace=work;
ВП>}

ВП>}
ВП>

Еще раз хочу уточнить смысл выделенной конструкции. Она означает, что перечисленными значениями будет инициализироваться instance переменные до вызова конструктора? Какие выгоды это дает? Не проще ли потребовать инициализировать поля сразу при объявлении? (так, на мой взгляд даже будет наглядее, поскольку в приведенном тобой примере не очевидно, какая из приведенных в default выражении пустых строк какой переменной соответствует). Могут ли быть более сложные выражения, чем строки, в default выражении? (Полагаю, что должны быть, поскольку иначе notnull расширение будет иметь смысл исключительно для класса java.lang.String). А как быть со статическими переменными?

ВП>всё, приехали. бесконечный цикл инициализации — parent нельзя присвоить null.
ВП>Компилятор нужно "научить" таким ситуациям:
ВП>Если в классе с default есть нестатические члены того же типа, что и объявляемый класс,
ВП>то выдать ошибку наподобие
ВП> "Infinity initialization error: reference variable parent mast be declared as nullable.".

Я не вижу особого смысла накладывать подобные ограничения. Что плохого в том, чтобы переменная parent была notnull? Единственное, нужно проверить, чтобы в конструкторе она инициализировалась ненулевым значением (что и делает предложенная мной реализация).

Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:
DS>Adding notnull to the Java Programming Language

Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

DS>Авторы:
DS> Dmytro Sheyko

DS>Аннотация:
DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

А пока в Sun думают...

Здравствуйте, Blazkowicz, Вы писали:

B>А пока в Sun думают...

Я думаю они сделают это, JetBrains сроде как может им советовать. @SuppressWarning же появился.
Вот я думаю появится и @Nullable с @NotNull. По крайней мере я ими уже пользуюсь.

Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:
DS>Adding notnull to the Java Programming Language

Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

DS>Авторы:
DS> Dmytro Sheyko

DS>Аннотация:
DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

В статье часто упоминается слово "контракт", для тех кто не в курсе, рекомендую для общего развития познакомиться с языком Eiffel и техникой Design by Contract.
Здесь можно прочитать про iContract -- реализацию Design by Contract для Java.
Судя по всему, DBC кроме прочих позволяет так же вводить окраничение и на not null.
Например:

/**
 * @inv firstName != null
 * @inv lastName  != null
 */
public class Person {
    private String firstName;
    private String lastName;

    /**
     * @pre firstName != null
     */
    public void setFirstName(String firstName) {
        return this.firstName = firstName;
    }

    /**
     * @post return != null
     */
    public String getFirstName() {
        return firstName;
    }
    // . . .
}

Здесь инвариант класса запрещает нули в переменных firstName и lastName. Предусловие метода setFirstName запрещает передавать ему нуль в параметре, а постусловие метода getFirstName запрещает ему возвращать нуль.
Компилятор анализируя инварианты, предусловия и постусловия мог бы получить столько же информации, сколько из ключевых слов not null или аннотаций @NotNull. Кроме того, DBC позволяет намного больше, чем просто not null.

Здравствуйте, caustic, Вы писали:

C>Компилятор анализируя инварианты, предусловия и постусловия мог бы получить столько же информации, сколько из ключевых слов not null или аннотаций @NotNull. Кроме того, DBC позволяет намного больше, чем просто not null.

Верно. Тем не менее iContract не проверяет "правильность" во время компиляции, а просто добавляет код, который делает необходимые проверки уже на этапе выполнения.

Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:
DS>Adding notnull to the Java Programming Language

Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

DS>Авторы:
DS> Dmytro Sheyko

DS>Аннотация:
DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.
Это ничего не даёт: появляется ещё одна сущность-квазитип "NotNULL", за объектами которой тоже нужно присматривать.
Введение новых ключевых слов — это просто затенение проблемы разработчиков.

Решение проблемы — сходно с намеренным отказом от семантики throws в сигнатурах методов .Net.

Решение проблемы таким образом сходно с намеренным отказом от семантики throws в сигнатурах методов .Net, что очень печально.

Здравствуйте, iZEN, Вы писали:

ZEN>Решение проблемы таким образом сходно с намеренным отказом от семантики throws в сигнатурах методов .Net, что очень печально.

Что печально, отказ от семантики throws в сигнатурах методов? Я бы так не сказал.