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

    image

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


    — В битве Google vs Oracle поставлена жирная точка с запятой
    — Вброс: checked exceptions не нужны, доказано!
    — Учимся писать на ассемблере в Java-коде
    … и многое другое

    1. Новости


    1.1. Oracle vs Google

    Как стало известно, федеральный суд Сан-Франциско отказал Oracle в иске к Google о незаконном использовании API Java. Достаточно знаковое событие. Краткая фабула для тех, кто не следил за этой историей:
    Google: Мы написали свою виртуальную машину с которой можно работать через Java API, который знаком миллионам разработчиков!
    Oracle: Так нельзя, вы нам должны 9,000,000,000$.
    Google: Нет, можно!
    Oracle: Нет, нельзя!
    На самом деле ситуация двоякая. С одной стороны, написание API это тяжелая и неблагодарная работа. Сделать продукт удобным для пользователя удается далеко не сразу. Зачастую это длительный и итеративный процесс. Поэтому требование Oracle уважать этот труд вполне можно понять.

    С другой стороны, победа Oracle создала бы опасный прецедент, когда можно накидать огромное количество API, запатентовать их, и начать троллить технологические компании. Своим решением суд показал, что публичный API можно использовать без каких-либо лицензионных ограничений, что безусловно является плюсом для IT-индустрии в целом.


    1.2. Checked exception? Нет, не слышал

    И кстати про API. Социальные сети активно репостят занятное исследование. Парни из University of Waterloo собрали статистику обработки checked exceptions в Java. Оказалось, что в большинстве случаев разработчики их либо игнорируют, либо логируют, либо заворачивают в unchecked. Вот так неожиданность!
    image
    Источник: plg.uwaterloo.ca/~migod/846/current/projects/09-NakshatriHegdeThandra-report.pdf

    На ситуацию, когда пользователи массово некорректно используют API, можно посмотреть с двух сторон. Можно сказать: «Пользователи не те!». А можно: «API не тот!». В данном случае я склонен поддержать второй вариант. Люди правильно отмечают — сheck exceptions не справились со своей задачей. Их главное преимущество — определение на уровне сигнатуры метода — является их же главным недостатком. Мы не хотим, что бы какой-нибудь SQLException размазывался по всем компонентам приложения. Вместо этого мы изолируем его на уровне работы с данными. Чаще всего просто заворачивая в unchecked исключение. Отказ от checked исключений давно прослеживается по многим популярным фреймворкам. Возможно, пришло время посмотреть правде в глаза, и деприкейтнуть checked exceptions. Что думаете?

    1.3. Twitter открыл очередной фреймворк со странным названием

    Heron. Просто Heron. Не больше, и не меньше. Это фреймворк для stream processing. Позиционируется как замена Apache Storm. Любопытна история его создания — этот тот самый случай, когда парни сказали «А давайте перепишем все с нуля!», и переписали. Нам тоже периодически хочется выкинуть все, и создать заново. Но ввиду ограниченности ресурсов, эта идея практически всегда оказывается бесперспективной. Но у Twitter ресурсов много, поэтому им можно. Как говорится, «что позволено Юпитеру ...».

    2. Почитать


    2.1. Переходим на Java 9

    Ссылка: https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach

    Это список главных новшеств в Java 9. Его полезно иметь ввиду, что бы понимать, какая часть вашего приложения сломается при переходе на новую версию.

    2.2. Простыми словами о JIT

    Ссылка: https://advancedweb.hu/2016/05/27/jvm_jit_optimization_techniques/

    Хорошее введение в работу JIT в Java. Инлайнинг, dead code elimination, «биоморфы», и т.д…

    2.3. Пишем ассемблерные вставки в Java

    Ссылка: http://serce.me/posts/01-06-2016-wild-panama/

    Все же уже слышали про Project Panama? Автор статьи потрогал руками новую фичу — вставку ассемблера напрямую в Java-код. Теперь мы не боимся выпиливания sun.misc.Unsafe :-)

    2.4. QA процесс в Plumbr

    Ссылка: https://plumbr.eu/blog/programming/how-it-is-made-plumbr-edition

    Тестирование продукта под разные платформы и окружения — не самая легкая задача. В статье инженеры Plumbr рассказывают, как они выстраивали процесс тестирования своего продукта без выделенного QA отдела.

    3. Мудрость


    3.1. Про Junior-ов и Senior-ов


    3.2. Про самоуверенность


    3.3. Падающего подтолкни


    3.4. Двоякая мысль про алгоритмы


    4. Юмор


    4.1. Foo в Спринге

    Будьте осторожны с именами бинов в Спринге. В противном случае вы рискуете наткнуться на конфликт:
    Так же к использованию не рекомендовано имя «John Doe». Справедливости ради, «баг» уже исправлен.

    4.2. Когда ломается GitHub

    image
    Источник: classicprogrammerpaintings.com/post/144953638470/github-major-service-outage-georges-seurat

    Повод задуматься, насколько сильно мы зависим от интернет-сервисов.

    4.3. Наглая ложь Microsoft


    Кто-нибудь знает, что происходит в Windows в этот момент на самом деле?

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

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

    More

    Comments 13

      +3

      Checked exceptions определённо отжили своё. Не взлетела идея. Через дебри лямбд им придётся продираться всё сложнее. Уже в восьмёрке в связи с этим добавили UncheckedIOException. Осталось UncheckedSQLException, UncheckedInterruptedException и т. д. И заживём!

        –2
        >>Оказалось, что в большинстве случаев разработчики их либо игнорируют, либо логируют, либо заворачивают в unchecked.
        Миллионы мух не могут ошибаться.

        Ну да много кода и что? Вы же не в блокноте свои приложения разрабатываете! checked меньше шансов что исключение будет обработано не корректно. Основная проблема unchecked исключений — документирование, документирование и еще раз документирование. У программистов обычно сложности с соблюдением всех регламентов, особенно в сжатые сроки.
        По сути должна быть золотая середина.
          –1
          PS.

          Figure 15: Sample Code illustrating use of Custom Exception picked from Bruce’s blog
          Ну не верю я что Брюс Эккель мог написать «высвобождение ресурсов» в try блоке.


          Квест что выбрасывает NPE, Refrence.MOD_VERSION — константа
          instance == null? ошибка реализации: getCurrentRecomendedBuild() — без комментариев…
          Должна была быть статья о том что «checked исключения не нужны», а получилась о «большинство разработчиков не умеют с ними работать»
          Им бы подучиться, а потом делать такие громкие заявления…
            +1
            Вы бы хоть писали с чем не согласны.
            Ничего не имею против checked исключений и по сему не понимаю к чему тут холивар? Буду признателен если поделитесь своим видением, с удовольствием пересмотрю свою точку зрения.
            В какой момент стало хорошей практикой пустые кэч блоки?
        0
        «Кто-нибудь знает, что происходит в Windows в этот момент на самом деле?» проверяется совместимость софта с версией винды и наличие известных конфликтов.
          0
          На самом деле вызываются DLL-ки, зарегистрированные с помощью WerRegisterRuntimeExceptionModule. А уж какой они там трэш внутри себя творят — хз.
        • UFO just landed and posted this here
            +1
            По поводу checked exceptions двоякие мысли:
            С одной стороны, да, видно, что народ их не использует так, как было задумано во многих случаях. Заворачивают в unchecked, просто пропускают, хорошо если еще логи и стектрейсы будут. И вроде бы надо избавиться от этого.

            С другой стороны, когда я вижу код, в котором это не спускается на тормозах, где исключения честно обрабатываются, где они не заворачиваются в unchecked, а как минимум, попробовавши какие то локальные действия, и не получивши результата, заворачивают это в другое checked exception и выкидывают дальше, например когда SQLException превращается в хорошо оформленный какой-нибудь самодельный DataAccessException, с указанием на то, что же все таки случилось, вот такой код мне нравится. Его проще читать, поддерживать и дорабатывать.
            Причем на небольших проектах этого не заметно. А вот на больших, многоуровневых, модульных — очень даже.

            Лично я стараюсь обрабатывать исключения нормально. Согласен, не всегда это в принципе возможно, но где возможно — обрабатываю.

            Да, то как это сейчас многими используется — это не хорошо. Но однозначно выпиливать я бы не стал.
              0
              Я бы уже стал бы. Уже примерно понятно, чем их можно заменить — это что-то типа монады either, когда ваш метод может возвращать либо результат, либо ошибку. checked exception — это ошибка, прописанная в сигнатуре метода. Хотите ее вернуть — верните явно.

              Это не замена 1 в 1, по очевидным причинам — выкинутое исключение можно ловить на много уровней выше. Но это адекватный механизм, проверенный временем. И вы не можете просто игнорировать ошибку, почти также, как исключение — потому что результат успешного выполнения из either нужно еще достать, и если его нет — то это достаточно явно.

              Это потребует некоторого пересмотра своих привычек — но как правило, в хорошем направлении. И компонуется такой код намного легче.

              Не вобще выпилить — а выпилить из API. Для начала из своего.
                0
                Можно подумать, вашу монаду не будут пустым get-ом раскрывать.

                Проблема в том, что создатели языков программирования обычно бесконечно далеки от своих пользователей. Unchecked-исключения позволяют плохо написанному коду работать хорошо. Потому, что ошибка вылетает наверх и обрабатывается инфраструктурным кодом (это проще). Checked-исключения гасятся пустым try-catch (это проще), в итоге код работает некорректно и в лучшем случае свалится каким-нибудь NPE на следующей строчке, а в худшем случае испортит данные.

                Поэтому для реального мира с позавчерашними дедлайнами и завтрашними выпускниками-разработчиками Unchecked Exceptions это лучший вариант из всех, которые сегодня есть.
                  0

                  Будут, и что? Это нужно сделать точно также явно, как обработать checked исключение. И точно также можно схалявить. Но эти места точно также будут видны при review кода, и завтрашним выпускникам можно будет надавать по шапке и попросить так больше не делать.


                  Я не говорю, что это идеальный вариант. Но это достаточно хорошо работающий вариант.


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


                  Вот скажем хороший пример — в spring jdbc вместо checked SQLException есть кучка разных unchecked. Это проще? Несомненно. Дает ли это гарантии от неверной работы? Да никаких абсолютно.

                    0
                    > Будут, и что? Это нужно сделать точно также явно, как обработать checked исключение. И точно также можно схалявить.

                    Верно. Поэтому я и пишу, что это то же самое с теми же проблемами. И как checked-исключения в своё время казались хорошей идеей, но на практике оказались плохой, так и тут будет.

                    > Но эти места точно также будут видны при review кода, и завтрашним выпускникам можно будет надавать по шапке и попросить так больше не делать.

                    Не надают, не попросят, по разным причинам. В этом-то и проблема. Вам ведь статистику в статье привели. Вы в неё не верите?

                    > А что до unckeched всегда… так извините, их ловля «где-то наверху», это вовсе не «хорошо». Не заведомо так. В ряде случаев это не более чем попытка исправить все пост-фактум, когда ошибка уже была, и не обработана там где нужно — потому что ваш инфраструктурный код зачастую уже не знает контекста, и не может не только исправить, но даже в лог ничего путного записать — потому что без контекста анализ логов ничего не дает.

                    Сообщение + стектрейс в 90% случаев позволяет однозначно идентифицировать проблему, поэтому в лог записать есть что. Исправить не получится, да, но обычно это не имеет смысла. Откатить транзакцию и ответить «ошибка» это нормальный исход для очень многих случаев.

                    > Вот скажем хороший пример — в spring jdbc вместо checked SQLException есть кучка разных unchecked. Это проще? Несомненно. Дает ли это гарантии от неверной работы? Да никаких абсолютно.

                    Это лучше по той простой причине, что эти исключения долетят до самого верха, откатят транзакцию и залоггируются с точным местом вызова. А проверяемое исключение в 80% случаев будет проигнорировано и выполнение кода продолжится. insert упал из-за duplicated key? catch {} и идём обновлять «только что вставленную» запись, как ни в чём не бывало. Ой, это была не та запись и мы обновили чужие данные? Узнали про это полгода спустя, когда получили штраф от налоговой? Обидно, да.
                      +1
                      Сообщение + стектрейс в 90% случаев позволяет однозначно идентифицировать проблему, поэтому в лог записать есть что.


                      Это тривиально неправда. Покажите мне обработку SQLException, скажем при попытке вставить дубликат — тогда я вам, может быть, поверю. А так. именно ваш пример как раз и не позволяет обработать исключение где-то выше — вы не знаете данных, и не знаете, почему они дублируются и с чем. Тоже самое будет практически с любой вариацией SQL (data truncation скажем). Вам подвалило пара миллионов записей из внешнего источника, вы попытались сделать INSERT, получили ошибку — и нет, просто откатиться и сказать "ошибка" недостаточно, потому что вы не знаете, на каких данных это произошло. Вы просто не вставили запись, причем неизвестно какую, и штраф вам точно также прилетит — просто за другие нарушения.
                      Не надают, не попросят, по разным причинам.


                      В моих проектах — надают еще как. Просто потому, что как checked, так и в меньшей степени — Either это средства времени компиляции, и поэтому инструменты для выявления некорректной работы с ними давно существуют. Инспекция кода в IDEA например их отлично ловит. Да, pattern matching к сожалению полноценно реализовать нельзя, но даже то что есть в javaslang скажем есть — уже показывает при компиляции, если вы не обработали оба варианта. Так что я при желании об этих проблемах узнаю до внедрения в продакшн, а не при падении через два месяца.
                      Вам ведь статистику в статье привели. Вы в неё не верите?


                      Вообще-то у меня своего опыта навалом, чтобы верить в чью-то статистику просто так. Я ее просто иначе интерпретирую. Примерно половина обработчиков — это логирование (первые два пункта). И? Что изменится, если тут будут unchecked исключения? Вы будете ловить и обрабатывать "хорошо" в одном месте, много уровней выше? Не-а.

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