Adding notnull to the Java Programming Language - Java

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

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

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

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

Ну ладно, не будем далеко уходить от темы.
В подходе, описанном в статье, исключение NullPointerException никто не отменяет, просто его переносят поближе к прикладному коду, в то же время пытаясь часть проблемы переложить на компилятор (этап компиляции).
Смешно.
Придумывают новое ключевое слово и разделяют одну проблему на две проблемы.
Смешно.

Я говорю, что исключение NullPointerException не на пустом месте появляется (каламбур: хотя как раз-таки на пустом). Именно это исключение — важный знак плохого дизайна. И дело решения проблемы с нулевыми ссылками лежит исключительно в плоскости прикладного кода — его дизайна. Не надо перекладывать надуманную проблему низкоквалифицированных кодеров на среду программирования.
Не получится.

Не нужно подстилать соломку там, где под ногами болото, рано или поздно выплывут другие связанные с этим проблемы, а вы (или кто-то после вас) погрязнете в их решении (утонете).

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

C>>Что печально, отказ от семантики throws в сигнатурах методов? Я бы так не сказал.
ZEN>А я так говорю.
В священные войны.

ZEN>Ну ладно, не будем далеко уходить от темы.
ZEN>В подходе, описанном в статье, исключение NullPointerException никто не отменяет, просто его переносят поближе к прикладному коду, в то же время пытаясь часть проблемы переложить на компилятор (этап компиляции).
ZEN>Смешно.
Интересная оценка.

ZEN>Придумывают новое ключевое слово и разделяют одну проблему на две проблемы.
ZEN>Смешно.
Где вторая проблема?

ZEN>Я говорю, что исключение NullPointerException не на пустом месте появляется (каламбур: хотя как раз-таки на пустом). Именно это исключение — важный знак плохого дизайна.
Всегда ли нам приходится иметь дело с таким хорошим дизайном что в нем не встречаются NPE?

ZEN>И дело решения проблемы с нулевыми ссылками лежит исключительно в плоскости прикладного кода — его дизайна. Не надо перекладывать надуманную проблему низкоквалифицированных кодеров на среду программирования.
ZEN>Не получится.
Да ладно, до этого у всех IDE получалось, а тут бац и не получится. Почему не получится? IDE призваны решать проблемы кодера. Чем они успешно и занимаются.

ZEN>Не нужно подстилать соломку там, где под ногами болото, рано или поздно выплывут другие связанные с этим проблемы, а вы (или кто-то после вас) погрязнете в их решении (утонете).
Это предсказание? Или опыт? Если опыт то тогда делись какие именно проблемы всплывут?

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

iZEN>>Придумывают новое ключевое слово и разделяют одну проблему на две проблемы.
iZEN>>Смешно.
B>Где вторая проблема?
Там же, где и была: обрабатывать NullPointerException всё-таки нужно.

iZEN>>Я говорю, что исключение NullPointerException не на пустом месте появляется (каламбур: хотя как раз-таки на пустом). Именно это исключение — важный знак плохого дизайна.
B>Всегда ли нам приходится иметь дело с таким хорошим дизайном что в нем не встречаются NPE?
Почему NullPointerException не встречается в средах програмирования на Java? Это же целые конгломераты классов и объектов с гибкой системой управления кодом.

iZEN>>И дело решения проблемы с нулевыми ссылками лежит исключительно в плоскости прикладного кода — его дизайна. Не надо перекладывать надуманную проблему низкоквалифицированных кодеров на среду программирования.
iZEN>>Не получится.
B>Да ладно, до этого у всех IDE получалось, а тут бац и не получится. Почему не получится? IDE призваны решать проблемы кодера. Чем они успешно и занимаются.
Я не про IDE, а вообще — про среду исполнения и среду создания кода, включающие в себя рантайм, компилятор, инструменты отладки и сборки.

iZEN>>Не нужно подстилать соломку там, где под ногами болото, рано или поздно выплывут другие связанные с этим проблемы, а вы (или кто-то после вас) погрязнете в их решении (утонете).
B>Это предсказание? Или опыт? Если опыт то тогда делись какие именно проблемы всплывут?
Это опыт из Delphi 3->5->7.

Проблемы:
1) Управляемость исходным кодом может быть нарушена — совмещение старого и нового кода: не плодите сущностей почём зря, ими придётся управлять;
2) Потенциальная угроза "несрабатывания" защитного механизма вследствие такой же квалификации программиста, какая у него была до нововведений: человеческий фактор;
3) Новое ключевое слово и усложнение средств разработки/компиляции/отладки.

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

B>>Где вторая проблема?
ZEN>Там же, где и была: обрабатывать NullPointerException всё-таки нужно.

Вообще-то, лично я -- стронник подхода fail fast, т.е. ошибки в программе должны обнаруживать себя "во весь голос" и как можно раньше. Исключения типа NullPointerException вовсе не нужно как-то обрабатывать, они просто не должны возникать. Едиственная причина, по которой подобного рода исключения могут обрабатываться, -- это для более ранней и точной диагностики ошибки. Что касается описываемого в статье расширения компилятора, то оно позволяет такие ошибки (по крайней мере часть из них), обнаруживать еще раньше, на этапе компиляции.

iZEN>>>Я говорю, что исключение NullPointerException не на пустом месте появляется (каламбур: хотя как раз-таки на пустом). Именно это исключение — важный знак плохого дизайна.
B>>Всегда ли нам приходится иметь дело с таким хорошим дизайном что в нем не встречаются NPE?
ZEN>Почему NullPointerException не встречается в средах програмирования на Java? Это же целые конгломераты классов и объектов с гибкой системой управления кодом.

iZEN>>>И дело решения проблемы с нулевыми ссылками лежит исключительно в плоскости прикладного кода — его дизайна. Не надо перекладывать надуманную проблему низкоквалифицированных кодеров на среду программирования.

Мне кажется, что многим приходилось иметь дело с "чужим кодом". И чем более профессиональным становится разработчик, тем более "низкоквалифицированный" код он встречает. И что самое неприятное, что просто от того, что кто-то понимает, насколько данный код непрофессионален, он (этот код) не становится лучше. На самом-то деле, проблема низкоквалифицированных кодеров -- это моя проблема. А низкоквалифицированные кодеры могут о ней и не подозревать. И меня больше волновал вопрос, почему NullPointerException все-таки встречается в моих программах.

Проанализировав код я пришел к выводу, что все ссылочные значения можно разделить на два вида: те, которые могут принимать нулевое значение, и те, которые не могут. И большой риск возникновения NPE появляется тогда, когда с потенциально нулевыми значениями работают так, как будто, они никогда не могут быть null'ом. Т.е. когда разница между этими двумя видами ссылочных значений игнорируется. В общем-то, она всегда была, просто теперь она стала явной.

iZEN>>>Не нужно подстилать соломку там, где под ногами болото, рано или поздно выплывут другие связанные с этим проблемы, а вы (или кто-то после вас) погрязнете в их решении (утонете).
B>>Это предсказание? Или опыт? Если опыт то тогда делись какие именно проблемы всплывут?
ZEN>Это опыт из Delphi 3->5->7.

ZEN>Проблемы:
ZEN>1) Управляемость исходным кодом может быть нарушена — совмещение старого и нового кода: не плодите сущностей почём зря, ими придётся управлять;

Я постарался уделить должное внимание обратной совместимости. Если есть какие-то конкретные замечения, всегда пожалуйста.

ZEN>2) Потенциальная угроза "несрабатывания" защитного механизма вследствие такой же квалификации программиста, какая у него была до нововведений: человеческий фактор;

Да, есть такая угроза. Также как и есть шанс "срабатывания".

ZEN>3) Новое ключевое слово и усложнение средств разработки/компиляции/отладки.

Данное расширение действительно приводит в той или иной степени к усложнению инструментальных средств. Тем не менее, эта задача вполне реальна. В качестве доказательства, я привел код экспериментального компилятора.

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

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

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

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

Между делом случайно нашел интересный баг 4449383 в Sun Bug Database:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383

Bug ID: 4449383
Votes 521
Synopsis Support For 'Design by Contract', beyond "a simple assertion facility"
Category java:specification
Reported Against 1.3
State In progress, request for enhancement
Submit Date 23-APR-2001
Description слишком много чтобы писать сюда, но в двух словах, разработчики хотят Design by Contract в Java.

Там же в коментариях есть такая вот запись:

Submitted On 04-MAY-2001
Ixchel

It may be quite difficult to implement this unless feature
request #4211070 ("Java should support const parameters,
like C++, for code maintenance") is also approved.

I would also like to see a way to declare certain object
references (fields, method parameters, local variables,
etc.) to be guaranteed to be non-null. This could be part
of a design-by-contract proposal, or a separate proposal.
It would be supported by data flow tracing in the compiler
(similar to what's used now to detect unassigned final
variables) to detect possible violations. For instance:

notnull String foo = "abc"; // foo can never be null foo = null; // Compiler error here foo = "def"; // No Compiler error here String bar = getSomePossiblyNullString(); foo = bar; // Compiler error here if (bar != null) foo = bar; // No compiler error here

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

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

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

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

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

C>Между делом случайно нашел интересный баг 4449383 в Sun Bug Database:

C>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383

C>Bug ID: 4449383
C>Votes 521
C>Synopsis Support For 'Design by Contract', beyond "a simple assertion facility"
C>Category java:specification
C>Reported Against 1.3
C>State In progress, request for enhancement
C>Submit Date 23-APR-2001
C>Description слишком много чтобы писать сюда, но в двух словах, разработчики хотят Design by Contract в Java.

В очередной раз меня посетила гениальная идея -- Design by Contract реализуется элементарно через XDoclet и AspectJ. XDoclet извлекает информацию о пред-, постусловиях и инвариантах из JavaDoc тэгов и генерирует AspectJ файлы аспектов, которые эти самые инварианты и реализуют незаметно для javaс компилятора. Это конечно требует дополнительных шагов компиляции, но совсем не сложно написать простенький плагин к мавену, который это все будет автоматизировать.
Я уже начал пускть слюни как я стану знаменитым и богатым запатентовав свою идею, но в очередной раз меня очень жестоко обломал гугль. Уже существует проект barter, который работает именно так, как я описал, но без мавена.
Кроме того, есть еще один проект contract4j, который использует анотации из пятой Java и Annotation Processing Tool (APT) для описания пре- и постусловий с инвариантами.
Так что тем, кому DoB нужен прямо сейчас уже могут им пользоваться, все необходимое для этого есть.
Ну а для статического анализа кода инструментов тоже хватает.
Хотя конечно было бы неплохо если бы компилятор был более "разумен" и мог генерировать больше предупреждений о потенциальных ошибках на этапе компиляции. В том числе необходимую информацию компилятор, как я уже раньше писал, мог бы получить из тех же самых пре- и постусловий, и для этого не потребуется расширять язык новыми ключевыми словами.

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

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

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

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

Эта идея полный бред.

Вместо того чтобы нормально проектировать системы, и ответственно подходить к вопросу проверок кода и тп предлагается ввести "чудо" слово, после которого все проблемы разом уйдут. Это не так. Программисты у которых руки растут из невнятных мест, всегда будут писать плохо. Хоть ты трижды напиши notnull.

Потом техническая сторона вопроса смешна.
private notnull String firstName;
уже должен кинуть ошибку так как firstName — null (!!! СЮРПРАЙЗ !!!)
Это значит придется забивать всегда обьект какимто дефолтным значением. И следовательно идея с notnull вообще непонятна зачем, когда можно просто юзать дефолтные значения.

При этом то что указывалось как предпосылка — тоже полный бред.
Если мы можем передать null а потом обьект упадет — значит это должно быть отловлено конструктором. Если это чужая библиотека — соответствующий багрепорт соответствующему создателю кода.

И вообще строго говоря — null значения не на пустом месте появляются. И чаще всего не по вине разработчиков которые не вставили проверку на null, а по вине тех кто вообще не представляет какие процессы идут в их системе.

Сорри что незарганый — потом зарегаюсь и подпишусь уже как следует.

Сергей.

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

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

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

А>Эта идея полный бред.

Если есть желание это обсудить, предлагаю написать мне в приват. За бурными эмоциями я пока не уловил суть критики.

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

А>>Эта идея полный бред.

D>Если есть желание это обсудить, предлагаю написать мне в приват. За бурными эмоциями я пока не уловил суть критики.

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

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

C0s>в свете того, что здесь совсем недавно уже обсуждались такие решения как OVal, которые уже претворили в некотором виде идею контрактности в жизнь, не очень понятно, зачем обсуждать статью

Как я понимаю, статья все же про compile time. Что позволяет обнаружить проблему ещё раньше, чем Oval.

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

А>И вообще строго говоря — null значения не на пустом месте появляются. И чаще всего не по вине разработчиков которые не вставили проверку на null, а по вине тех кто вообще не представляет какие процессы идут в их системе.

Видал я проекты заполненые проверками на null. К чему нужны эти тоны лишнего кода, когда их можно смела выкинуть, если убедиться что переменная никогда не станет null.

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

C0s>>в свете того, что здесь совсем недавно уже обсуждались такие решения как OVal, которые уже претворили в некотором виде идею контрактности в жизнь, не очень понятно, зачем обсуждать статью

B>Как я понимаю, статья все же про compile time. Что позволяет обнаружить проблему ещё раньше, чем Oval.

я, в большей степени, имел в виду, что констрейнтов в общем случае может быть много одновременно и не только на not-null
гарантия not-null — частный случай программирования-по-контракту и, хотя она даже сама по себе полезна, всё же интереснее обсуждать более общие случаи и подходы

потом, в compile-time много не накопать — обычно алгоритмы характеризуются тем, что работают на значениях, попавших в контекст выполнения алгоритма "извне" (как параметры нескольких вложенных вызовов методов, как параметры инстанцирования классов и т.п.). и компилятору просто невмоготу построить все возможные пути, которые ведут в текущий компилируемый метод, и он в любом случае, получается, должен вставлять runtime-проверки
а пользы, если он начнёт отлавливать 1% случаев, аналогичных по природе Statement is unreachable — ровно на этот 1%. ты вот часто, к примеру, видишь сообщение компилятора statement is unreachable?

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

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

А>>И вообще строго говоря — null значения не на пустом месте появляются. И чаще всего не по вине разработчиков которые не вставили проверку на null, а по вине тех кто вообще не представляет какие процессы идут в их системе.

B>Видал я проекты заполненые проверками на null. К чему нужны эти тоны лишнего кода, когда их можно смела выкинуть, если убедиться что переменная никогда не станет null.

смелость — города берёт, но правильный код писать не помогает.
к чему это я? да к тому, что лучше проверок расставить, чем использовать "метод пристального взгляда" для "убеждения, что переменная никогда не станет null". лучше всего — чтобы проверки расставлялись "магическо-автоматическим способом", что, собственно, на аннотациях делается достаточно удобно.
кстати, автор про аннотации справедливо упоминает

а лично мне, в конечном итоге, не так важно, кто потом по этим аннотациям генерирует проверки — aop или компилятор. просто в текущей ситуации требовать усложнения компилятора, когда есть уже целый ряд инструментов, решающих задачу, как минимум, достойно принципа "семь раз отмерь". к тому же отдельные инструменты — всегда двигатель прогресса, т.к. присутствует элемент соперничества. а заложить это в компилятор — тогда по полгода придётся ждать добавления поддержки очередного констрейнта и прочих удобств.

Жаль что JetBrains лезет вперёд батьки и вводит нестандартные конструкции.

На мой взгляд намного полезнее и корректнее было бы ввести систему аннотаций, например, так:

java.constraint.Mandatory — не зависящий от языка аналог NotNull
java.constraint.Optional — аналог Nullable
java.constraint.Range(min,max) — диапазон значений
java.constraint.Size(min,max) — размер коллекции или массива
java.constraint.Length(min,max) — длина строки
java.constraint.Pattern(value) — регулярное выражение
java.constraint.OCL(expression)

C0s>я, в большей степени, имел в виду, что констрейнтов в общем случае может быть много одновременно и не только на not-null
Золотые слова. Я чуть ниже откомментил правильный на мой взгляд подход.

B>>Всегда ли нам приходится иметь дело с таким хорошим дизайном что в нем не встречаются NPE?
ZEN>Почему NullPointerException не встречается в средах програмирования на Java? Это же целые конгломераты классов и объектов с гибкой системой управления кодом.
Пять копеек. Встречается. Eclipse, исходный код и архитектура которого есть настоящий кошмар.

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

B>Пять копеек. Встречается. Eclipse, исходный код и архитектура которого есть настоящий кошмар.
Конкретнее можно? Про исходный код... к примеру, SWT/JFace так попросту напичкан всевозможными NullPointerException, IllegalArgumentException и etc. В особенности интересна претензия к архитектуре Eclipse, это OSGi вам не по душе или что?

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

B>Жаль что JetBrains лезет вперёд батьки и вводит нестандартные конструкции.
Есть потребность в контрактном программировании, а JDK на данный момент не предоставляет удобный инструментарий для того (даже контракты на утверждениях assert — это все же жуткий overhead), так что же — ждать у моря погоды?

B>На мой взгляд намного полезнее и корректнее было бы ввести систему аннотаций, например, так:
B>...
Посмотрите Oval, там все это есть. Про java.constraint.Optional не понял, какой смысл в него вкладывается?

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

В принципе, Blazkowicz тоже дело говорит. Далеко не все классы вообще должны бояться пустых параметров, т.е. могут и иметь некоторую семантику обработки null. А также многие классы или уверенно не должны получать null (по логике связи объектов), или же локализация данной ошибки настолько минимальна по времени, что дополнительные проверки только отнимут лишнее время. Все субъективно... но я пока увидел эффективность применения Oval только в BLL-объектах, слишком много зайцев за раз:

контракт с БД, в которую сливаются потенциально опасные данные программы (кто еще не знает баян про тетку-оператора, у которой на клавиатуре отпала кнопка "0", так она — умница — не растерялась, стала забивать букву "О" вместо нулей в ИНН?), оно хорошо, конечно, получать от БД SQL-ошибку, но, во-первых, это лишняя нагрузка на соединение, а во-вторых, порой приходится работать с БД, которые проектировали... мягко скажем, очень давно... и ничего про нормализацию, ограничения целостности и т.п. методики не знали;
к примеру, при работе с ООБД Db4o библиотека Oval стал средством, которое по сути дотянуло эту БД по безопасности до уровня современных реалиционных БД (ограничения на уровне объектов восполнили отсутствие такой проверки в движке БД);
возможность на основе данного контракта предупреждать пользователя о некорректных промежуточных данных (завязать GUI с BLL на основе Oval).

	От:	iZEN
	Дата:	11.08.05 14:02
	Оценка:

	От:	Blazkowicz
	Дата:	11.08.05 14:22
	Оценка:	+1

	От:	iZEN
	Дата:	11.08.05 18:49
	Оценка:

	От:	dshe
	Дата:	12.08.05 06:44
	Оценка:

От:	caustic	http://commitq.com/
Дата:	19.10.05 09:21
Оценка:

	От:	Baudolino
	Дата:	13.08.07 11:07
	Оценка:	6 (1) +1

От:	rsn81	http://rsn81.wordpress.com
Дата:	13.08.07 12:55
Оценка:

	От:	Аноним
	Дата:	07.08.07 12:57
	Оценка:	-1

	От:	C0s
	Дата:	07.08.07 14:53
	Оценка:	+1