В этом выпуске
— Не успеваем: дедлайны 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: петиция Ларри Элиссону
Вокруг 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.
One is going to Mars, the other is going to spam.
— Brian Krogsgard (@Krogsgard) 13 июня 2016 г.
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
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 г.
Бросить exception или вернуть код ошибки? Отдать пользователю коллекцию или итератор? Потоковая обработка или модель в памяти? Вопросов много, вариантов решения еще больше. Создание хорошего API — невероятно сложная работа.
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 проекту?
Inconvenient truth: one of the most useful contributions you can make to open source software is good documentation.
— Richard Astbury (@richorama) 14 июня 2016 г.
Утверждение справедливо для любых проектов, не только open source. Все понимают, насколько важна хорошая документация. Но время на ее написание мы обычно находим с большим трудом.
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:
map([, , ], cook)
=> [, , ]filter([, , ], isVegetarian)
=> [, ]reduce([, ], eat)
=>— Steven Luscher (@steveluscher) 10 июня 2016 г.
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)
Автор: devozerov
