Дайджест цікавих подій з світу Java, і навколо неї #5 (20.06.2016 — 03.07.2016)

image

У цьому випуску
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 :-)

image

Запити рекомендується складати розумно, тому що 1.5 Tb даних в 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. Java Memory ModelПосилання: 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. Що робити, якщо ви підняли інвестиції на ІТ-стартап?Зрозуміло, найняти шеф-кухаря для годування собак!
*Raise $70M from Twitter*

*Recruit Michelin star restaurant trained chefs to prepare розробити 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)
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.