Дайджест интересных событий из мира Java, и вокруг нее #4 (06.06.2016 — 19.06.2016)

    image

    В этом выпуске


    — Не успеваем: дедлайны Java 9 снова сдвигаются
    — Спасаем Java EE: петиция Ларри Элиссону
    Microsoft покупает LinkedIn
    — Зачем отключать C2-компиляцию?
    — Холивар: использовать assert или нет?
    … и многое другое

    1. Новости


    1.1. Java 9: сроки плывут

    Ссылка: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html

    Главный архитектор Java Марк Рейнхольд нампомнил, что запланированные сроки «feature complete» майлстоуна уже прошли, но ряд фич Java 9 по прежнему не готовы. Речь идет о примерно 15 JEP-ах. В письме предлагается не поднимать панику, а планомерно завершать работу, ибо главное это фактическая готовность, и качество, а не формальные сроки.

    image

    Разумный подход. Однако стоит напомнить, что это не первый косяк со сроками. Все мы прекрасно знаем, насколько сложно укладываться в дедлайны при разработке. Но Java — это публичный продукт, за развитием которого следят миллионы разработчиков. Массовый пользователь не будет вникать, что такое Оракловский майлостоун, и что, дескать, он слабо привязан к датам. Это внутренняя кухня Oracle. Нам сказали «будет к такому-то числу», мы запасаемся попкорном, и ждем. Если обещанного не происходит, мы расстраиваемся, и начинаем перемывать косточки. Учитывая, продолжающиеся срывы сроков, Oracle имеет смысл поднажать на developer relations, что бы минимизировать репутационные издержки.

    1.2. Спасаем Java EE: петиция Ларри Элиссону

    Ссылка: https://www.change.org/p/larry-ellison-tell-oracle-to-move-forward-java-ee-as-a-critical-part-of-the-global-it-industry

    Вокруг Java EE продолжают кипеть страсти. Группа людей, называющая себя Java EE Guardians, подала петицию на имя CEO Oracle Ларри Элиссона, в надежде привлечь внимание топ-менеджмента компании к заморозке развития Java EE.

    Лично мне тоже не совсем понятна политика Oracle по поводу Java EE. Очень интересно было бы послушать их комментарии. Если вы где-то их встречали, поделитесь пожалуйста ссылкой.

    1.3. Microsoft покупает LinkedIn

    Ссылка: http://www.cnbc.com/2016/06/13/microsoft-to-buy-linkedin.html

    Сумма сделки, как это водится в IT-мире, достаточно скромная — каких-то 26.2 миллиарда долларов. Теперь детище Билла Гейтца получит контроль над огромным количеством внутренних Java-проектов, созданных в LinkedIn за эти годы. Не исключено, что какие-то из этих наработок мигрируют в новые проекты Microsoft.

    Так же сделка дала многим возможность пощеголять чувством юмора:

    image

    2. Почитать


    2.1. Сборник материалов по внутренностям HotSpot

    Ссылка: https://wiki.openjdk.java.net/display/HotSpot/Presentations

    Архитектор JVM John Rose занялся сбором воедино материалов по внутренностям JVM. Пока там буквально несколько ссылок, но я надеюсь, что в будущем этот список будет расти. Так что добавляйте ссылку в «Избранное».

    2.2. Статическим анализатором по OpenJDK

    Ссылка: https://medium.com/@Coder_HarryLee/openjdk-check-by-pvs-studio-f25a2187b8a0#.obyfqnjbs

    Парни прошлись статическим анализаторам PVS Studio по исходникам OpenJDK, и нашли там приличное количество проблем. Кривые проверки в if-else выражениях, забытые скобки, копипаста, отсутствующие проверки на NULL, и т.д… Можно сколь угодно скептически относится к анализаторам кода, но эти бездушные машины не зря едят свой хлеб.

    2.3. (Не) используйте assert!

    Ссылка: http://www.yegor256.com/2016/06/17/dont-use-java-assertions.html

    Егор Бугаенко стремительным домкратом промчался по европейским конференцям, наделав много шуму своими радикальными взглядами на ООП. Досталось всем — и Хибернейту, и аннотациям, и много кому еще. Печальная участь постигла и assert-ы. В своем свежем посте Егор призывает отказаться от их использования, и полагаться исключительно на exceptions.

    Взаимоотношения разработчиков и assert никогда не были простыми. Для одних это «активная» документация и халявные дополнительный «тесты». Для других это умышленная маскировка багов. Лично я assert люблю, и в нашем проекте их очень много. Есть два простых правила: не проверять ими пользовательский ввод, и не заменять ими тесты. Следуйте этим правилам, и assert станет Вашим надежным помощником.

    Что думаете по этому поводу? Используете ли Вы assert в своих проектах?

    2.4. Уменьшаем memory footrpint Java-приложения

    Ссылка: https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/

    У парней из buoyant.io один из продуктов стартует вспомогательные Java-процессы. И им очень хотелось, что бы эти процессы потребляли как можно меньше памяти. В итоге они добились желаемых результатов путем:
    — Использования 32-битного режима
    — Отключения C2

    Второй подход вызывает вопросы, но если С1 выдает им достаточную производительность — то почему бы и нет?

    3. Мудрость


    3.1. Дизайн API

    Бросить exception или вернуть код ошибки? Отдать пользователю коллекцию или итератор? Потоковая обработка или модель в памяти? Вопросов много, вариантов решения еще больше. Создание хорошего API — невероятно сложная работа.

    3.2. Внешние зависимости в проекте

    Мысль, которая может быть спасительной для одних проектов, и губительной для других.

    3.3. Как помочь open source проекту?

    Утверждение справедливо для любых проектов, не только open source. Все понимают, насколько важна хорошая документация. Но время на ее написание мы обычно находим с большим трудом.

    3.4. О функциональном программировании


    4. Юмор


    4.1.Пожалуй, лучшее объяснение, что такое map-reduce


    4.2. Микросервисы против монолитов

    Hadi Hariri из JetBrains достаточно доходчиво разъясняет ключевые отличия этих двух архитектурных подходов:image

    4.3. Если Вы собрались навести порядок в своем проекте ...

    … то помните, что возможно кто-то уже делал это до Вас.
    image
    Источник: https://twitter.com/swardley

    Выпуски: ПредыдущийСледующий

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 6

      +2

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

        +10

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


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


        Во-вторых, плюс ассертов в том, что они могут полностью уничтожаться 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, где есть ассерты в том числе внутри цикла. Скорость сортировки исключительно важна, поэтому было бы здорово не терять ни грамма производительности на отладку. Как переписать это без ассертов (или их аналога), имея возможность тестировать те же инварианты, но при этом не теряя в производительности в продакшне? Не всегда нужен красивый ООП (кто бы что под этим ни понимал), иногда нужна тупо производительность.

          +1

          На тему старта JVM есть интересный ответ apangin на StackOverflow.

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

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


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


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

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

                Если есть 15 минут времени, то вот здесь есть замечательный пример, как Adam Bien создает с нуля Java EE приложение с инъекциями, транзакциями, REST API, блэкджэком и прочим JAX-RS:
                youtu.be/FKpePxsp6g0?t=1h8m20s

              Only users with full accounts can post comments. Log in, please.