Comments 6

Про «сроки плывут» всё же не надо нагнетать. Срок GA никто пока не сдвигает. Если немного дольше поработают над фичами по конкретным JEP'ам, ничего плохого не будет. Покажите ещё проект, где FC за 10 месяцев до GA. Самые серьёзные и рискованные фичи впилили, это главное.

Про ассерты (разные темы в разных комментариях пишу, чтобы удобнее было дискутировать). Егор умеет вбрасывать и собрал вокруг себя неплохую секту почитателей. Но всё-таки слабовато. Я написал ему комментарий там, он ответил отпиской и продолжать дискуссию в его блоге не вижу смысла. Давайте повторю мысли здесь.


Во-первых, никогда не путайте ассерты с предусловиями, это абсолютно разные вещи. Ассерты — это часть разработки/отладки/тестирования, но не часть нормального функционирования приложения.


Во-вторых, плюс ассертов в том, что они могут полностью уничтожаться JIT-компилятором в режиме -da. Это делается потому, что необходимость ассертов инициализируется при загрузке класса записью автогенерированного static final boolean поля, а JIT по дефолту верит static final полям. Для иллюстрации такой класс:


public class Test { 
   public void test(int x) {
     assert x > 0;
   }
}

javac превратит его примерно в такое:


public class Test { 
   static final boolean $assertionsDisabled = !Test.class.desiredAssertionStatus();

   public void test(int x) {
     if(!$assertionsDisabled && x > 0)
        throw new AssertionError();
   }
}

Вот как бы и всё. Магия именно в том, что при JIT-компиляции проверка if(!$assertionsDisabled) вычисляется статически и в -da пропадает условие целиком, а в -ea остаётся просто if(x > 0). Вы можете сами сделать подобный механизм. Хороший пример — класс java.util.Tripwire: по сути альтернативный ассерт, который включается не -ea, а системной настройкой, и добавляет отладочное логирование, а не исключения.


Ассерты нужны для тестирования и отладки потрохов. Юнит-тестом вы можете проверить выход метода или состояние системы после выхода. Но трудно проверить состояние системы в середине выполнения метода. Тут ассерты и приходят на помощь. Егор утверждает, что все проблемы можно решить парой-тройкой декораторов. Я привёл в пример метод из реализации алгоритма TimSort, где есть ассерты в том числе внутри цикла. Скорость сортировки исключительно важна, поэтому было бы здорово не терять ни грамма производительности на отладку. Как переписать это без ассертов (или их аналога), имея возможность тестировать те же инварианты, но при этом не теряя в производительности в продакшне? Не всегда нужен красивый ООП (кто бы что под этим ни понимал), иногда нужна тупо производительность.

3.3. Как помочь open source проекту?
Inconvenient truth: one of the most useful contributions you can make to open source software is good documentation.

Думаю, что это касается не только opensource. Хорошая документация — это вообще бич любого проекта. Но думаю, что внутренняя мотивация писать документацию заслуживает отдельного исследования, а не просто заметки, что это надо делать.
Хоть я и не всегда хочу писать документацию, но в итоге выяснил, что её надо писать как минимум для себя. Через неделю глубоких и не очень исследований и поисков можно совсем забыть что было и зачем. А так посмотрел на описание и Ура! Вспомнил! Так что документация — это письмо самому себе в будущее, которое поможет сэкономить время. Поэтому я обоими руками «за» правило вообще писать документацию, комментарии в коде, делать скриншоты результатов и т.д.
Лично мне тоже не совсем понятна политика Oracle по поводу Java EE. Очень интересно было бы послушать их комментарии. Если вы где-то их встречали, поделитесь пожалуйста ссылкой.


Вообще странная реакция от Oracle, у которого огромное количество продуктов завязано на Weblogic-е. С другой стороны, я считаю идею забить на JavaEE 100% правильной, т.к. технология совершенно не соответствует современным запросам. (p.s. больше 10 лет занимаюсь разработкой на JavaEE).
2.3. (Не) используйте assert!


Как уже много где писалось, assert хорош для повышения читаемости кода, когда валидность значений неясна из контекста. Assert объясняет, что конкретное условие в данном месте гарантируется и что дополнительные проверки не требуются.
А можно поподробнее, что не так с JavaEE? В чем она не соответствует современным запросам?

Как по мне, так Java EE 7 позволяет писать очень стройный код с минимумом бойлерплэйта. Прям вот берёшь и пишешь бизнес логику, которую можно сразу запустить на сервере приложений. В докере, если угодно.

Если есть 15 минут времени, то вот здесь есть замечательный пример, как Adam Bien создает с нуля Java EE приложение с инъекциями, транзакциями, REST API, блэкджэком и прочим JAX-RS:
youtu.be/FKpePxsp6g0?t=1h8m20s
Only those users with full accounts are able to leave comments. Log in, please.