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

— Microprofile: очередная попытка реанимации Java EE
— Заденет ли Brexit Java-разработчиков?
— Раскладываем по полочкам Java Memory Model
— Профилирование: слабые стороны AsyncGetCallTrace
… и многое другое

1. Новости

1.1. Microprofile

Ссылка 1: http://microprofile.io/
Ссылка 2: https://developer.ibm.com/wasdev/blog/2016/06/27/microprofile-announce/
Ссылка 3: http://middlewareblog.redhat.com/2016/06/27/microprofile-collaborating-to-bring-microservices-to-enterprise-java/
Ссылка 4: http://www.tomitribe.com/blog/2016/06/microprofile/

Java EE продолжает тонуть в хайпе микросервисов. Парни из IBM, RedHat и нескольких других компаний решили бросить ей спасательный круг, анонсировав инициативу MicroProfile.io. Задача — подогнать стандарты Java EE под современные тренды. Читай — натянуть Java EE на микросервисы. Причем в буквальном смысле. Например, предлагается чуть ли не стандартизировать максимальный размер джарника и время старта приложения. Что-то вроде «enlarge your ...», только наоборот.

Реакция на инициативу неоднозначна. Кто-то ехидничает:

To all of those voices claiming EJBs are microservices, I salute you.....

— James Watters (@wattersjames) 27 июня 2016 г.

Кто-то предлагает не тратить время на заведомо проигрышные идеи:

@jamie_allen @darachennis our industry has a habit of ignoring natural selection. Some bad ideas just need to gracefully be end of life.

— Todd L. Montgomery (@toddlmontgomery) 1 июля 2016 г.

Мое мнение — инициатива, безусловно, хорошая. Но вся предыдущая история Java EE была про «стандарты ради стандартов». Удастся ли MicroPofile.io учесть ошибки прошлого, и переключиться на модель «стандарты для людей», покажет время.

Между тем, ситуация вокруг заморозки Java EE продолжает накаляться. Так, вышла очередная разжигающе-апокалиптическая статья, суть которой в двух словах «Oracle гады, все пропало». Публикацию недвусмысленно прокомментировал сам James Gosling:

I'd love to be able to say that this is bullshit, but it's tragically the opposite. Oracle is run by the highest IQ idiots I've ever met. They're torching Oracle, it's customers, and every company they've ever acquired. The one ray of light is that the core Java group has fared much better than EE.

Продолжаем следить за развитием событий.

1.2. BREXIT

Ссылка: http://www.ibtimes.co.uk/brexit-will-london-lose-its-fintech-crown-1567222

Великобритания выходит из ЕС. Фунт ушел в пике, прихватив с собой котировки крупнейших английских банков. То и дело появляются вбросы о начале сокращений в Лондонских офисах международных финансовых корпораций. Может ли это как-то сказаться на российских Java-разработчиках?

Определенное влияние будет. Спойлер из исследования рынка Java-разработки, которое мы начнем выкладывать осенью: только в Санкт-Петербурге оперирует порядка дюжины fintech-компаний, и около сотни аутсорсеров разного масштаба. Ощутимая доля этих компаний имеет завязки на Запад, включая Великобританию. В условиях высокой неопределенности, какие-то проекты будут неминуемо заморожены, урезаны, отменены. Поэтому вполне возможны локальные кадровые перетасовки, которые тем не менее не должны сильно повлиять на общую ситуацию на рынке.

1.3. Анализируем GitHub

Ссылка: https://cloudplatform.googleblog.com/2016/06/GitHub-on-BigQuery-analyze-all-the-open-source-code.html

Ребята из Google залили публичные репозитории GitHub в свой движок BigQuery, и открыли к нему доступ всем желающим. Остается положить какие-то 300$ на счет, и вы легко сможете собирать всевозможную статистику по этому огромному датасету. Например, найти все использования пакета sun.misc :-)



Запросы рекомендуется составлять разумно, потому что 1.5Tb данных в BigQuery очень быстро превращают доллары в тыкву.

2. Почитать

2.1. Java Memory Model

Ссылка 1: http://shipilev.net/blog/2016/close-encounters-of-jmm-kind/
Ссылка 2: https://groups.google.com/d/msg/mechanical-sympathy/T0pNhJSkZWQ/zHDubWKUBwAJ

Модель памяти Java хорошо разжевана в бесчисленных статьях и докладах. Буквально несколько правил, которые надежно скрывают детали реализации JVM и железа. Но разработчики упорно пытаются выйти за границы этой элегантной модели, ошибочно полагая, что они уже достаточно хорошо разобрались в кишочках происходящего. Свербит. Зудит. Чешется. Отсюда растут ноги множества некорректных интерпретаций JMM. Одним не нужен volatile на x86, ибо TSO. Другие пустыми synchronized-блоками happens-before запиливают. Третьи кэши в память «флашают». Бороться с этим сложно, так как под рукой долгое время не было наглядных примеров, демонстрирующих ошибочность таких подходов и утверждений.

Алексей Шипилев проделал титанический труд, и собрал воедино огромное количество наглядных примеров неправильного толкования JMM. Да, прямо такие, где «реордеринги на TSO», и вот это все. Размеру статьи позавидовал бы и Лев Николаевич, но ее прочтение очень важно. В первую с точки зрения веры — после прочтения вы наконец поверите, что заигрывать с JMM не стоит.

Комметнарий Gil Tene по второй ссылке подводит жирную черту под всем вышесказанным.

2.2. Профилирование и AsyncGetCallTrace

Ссылка: http://psy-lob-saw.blogspot.ru/2016/06/the-pros-and-cons-of-agct.html

В последнее время идет много дискуссий вокруг метода AsyncGetCallTrace, который позволяет снять дамп потока, не требуя при этом остановки на safepoint. Например, на его основе построен Honest Profiler. В своем посте Нитсан показывает некоторые слабые стороны этого подхода. Например, невозможность отпрофилировать интринзики.

Думаю, в ближайшее время стандартом первой линии профилирования может стать связка JMC + Honest Profiler, так как они очень неплохо дополняют друга друга.

Вдогонку свежее видео с доклада Нитсана про профилирование:

2.3. Немного про JIT

Ссылка: https://www.infoq.com/articles/OpenJDK-HotSpot-What-the-JIT

Хорошая статья про особенностях работы JIT. Рассматриваются вопросы tiered compilation, деоптимизации, интринзиков, и т.д. Написана лайтово и интересно.

Кстати, есть в JVM одно решение, которое лично мне непонятно — почему code cache отделен от metaspace? Уже не раз натыкался на проблему, когда при активной работе класслоадеров приходится тюнить эти два параметра параллельно. В противном случае просто в какой-то момент отрубается компиляция. Одним metaspace никак нельзя обойтись было? Да и в целом по ощущениям, что metaspace, что code cache на данный момент достаточно слабо встроены в инфраструктуру GC. Например, можно легко получить переполнение code cache, хотя в metaspace болтаются никому ненужные класслоадеры.

2.4. Визуализация GC

Ссылка: http://mattwarren.org/2016/06/20/Visualising-the-dotNET-Garbage-Collector/

Matt Warren визуализировал работу GC в процессе работы приложения. Правда, не в Java, а в .NET :-) Но все равно интересно. Для Java что-нибудь подобное есть? И насколько возможно/удобно в Java получать нотификации о событиях GC?

3. Мудрость

3.1. Идеальный софт

How to write good software: make it correct, fast, then pretty.
How to get adoption: make it pretty, fast, then correct.
Me: (?°?°)?? ???

— deech (@deech) 26 июня 2016 г.

3.2. Протоколы против имплементаций

Distributed systems are about protocols, not implementations. Forget languages, protocols are everything.

— Timothy Perrett (@timperrett) 30 июня 2016 г.

4. Юмор

4.1. Что делать, если вы подняли инвестиции на IT-стартап?

Разумеется, нанять шеф-повара для кормления собак!

*Raise $70M from Twitter*

*Recruit Michelin star restaurant trained chefs to prepare elaborate meals for dogs* pic.twitter.com/5ZMFELzIbg

— Tanay Jaipuria (@tanayj) 30 июня 2016 г.

Честно говоря, смахивает на вирусную рекламу.

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

#4 (06.06.2016 — 19.06.2016)
#3 (23.05.2016 — 05.06.2016)
#2 (09.05.2016 — 22.05.2016)