В этом выпуске
— Не успеваем: дедлайны 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-ах. В письме предлагается не поднимать панику, а планомерно завершать работу, ибо главное это фактическая готовность, и качество, а не формальные сроки.
Разумный подход. Однако стоит напомнить, что это не первый косяк со сроками. Все мы прекрасно знаем, насколько сложно укладываться в дедлайны при разработке. Но 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.
Так же сделка дала многим возможность пощеголять чувством юмора:
According to Microsoft, LinkedIn is worth ~2 of SpaceX.
— Brian Krogsgard (@Krogsgard) 13 июня 2016 г.
One is going to Mars, the other is going to spam.
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 — невероятно сложная работа.A lot of performance is dictated or bounded by API design, but it’s not often considered when designing them. Can often tell when it is, tho
— Chris Vest (@chvest) 8 июня 2016 г.
3.2. Внешние зависимости в проекте
Мысль, которая может быть спасительной для одних проектов, и губительной для других."Zero-dependency library" aka. I preferred to code a bug ridden variant of some functionality already available out there…
— Oliver Gierke (@olivergierke) 13 июня 2016 г.
3.3. Как помочь open source проекту?
Утверждение справедливо для любых проектов, не только open source. Все понимают, насколько важна хорошая документация. Но время на ее написание мы обычно находим с большим трудом.Inconvenient truth: one of the most useful contributions you can make to open source software is good documentation.
— Richard Astbury (@richorama) 14 июня 2016 г.
3.4. О функциональном программировании
Use Java 8 features and functional programming in general to improve readability, not just to save characters. Characters are cheap
— Mario Fusco (@mariofusco) 10 июня 2016 г.
4. Юмор
4.1.Пожалуй, лучшее объяснение, что такое map-reduce
Map/filter/reduce in a tweet:
— Steven Luscher (@steveluscher) 10 июня 2016 г.
map([, , ], cook)
=> [, , ]
filter([, , ], isVegetarian)
=> [, ]
reduce([, ], eat)
=>
4.2. Микросервисы против монолитов
Hadi Hariri из JetBrains достаточно доходчиво разъясняет ключевые отличия этих двух архитектурных подходов:4.3. Если Вы собрались навести порядок в своем проекте ...
… то помните, что возможно кто-то уже делал это до Вас.Источник: https://twitter.com/swardley
Предыдущие выпуски
#3 (23.05.2016 — 05.06.2016)#2 (09.05.2016 — 22.05.2016)
#1 (02.05.2016 — 08.05.2016)
Комментарии (6)
lany
20.06.2016 08:18+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, где есть ассерты в том числе внутри цикла. Скорость сортировки исключительно важна, поэтому было бы здорово не терять ни грамма производительности на отладку. Как переписать это без ассертов (или их аналога), имея возможность тестировать те же инварианты, но при этом не теряя в производительности в продакшне? Не всегда нужен красивый ООП (кто бы что под этим ни понимал), иногда нужна тупо производительность.
AlexZaharow
20.06.2016 10:20+13.3. Как помочь open source проекту?
Inconvenient truth: one of the most useful contributions you can make to open source software is good documentation.
Думаю, что это касается не только opensource. Хорошая документация — это вообще бич любого проекта. Но думаю, что внутренняя мотивация писать документацию заслуживает отдельного исследования, а не просто заметки, что это надо делать.
Хоть я и не всегда хочу писать документацию, но в итоге выяснил, что её надо писать как минимум для себя. Через неделю глубоких и не очень исследований и поисков можно совсем забыть что было и зачем. А так посмотрел на описание и Ура! Вспомнил! Так что документация — это письмо самому себе в будущее, которое поможет сэкономить время. Поэтому я обоими руками «за» правило вообще писать документацию, комментарии в коде, делать скриншоты результатов и т.д.
Throwable
20.06.2016 10:59+1Лично мне тоже не совсем понятна политика Oracle по поводу Java EE. Очень интересно было бы послушать их комментарии. Если вы где-то их встречали, поделитесь пожалуйста ссылкой.
Вообще странная реакция от Oracle, у которого огромное количество продуктов завязано на Weblogic-е. С другой стороны, я считаю идею забить на JavaEE 100% правильной, т.к. технология совершенно не соответствует современным запросам. (p.s. больше 10 лет занимаюсь разработкой на JavaEE).
2.3. (Не) используйте assert!
Как уже много где писалось, assert хорош для повышения читаемости кода, когда валидность значений неясна из контекста. Assert объясняет, что конкретное условие в данном месте гарантируется и что дополнительные проверки не требуются.antrew
23.06.2016 12:47А можно поподробнее, что не так с JavaEE? В чем она не соответствует современным запросам?
Как по мне, так Java EE 7 позволяет писать очень стройный код с минимумом бойлерплэйта. Прям вот берёшь и пишешь бизнес логику, которую можно сразу запустить на сервере приложений. В докере, если угодно.
Если есть 15 минут времени, то вот здесь есть замечательный пример, как Adam Bien создает с нуля Java EE приложение с инъекциями, транзакциями, REST API, блэкджэком и прочим JAX-RS:
youtu.be/FKpePxsp6g0?t=1h8m20s
lany
Про «сроки плывут» всё же не надо нагнетать. Срок GA никто пока не сдвигает. Если немного дольше поработают над фичами по конкретным JEP'ам, ничего плохого не будет. Покажите ещё проект, где FC за 10 месяцев до GA. Самые серьёзные и рискованные фичи впилили, это главное.