В этом выпуске
— В битве Google vs Oracle поставлена жирная точка с запятой
— Вброс: checked exceptions не нужны, доказано!
— Учимся писать на ассемблере в Java-коде
… и многое другое
1. Новости
1.1. Oracle vs Google
Как стало известно, федеральный суд Сан-Франциско отказал Oracle в иске к Google о незаконном использовании API Java. Достаточно знаковое событие. Краткая фабула для тех, кто не следил за этой историей:
Google: Мы написали свою виртуальную машину с которой можно работать через Java API, который знаком миллионам разработчиков!
Oracle: Так нельзя, вы нам должны 9,000,000,000$.
Google: Нет, можно!
Oracle: Нет, нельзя!
На самом деле ситуация двоякая. С одной стороны, написание API это тяжелая и неблагодарная работа. Сделать продукт удобным для пользователя удается далеко не сразу. Зачастую это длительный и итеративный процесс. Поэтому требование Oracle уважать этот труд вполне можно понять.
С другой стороны, победа Oracle создала бы опасный прецедент, когда можно накидать огромное количество API, запатентовать их, и начать троллить технологические компании. Своим решением суд показал, что публичный API можно использовать без каких-либо лицензионных ограничений, что безусловно является плюсом для IT-индустрии в целом.
Probably the best possible Gv.O outcome. Uncopyrightable APIs would de-fang copyleft licenses, and fair use helps a competitive marketplace.
— cpurdy (@cpurdy) 27 мая 2016 г.
1.2. Checked exception? Нет, не слышал
И кстати про API. Социальные сети активно репостят занятное исследование. Парни из University of Waterloo собрали статистику обработки checked exceptions в Java. Оказалось, что в большинстве случаев разработчики их либо игнорируют, либо логируют, либо заворачивают в unchecked. Вот так неожиданность!
Источник: plg.uwaterloo.ca/~migod/846/current/projects/09-NakshatriHegdeThandra-report.pdf
На ситуацию, когда пользователи массово некорректно используют API, можно посмотреть с двух сторон. Можно сказать: «Пользователи не те!». А можно: «API не тот!». В данном случае я склонен поддержать второй вариант. Люди правильно отмечают — сheck exceptions не справились со своей задачей. Их главное преимущество — определение на уровне сигнатуры метода — является их же главным недостатком. Мы не хотим, что бы какой-нибудь SQLException размазывался по всем компонентам приложения. Вместо этого мы изолируем его на уровне работы с данными. Чаще всего просто заворачивая в unchecked исключение. Отказ от checked исключений давно прослеживается по многим популярным фреймворкам. Возможно, пришло время посмотреть правде в глаза, и деприкейтнуть checked exceptions. Что думаете?
1.3. Twitter открыл очередной фреймворк со странным названием
Heron. Просто Heron. Не больше, и не меньше. Это фреймворк для stream processing. Позиционируется как замена Apache Storm. Любопытна история его создания — этот тот самый случай, когда парни сказали «А давайте перепишем все с нуля!», и переписали. Нам тоже периодически хочется выкинуть все, и создать заново. Но ввиду ограниченности ресурсов, эта идея практически всегда оказывается бесперспективной. Но у Twitter ресурсов много, поэтому им можно. Как говорится, «что позволено Юпитеру ...».
2. Почитать
2.1. Переходим на Java 9
Ссылка: https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach
Это список главных новшеств в Java 9. Его полезно иметь ввиду, что бы понимать, какая часть вашего приложения сломается при переходе на новую версию.
2.2. Простыми словами о JIT
Ссылка: https://advancedweb.hu/2016/05/27/jvm_jit_optimization_techniques/
Хорошее введение в работу JIT в Java. Инлайнинг, dead code elimination, «биоморфы», и т.д…
2.3. Пишем ассемблерные вставки в Java
Ссылка: http://serce.me/posts/01-06-2016-wild-panama/
Все же уже слышали про Project Panama? Автор статьи потрогал руками новую фичу — вставку ассемблера напрямую в Java-код. Теперь мы не боимся выпиливания sun.misc.Unsafe :-)
2.4. QA процесс в Plumbr
Ссылка: https://plumbr.eu/blog/programming/how-it-is-made-plumbr-edition
Тестирование продукта под разные платформы и окружения — не самая легкая задача. В статье инженеры Plumbr рассказывают, как они выстраивали процесс тестирования своего продукта без выделенного QA отдела.
3. Мудрость
3.1. Про Junior-ов и Senior-ов
[User requests feature already in product]
Junior dev: "lol dumb user"
Staff dev: "Closed - fixed"
Senior dev: <opens usability bug>— Vicky Harp (@vickyharp) 27 мая 2016 г.
3.2. Про самоуверенность
9 devs' lies
1 Tested
2 Fixed
3 Not a bug
4 Thread-safe
5 Done in 2 days
6 User's fault
7 It scales
8 Self-documenting
9 I got requirements— Mario Fusco (@mariofusco) 1 июня 2016 г.
3.3. Падающего подтолкни
We've taken strong steps to prevent further break-ins. Our buildings now have doors and an option to use locks. pic.twitter.com/1NP6EjFtU2
— Jevgeni Kabanov (@ekabanov) 25 мая 2016 г.
3.4. Двоякая мысль про алгоритмы
A periodic reminder that remembering the details of specific named algorithms is 0% correlated with being an actually good developer.
— Laurie Voss (@seldo) 25 мая 2016 г.
4. Юмор
4.1. Foo в Спринге
Будьте осторожны с именами бинов в Спринге. В противном случае вы рискуете наткнуться на конфликт:
Spent some time figuring out why my Spring bean “foo” wasn’t resolving properly. Found Spring Data already has one! pic.twitter.com/gJTuhGaigb
— Dan Woods (@danveloper) 23 мая 2016 г.
Так же к использованию не рекомендовано имя «John Doe». Справедливости ради, «баг» уже исправлен.
4.2. Когда ломается GitHub
Источник: classicprogrammerpaintings.com/post/144953638470/github-major-service-outage-georges-seurat
Повод задуматься, насколько сильно мы зависим от интернет-сервисов.
4.3. Наглая ложь Microsoft
Among the biggest lies in software:
"Windows is checking for a solution to the problem"
LOL pic.twitter.com/795QpZyp33— Lukas Eder (@lukaseder) 27 мая 2016 г.
Кто-нибудь знает, что происходит в Windows в этот момент на самом деле?
Автор: devozerov
