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

в 19:03, , рубрики: java, java дайджест javaee assert, Программирование, метки:

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

Предыдущие выпуски

#3 (23.05.2016 — 05.06.2016)
#2 (09.05.2016 — 22.05.2016)
#1 (02.05.2016 — 08.05.2016)

Автор: devozerov

Источник

Поделиться новостью

* - обязательные к заполнению поля