В этом выпуске
— В битве Google vs Oracle поставлена жирная точка с запятой
— Вброс: checked exceptions не нужны, доказано!
— Учимся писать на ассемблере в Java-коде
… и многое другое
1. Новости
1.1. Oracle vs Google
Как стало известно, федеральный суд Сан-Франциско отказал Oracle в иске к Google о незаконном использовании API Java. Достаточно знаковое событие. Краткая фабула для тех, кто не следил за этой историей:Google: Мы написали свою виртуальную машину с которой можно работать через Java API, который знаком миллионам разработчиков!На самом деле ситуация двоякая. С одной стороны, написание API это тяжелая и неблагодарная работа. Сделать продукт удобным для пользователя удается далеко не сразу. Зачастую это длительный и итеративный процесс. Поэтому требование Oracle уважать этот труд вполне можно понять.
Oracle: Так нельзя, вы нам должны 9,000,000,000$.
Google: Нет, можно!
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]
— Vicky Harp (@vickyharp) 27 мая 2016 г.
Junior dev: "lol dumb user"
Staff dev: "Closed - fixed"
Senior dev: <opens usability bug>
3.2. Про самоуверенность
9 devs' lies
— Mario Fusco (@mariofusco) 1 июня 2016 г.
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
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 в Спринге
Будьте осторожны с именами бинов в Спринге. В противном случае вы рискуете наткнуться на конфликт:Так же к использованию не рекомендовано имя «John Doe». Справедливости ради, «баг» уже исправлен.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 г.
4.2. Когда ломается GitHub
Источник: classicprogrammerpaintings.com/post/144953638470/github-major-service-outage-georges-seurat
Повод задуматься, насколько сильно мы зависим от интернет-сервисов.
4.3. Наглая ложь Microsoft
Among the biggest lies in software:
— Lukas Eder (@lukaseder) 27 мая 2016 г.
"Windows is checking for a solution to the problem"
LOL pic.twitter.com/795QpZyp33
Кто-нибудь знает, что происходит в Windows в этот момент на самом деле?
Комментарии (9)
Viacheslav01
07.06.2016 13:36«Кто-нибудь знает, что происходит в Windows в этот момент на самом деле?» проверяется совместимость софта с версией винды и наличие известных конфликтов.
tbl
07.06.2016 14:36На самом деле вызываются DLL-ки, зарегистрированные с помощью WerRegisterRuntimeExceptionModule. А уж какой они там трэш внутри себя творят — хз.
guai
07.06.2016 17:34Гевин Кинг про checked exceptions: http://ceylon-lang.org/blog/2016/04/05/object-validation/
pronchakov
07.06.2016 18:00+1По поводу checked exceptions двоякие мысли:
С одной стороны, да, видно, что народ их не использует так, как было задумано во многих случаях. Заворачивают в unchecked, просто пропускают, хорошо если еще логи и стектрейсы будут. И вроде бы надо избавиться от этого.
С другой стороны, когда я вижу код, в котором это не спускается на тормозах, где исключения честно обрабатываются, где они не заворачиваются в unchecked, а как минимум, попробовавши какие то локальные действия, и не получивши результата, заворачивают это в другое checked exception и выкидывают дальше, например когда SQLException превращается в хорошо оформленный какой-нибудь самодельный DataAccessException, с указанием на то, что же все таки случилось, вот такой код мне нравится. Его проще читать, поддерживать и дорабатывать.
Причем на небольших проектах этого не заметно. А вот на больших, многоуровневых, модульных — очень даже.
Лично я стараюсь обрабатывать исключения нормально. Согласен, не всегда это в принципе возможно, но где возможно — обрабатываю.
Да, то как это сейчас многими используется — это не хорошо. Но однозначно выпиливать я бы не стал.
sshikov
07.06.2016 21:19Я бы уже стал бы. Уже примерно понятно, чем их можно заменить — это что-то типа монады either, когда ваш метод может возвращать либо результат, либо ошибку. checked exception — это ошибка, прописанная в сигнатуре метода. Хотите ее вернуть — верните явно.
Это не замена 1 в 1, по очевидным причинам — выкинутое исключение можно ловить на много уровней выше. Но это адекватный механизм, проверенный временем. И вы не можете просто игнорировать ошибку, почти также, как исключение — потому что результат успешного выполнения из either нужно еще достать, и если его нет — то это достаточно явно.
Это потребует некоторого пересмотра своих привычек — но как правило, в хорошем направлении. И компонуется такой код намного легче.
Не вобще выпилить — а выпилить из API. Для начала из своего.
lany
Checked exceptions определённо отжили своё. Не взлетела идея. Через дебри лямбд им придётся продираться всё сложнее. Уже в восьмёрке в связи с этим добавили
UncheckedIOException. ОсталосьUncheckedSQLException,UncheckedInterruptedExceptionи т. д. И заживём!Gokudera
>>Оказалось, что в большинстве случаев разработчики их либо игнорируют, либо логируют, либо заворачивают в unchecked.
Миллионы мух не могут ошибаться.
Ну да много кода и что? Вы же не в блокноте свои приложения разрабатываете! checked меньше шансов что исключение будет обработано не корректно. Основная проблема unchecked исключений — документирование, документирование и еще раз документирование. У программистов обычно сложности с соблюдением всех регламентов, особенно в сжатые сроки.
По сути должна быть золотая середина.
Gokudera
PS.
Figure 15: Sample Code illustrating use of Custom Exception picked from Bruce’s blog
Ну не верю я что Брюс Эккель мог написать «высвобождение ресурсов» в try блоке.
Квест что выбрасывает NPE, Refrence.MOD_VERSION — константа
instance == null? ошибка реализации: getCurrentRecomendedBuild() — без комментариев…
Должна была быть статья о том что «checked исключения не нужны», а получилась о «большинство разработчиков не умеют с ними работать»
Им бы подучиться, а потом делать такие громкие заявления…
Gokudera
Вы бы хоть писали с чем не согласны.
Ничего не имею против checked исключений и по сему не понимаю к чему тут холивар? Буду признателен если поделитесь своим видением, с удовольствием пересмотрю свою точку зрения.
В какой момент стало хорошей практикой пустые кэч блоки?