Java *

Многие с подозрением относятся к перспективе чего-нибудь форкнуть и дописать самостоятельно. Зачастую цена слишком высока. Особенно странно слышать о собственных JDK, которые якобы есть в каждой достаточно крупной компании. Что за чертовщина, с жиру бесятся? В этой статье будет подробный рассказ о компании, которой всё это приносит реальную коммерческую выгоду, и которая проделала чудовищную работу, ведь они:

• Разработали мультитенантную виртуальную Java-машину;
• Придумали механизм работы объектов, не приносящих оверхеда на сборку мусора;
• Сделали что-то вроде аналога ReadyNow из Azul Zing;
• Запилили собственные корутины с yield-ами и континуациями (и даже готовы поделиться опытом с Loom, о котором я писал осенью);
• Прикрутили ко всем этим чудесам собственную подсистему диагностики.

Как всегда, видео, полная текстовая расшифровка и слайды ждут вас под катом. Добро пожаловать в ад одного из самых сложных направлений адаптации открытых проектов!

Доктор, откуда вы берёте такие картинки? Уголок «обложек O'Reilly»: бэкграунд для КДПВ предоставлен Joshua Newton и изображает священный танец Сангьянг Джаран в городе Убуде, Индонезия. Это классический балийский перформанс, состоящий из огня и трансового танца. Человек с непокрытыми пятками двигается вокруг костра, разведённого на кокосовой шелухе, распихивая ногами разное и танцуя в трансовом состоянии под действием конского духа. Идеальная иллюстрация для собственного JDK, правда?

Существует популярное заблуждение о том, что если не нравится garbage collection, то надо писать не на Java, а на C/C++. Последние три года я занимался написанием low latency кода на Java для торговли валютой, и мне приходилось всячески избегать создания лишних объектов. В итоге я сформулировал для себя несколько простых правил, как свести аллокации в Java если не до нуля, то до некого разумного минимума, не прибегая к ручному управлению памятью. Возможно, кому-то из сообщества это тоже будет полезно.

TL;DR: GitHub://PastorGL/AQLSelectEx.

Однажды, ещё не в студёную, но уже зимнюю пору, а конкретно пару месяцев назад, для проекта, над которым я работаю (нечто Geospatial на основе Big Data), потребовалось быстрое NoSQL / Key-Value хранилище.

Терабайты исходников мы вполне успешно прожёвываем при помощи Apache Spark, но схлопнутый до смешного объёма (всего лишь миллионы записей) конечный результат расчётов надо где-то хранить. И очень желательно хранить таким образом, чтобы его можно было по ассоциированным с каждой строкой результата (это одна цифра) метаданным (а вот их довольно много) быстро найти и отдать наружу.

Давным-давно в одной далёкой-далёкой... проекте, понадобилось мне сделать обработку http-запросов на Netty. К сожалению, стандартных удобных механизмов для маппинга http-запросов в Netty не нашлось (да и этот фреймвёрк совсем не для того), поэтому, было решено реализовать собственный механизм.

В данной статье я расскажу вам о том, каким образом можно построить граф маршрутов для приложений с Apache Camel, отслеживать состояния этих маршрутов и собирать для них метрики.
Мы используем Apache Camel в spring приложениях и в Apache ServiceMix. И если маршруты в отдельном сервисе — это штука понятная и легко обозримая, то в рамках шины данных, где таких маршрутов много, не все так просто.

Обзор фреймврока Axonframework

Spock предоставляет 3 мощных (но разных по сути) инструмента, упрощающих написание тестов: Mock, Stub и Spy.

Довольно часто коду, который нужно протестировать, требуется взаимодействовать с внешними модулями, называющимися зависимостями (в оригинальной статье используется термин collaborators, который не очень распространён в русскоязычной среде).

Модульные тесты чаще всего разрабатываются для тестирования одного изолированного класса при помощи различных вариантов моков: Mock, Stub и Spy. Так тесты будут надёжнее и будут реже ломаться по мере того, как код зависимостей эволюционирует.

Такие изолированные тесты менее подвержены проблемам при изменении внутренних деталей реализации зависимостей.

От переводчика: каждый раз, когда я использую Spock Framework для написания тестов, я чувствую, что могу ошибиться при выборе способа подмены зависимостей. В этой статье есть максимально краткая шпаргалка по выбору механизма для создания моков.

Аннотация

1. Spring Repository
2. Методы запросов из имени метода
3. Конфигурация и настройка
4. Специальная обработка параметров
5. Пользовательские реализации для репозитория
6. Пользовательский Базовый Репозиторий
7. Методы запросов — Query

Из-за громоздкой конфигурации зависимостей настройка Spring для корпоративных приложений превратилась в весьма утомительное и подверженное ошибкам занятие. Особенно это относится к приложениям, которые используют также несколько сторонних библиотек

Каждый раз, создавая очередное корпоративное Java-приложение на основе Spring, вам необходимо повторять одни и те же рутинные шаги по его настройке:

• В зависимости от типа создаваемого приложения (Spring MVC, Spring JDBC, Spring ORM и т.д.) импортировать необходимые Spring-модули
• Импортировать библиотеку web-контейнеров (в случае web-приложений)
• Импортировать необходимые сторонние библиотеки (например, Hibernate, Jackson), при этом вы должны искать версии, совместимые с указанной версией Spring
• Конфигурировать компоненты DAO, такие, как: источники данных, управление транзакциями и т.д.
• Конфигурировать компоненты web-слоя, такие, как: диспетчер ресурсов, view resolver
• Определить класс, который загрузит все необходимые конфигурации