Молодцы, что статью написали! И жалко, что вас на конференцию не взяли (я рекомендовал брать, но не послушали).
Да, FABA — это был проект в JetBrains, и он интегрирован в Идейку. Чистоту методов тоже иногда умеем выводить. И контракты вида null->false. И по сорцам умеем иногда, не только по байткоду. Причём по сорцам на лету в процессе редактирования.
Вопрос: при сравнении строк вы различаете равенство по ссылке и по контенту? str1.equals(str2) && str1 != str2 вы подсветите (ошибочно) как всегда ложное или нет?
если два разных потока в любом месте системы читают с одного и того же адреса памяти, то они никогда не должны одновременно считывать разные значения.
Что-то после слова "одновременно" возникли сомнения в квалификации автора. Во многопоточной среде понятие одновременности довольно расплывчато и вообще не нужно.
Интересно, а если метод виртуальный, вы делаете выводы, что у него нет побочных эффектов на основании реализации? Или смотрите всех доступных наследников? Что если анализируется код библиотеки и предполагается наличие наследников вне зоны видимости анализатора?
О да, насчёт fillInStackTrace совсем не удивлён. Нам его тоже приходится специально обрабатывать, например, при выводе чистоты методов по байткоду. Слишком уж он вездесущ, чтобы его просто проигнорировать.
Вы, наверно, давно учились. Это же обычный паттерн-матчинг, просто в Java пока нет синтаксиса для него. Оптимизация частного случая конкретной реализации без изменения семантики — прекрасное применение instanceof. Альтернатива — паттерн visitor, который сегодня уже кажется бойлерплейтом.
javah из старых версий не съест скомпилированный в новую версию класс. Впрочем, Котлин пока новее восьмёрки версии не выдаёт. Таргетить на 9-10 Котлину, наверно, смысла и нет. А вот если в 11 нестмейты выкатят, Котлин от этого выиграет.
И валидацию параметров конструктора ломбок прикрутит? Если у меня class Range { private final int from, to; } и инвариант from <= to, куда мне инвариант впихнуть?
На самом деле проапдейтили, даже в CHANGELOG написали, только поленились выпустить свежую версию почему-то. А вообще ты донат занёс людям или только требовать умеешь? ;-)
Вот на совести разработчика — это сделает язык дырявым. Простой пример:
fun test() {
val x: String
run { x = "Hello" }
println(x.length)
}
fun <R> run(block: () -> R): Unit {
contract {
callsInPlace(block, EXACTLY_ONCE)
}
//return block() бугагашечка
}
В результате, если мы поверили контракту, но не проверили его, то в методе test() мы получаем обращение к неинициализированной локальной переменной — то, чего, например, в Java не может быть никогда и ни за что.
На самом деле даже если контракты проверяются при компиляции, не забываем, что компиляция раздельная. Если метод run в прекомпилированном классе, и мы там подхачили контракт руками, мы получим тот же эффект. Опасной мне кажется эта фича, в общем. Может, конечно, разработчики умнее меня и как-то всё предусмотрели...
Молодцы, что статью написали! И жалко, что вас на конференцию не взяли (я рекомендовал брать, но не послушали).
Да, FABA — это был проект в JetBrains, и он интегрирован в Идейку. Чистоту методов тоже иногда умеем выводить. И контракты вида null->false. И по сорцам умеем иногда, не только по байткоду. Причём по сорцам на лету в процессе редактирования.
Вопрос: при сравнении строк вы различаете равенство по ссылке и по контенту?
str1.equals(str2) && str1 != str2вы подсветите (ошибочно) как всегда ложное или нет?Кстати, на коде Идеи у вас вменяемое количество предупреждений? :-)
Если кто забредёт сюда, не читайте этот бред выше, который я восемь лет назад написал. Был маленький, глупый.
Что-то после слова "одновременно" возникли сомнения в квалификации автора. Во многопоточной среде понятие одновременности довольно расплывчато и вообще не нужно.
Интересно, а если метод виртуальный, вы делаете выводы, что у него нет побочных эффектов на основании реализации? Или смотрите всех доступных наследников? Что если анализируется код библиотеки и предполагается наличие наследников вне зоны видимости анализатора?
Конкретно это и в джаве работает. Корутины для этого не нужны.
Есть вариант с asSequence, если вас это не устраивает. Впрочем, он особо не отличается от Java Stream API.
Покажите конкретный пример
О да, насчёт
fillInStackTraceсовсем не удивлён. Нам его тоже приходится специально обрабатывать, например, при выводе чистоты методов по байткоду. Слишком уж он вездесущ, чтобы его просто проигнорировать.Вы, наверно, давно учились. Это же обычный паттерн-матчинг, просто в Java пока нет синтаксиса для него. Оптимизация частного случая конкретной реализации без изменения семантики — прекрасное применение instanceof. Альтернатива — паттерн visitor, который сегодня уже кажется бойлерплейтом.
javah из старых версий не съест скомпилированный в новую версию класс. Впрочем, Котлин пока новее восьмёрки версии не выдаёт. Таргетить на 9-10 Котлину, наверно, смысла и нет. А вот если в 11 нестмейты выкатят, Котлин от этого выиграет.
И валидацию параметров конструктора ломбок прикрутит? Если у меня
class Range { private final int from, to; }и инвариантfrom <= to, куда мне инвариант впихнуть?Хотя, конечно, вру. "Some initial work on supporting JDK10" звучит совсем неубедительно.
На самом деле проапдейтили, даже в CHANGELOG написали, только поленились выпустить свежую версию почему-то. А вообще ты донат занёс людям или только требовать умеешь? ;-)
Вот на совести разработчика — это сделает язык дырявым. Простой пример:
В результате, если мы поверили контракту, но не проверили его, то в методе
test()мы получаем обращение к неинициализированной локальной переменной — то, чего, например, в Java не может быть никогда и ни за что.На самом деле даже если контракты проверяются при компиляции, не забываем, что компиляция раздельная. Если метод
runв прекомпилированном классе, и мы там подхачили контракт руками, мы получим тот же эффект. Опасной мне кажется эта фича, в общем. Может, конечно, разработчики умнее меня и как-то всё предусмотрели...