Обзор программы Java-конференции JBreak 2018: абсолютный баланс19.02.2018 18:18

Конференция: JBreak 2018
Суть: Единственная Java‑конференция в Сибири
Дата: 4 марта 2018
Место: Новосибирск, Экспоцентр, Станционная ул., 104

Меньше, чем через 2 недели, состоится JBreak 2018. В этот раз я смог поучаствовать в Программном комитете и могу не просто пересказывать чужие слова, а поделиться впечатлениями.

Это будет очень круто. Этот JBreak обещает быть чуть ли не самым сбалансированным по сочетанию хардкора, практики и смузи. Причём доклады выбраны так, чтобы как можно меньше пересекаться с JPoint (она будет через месяц). Например, Никита Коваль будет и на JBreak, и на JPoint —, но с двумя совершенно разными темами. Это важно, например, для тех, кто хочет побывать на JBreak вживую, а на JPoint — в онлайне.

Доклады очень разноплановые: если вам хочется погрузиться в кромешный ад внутренностей JVM, к нам приедут Крис Талингер и Фолькер Симонис — известные специалисты в этом самом. Если хочется узнать про будущее Java, об этом есть доклад замдиректора Азула, Саймона Риттера (правда, там тоже не всё так просто — придётся погрузиться в кучу JEP’ов, релизную политику, современные тренды развития платформы и так далее). Если же хочется поучаствовать в лёгком, ярком, стремительном шоу с использованием трендовых технологий типа Apache Kafka, Kafka Connect и KSQL — для этого к нам прилетит сооснователь и лидер любимого многими программистами правильного подкаста «Разбор Полётов» (по совместительству является Solution Architect в компании Confluent).

Чтобы не верить мне на слово, под катом будут освещены основные вопросы и приведена полная программа JBreak 2018 с описанием докладов и фоточками спикеров. В самом конце статьи будет ссылка на регистрацию. Поехали!

Вопросы организации

Всё проходит прямо в Новосибирске. Даже если наплевать на стоимость билета на самолет, каждый ли работодатель отпустит на целую неделю в Санкт-Петербург на Joker? Давайте считать: день, чтобы туда прилететь и устроиться в гостинице. Два дня конференции. День, чтобы вернуться назад (4 часа полета + 4 часа разницы часовых поясов — это сразу минус день). Риск, что тебя никуда не отпустят в свете надвигающихся дедлайнов, велик. Но JBreak проходит в Новосибирске, и никуда лететь не нужно.
Это будет выходной день. Многие работодатели считают конференции чепухой и вполне могут не отпустить в рабочий день. Но JBreak пройдет в воскресенье, так что к черту все эти запреты. В субботу можно будет немного отдохнуть от работы, в воскресенье — посетить JBreak и окунуться в него с головой, а в понедельник — приступить к задачам со свежими мыслями и новыми инструментами.
Участникам конференции, конечно же, будут предоставлены видеозаписи всех докладов, причем очень быстро. Если воспринимать конференцию как реальный источник знаний, то безумием было бы надеяться запомнить такое количество полезной информации в один день. К счастью, записи у нас будут.
Стоимость билетов — значительно меньше, чем на JPoint и Joker. Примерно в 3 раза. Конечно, нужно учитывать, что JBreak идет только один день, а JPoint и Joker — два дня.

Вопросы содержания

На JBreak будут не только простые лайтовые доклады, но и мощный хардкор. Такие вещи, которые имеют реальную ценность, дают конкурентное преимущество, заставляют шевелиться извилины, whatever. Нечто такое, чего почти никогда не завозят на редкие новосибирские Java-митапы. Хотите знать, как добавить новые интринсики в JVM? Кушать подано. (Доклад с одного из прошлых JBreak, на этом будут совершенно новые доклады).
Среди спикеров — не только наши соотечественники, но и зарубежные специалисты с мировым именем.
Среди наших соотечественников — сибиряки, с которыми вполне возможно однажды столкнуться на улице. Например, Никита Липский живет в Новосибирске и работает в Excelsior — это те самые чуваки, которые написали свою собственную JVM. Владимир Плизга работает в ЦФТ. Чтобы не казалось, что это тайная масонская новосибирская ложа, есть люди и из других мест: например, Алексей Зиновьев исторически из Омска. Тагир Валеев (lany) на этот раз не делает доклад, но он будет стоять на стенде JetBrains (и он тоже живет в Новосибирске, работает в JetBrains и делает ту самую IDE, на которой ты пишешь свой код).
Программный коммитет JBreak тоже во многом сибирский;
Со всеми спикерами можно будет пообщаться в специальных дискуссионных зонах. Грубо говоря, после доклада каждый (!) спикер направляется в специально отведенное место, где можно продолжительно мучить его сложнейшими вопросами. Про это я напишу чуть ниже с красивой фотографией :-)
JBreak — это не уменьшенная копия JPoint и Joker, а самостоятельная конференция со своими собственными докладами.

Программа

Эксплуатация Hadoop: tips and tricks

Речь пойдет о проблемах и задачах со стороны эксплуатации Hadoop, а также о том, как мы адаптировали Hadoop под инфраструктуру Яндекса. Доклад будет полезен всем, у кого есть Hadoop в продакшне: системным администраторам, DevOps’ам, разработчикам.

Игорь Андреев

Системный администратор в компании Яндекс. Последние 4 года занят развитием и поддержкой кластеров Hadoop.

Side Effect Injection, или Добродетельные костыли

Помните тот случай, когда вы случайно (или нет) отправили на продакшн кусочек кода, предназначенный только для теста? Или временно вставили крохотный if«чик, например, с Thread.sleep () или логированием для отладки? Знайте, вы не одиноки. Есть куча реальных задач, после решения которых на продакшн частенько уезжает тестовый/отладочный код, превращаясь там в бомбу замедленного действия, попутно преумножая тех.долг и пятно на карме разработчика. В докладе мы по косточкам разберем подход Side Effect Injection, который позволит вам внедрять в тестируемое приложение почти любое поведение: задержки, заглушки, логирование, обход безопасности и т.д., но при этом не пачкать репозиторий грязными хаками и даже не пересобирать само приложение. В ходе разбора полюбуемся вариантами компиляции Java-кода, расковыряем один кейс модификации байт-кода в JVM, препарируем формальную грамматику Java, а затем поиграем со всем этим на примере реального приложения.

Владимир Плизга

Владимир со школьной скамьи болеет программированием и с тех пор успел покодировать на всём: от советских программируемых калькуляторов до современных SCADA-систем в производстве. Но последние 6 лет погружен в разработку бэкенда интернет-банков и сопутствующих сервисов в ЦФТ, где активно топит за микросервисы и прочие модные штуки. Попутно постоянно заморачивается идеями оптимизации сложных задач разработки/тестирования серверного ПО, вынашивает для них решения на пробежках и в бассейне, а затем воплощает их в жизнь, бессовестно испытывая на собственных коллегах.

Как генератор тестов помог стабилизировать компилятор в Zing VM

Стабильность и функциональная корректность — это то, чего ждут пользователи Java-машин. А ещё они ждут, что скомпилированный ими код будет работать быстро. Для этого существуют компиляторные оптимизации, но чем агрессивнее они улучшают код, тем больше проблем в них может быть скрыто. Так как же помирить такие противоречивые цели, как скорость и корректность скомпилированного кода? Особенно если ваш компилятор основан на LLVM, и в него вливаются десятки тысяч строк изменений каждую неделю? Как находить скрытые баги у себя дома до того, как пользователь наткнётся на один из них? В этом докладе мы расскажем, как мы ищем функциональные проблемы в компиляторе Java-машины Zing, используя автоматический генератор тестовых программ на языке Java.

Максим Казанцев

Инженер компиляторов в Azul Systems. Последние 4 года занимается оптимизирующими JIT-компиляторами для виртуальных машин. С 2017 года работает над Zing VM, активно коммитит в LLVM. До этого работал над виртуальными машинами ART и Dalvik в компании Intel, внёс свой вклад в Android Open Source Project.

На пути к быстрой многопоточной хеш-таблице

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

Никита Коваль

Никита — инженер-исследователь в исследовательской группе dxLab компании Devexperts. Помимо этого, он студент кафедры Компьютерных Технологий в ИТМО, где к тому же преподает курс по многопоточному программированию. Главным образом интересуется многопоточными алгоритмами, верификацией программ и их анализом.

Spring Boot Starter — как и зачем?

Spring — уже не магия (спасибо «Spring-потрошителю» и Евгению Борисову), а вот Spring Boot довольно часто клеймят магической поделкой. Но многим нравится, особенно новичкам! В докладе мы осветим следующее: Доклад рассчитан на практикующих Spring (а лучше Spring Boot) инженеров, которые уже сталкивались с различными трудностями поддержки увесистой инфраструктуры, разрабатываемой с использованием Spring.

Максим Гореликов

Разработчик из Альфа-Лаборатории, занимается разработкой API для мобильных приложений и немного слоем безопасности. В основном использует экосистему Spring и Netflix, но пробует всё, что найдет хорошего на GitHub. Экспериментирует с реактивными подходами, несколько экспериментов успешно дожили до продакшна. Хочет понимать не только свои приложения, но и всё, что вокруг них, поэтому работает со всей инфраструктурой (логи, CI/CD, оркестрация). В общем, DevOps — наше всё.

Кирилл Толкачев

Разработчик в Альфа-Лаборатории. Разрабатывает различные банковские API. Формирует принципы и наборы инструментов для работы с микросервисной архитектурой. Большой поклонник Groovy, Gradle, Spring и стека технологий Netflix. Постоянный резидент подкаста «Разбор Полётов». Методологию DevOps знает не понаслышке и имеет почти двухлетний опыт её применения.

Смузи ML вместе со Spark MLlib

В направлении BigData требуются не только data scientist-ы, тюнящие параметры моделей из пакетов на R/Python, но и джависты, которые способны понять построенные модели, воплотив их на Java/Scala, в том числе при помощи Spark MLlib. Давайте начнем знакомство с этой самой мощной библиотекой распределенного машинного обучения, заодно обсудив особенности использования стандартных алгоритмов машинного обучения и структур данных в Spark.

Алексей Зиновьев

Харон (в греческой мифологии — перевозчик душ умерших через реку Стикс) из Java в Big Data. Если говорить проще, то практикующий тренер в компании EPAM Systems. С Hadoop/Spark и прочей бигдатой дружит с 2012 года, форкается и пуллреквестит с 2014, рассказывает с 2015. Особенно любит текстовые данные и большие графы.

Graal: how to use the new JVM JIT compiler in real life

JEP 317 (Experimental Java-Based JIT Compiler) приближает момент, когда Graal начнёт использоваться повсеместно. На самом деле, Graal уже имеется в JDK 9, в соответствии с JEP 243 (Java-Level JVM Compiler Interface). Graal сам по себе написан на Java, что добавляет новые свойства и особенности, которых ранее не было в HotSpot. В этом докладе мы увидим, как использовать Graal вместе с JDK 9, как собирать Graal из апстрима и на что стоит смотреть при его использовании в бенчмарках или, может быть, даже в продакшне.

Кристиан Талингер

Крис Талингер — разработчик, работающий над различными JVM более 13 лет. Является экспертом в компиляторах, в особенности — в JIT-компиляторах. Изначально участвовал в проектах CACAO и GNU Classpath, но как только Sun Microsystems отдала JDK в open source, сфокусировался на OpenJDK. С тех пор Крис работал над HotSpot в Sun, Oracle и сейчас продолжает заниматься этим в Twitter.

Строим криптотрейдинг-платформу, используя Spring 5 и Reactor 3

В докладе подробно рассмотрим Reactive-подходы со Spring 5 и Reactor 3 и покажем, как построить/перенести Reactive System на новый Reactive Stack. Расскажем об общих потребностях бизнеса, где эти техники работают лучше всего и помогают решить сложные задачи наиболее эффективно. Во время доклада мы построим криптотрейдинг-платформу. Сначала мы проанализируем дизайн стандартного приложения, его плюсы и недостатки. Затем оптимизируем существующую архитектуру и построим реактивное решение, используя стек современных технологий Spring 5 и Reactor 3.

Олег Докука

Инженер ПО, уже более 7 лет занимается разработкой ПО в различных областях. В последнее время активно разрабатывает корпоративное ПО и распределённые системы, в основном используя стек Spring. С самого начала разработки Spring 5 внимательно следит за развитием фреймворка и активно продвигает Reactive-решения, основанные на Spring 5 и Reactor 3, публике. Кроме того, Олег — коммитер Reactor 3, а также спикер таких конференций, как JEEConf и JavaDay Ukraine. В свободное время пишет книгу «Reactive Programming with Spring 5».

ML Pipelines в Одноклассниках

В рамках доклада мы рассмотрим основную архитектуру библиотеки машинного обучения Spark ML, а также особенности её использования для решения реальных задач с обработкой больших объёмов данных. Особое внимание уделим ряду ограничений, усложняющих применение библиотеки, и расскажем о том, какие расширения для стандартных элементов пришлось разработать, чтобы эти ограничения обойти и полноценно раскрыть потенциал массивного распределённого машинного обучения. Работу стандартной библиотеки и её расширений продемонстрируем на примере задачи ранжирования новостной ленты в социальной сети Одноклассники. Доклад будет полезен разработчикам, инженерам данных и аналитикам, использующим методы машинного обучения и платформы распределенной обработки информации.

Дмитрий Бугайченко

Закончил Санкт-Петербургский Государственный Университет в 2004 году, там же защитил кандидатскую по формально-логическим методам в 2007. Почти 9 лет проработал в аутсорсинге, не теряя контакта с университетом и научной средой. Анализ больших данных в Одноклассниках стал для Дмитрия уникальным шансом совместить теоретическую подготовку и научный фундамент с разработкой реальных, востребованных продуктов. И этим шансом он с радостью воспользовался, придя туда пять лет назад.

Class data sharing in the HotSpot VM

Class Data Sharing (CDS) — фича, появившаяся в Java 5 и предназначенная для улучшения скорости загрузки и уменьшения количества используемой оперативной памяти Java-приложения, которая осуществляется путем хранения предварительно обработанной метаинформации о системных классах на диске, с возможностью использовать эти данные в нескольких JVM одновременно. В течение последних лет CDS постоянно улучшалась. В OpenJDK 10 эта функциональность будет расширена с помощью AppCDS — фичи, которая позволяет пользоваться классами приложения нескольким экземплярам VM одновременно. Подробней можно прочитать в JEP 310 («Application Class-Data Sharing»). В этом докладе Фолькер кратко расскажет про CDS и AppCDS, покажет, как их можно использовать. Несмотря на то, что CDS весьма хорошо документирована, AppCDS для классов приложения и самописных класслоадеров требует большого количества ручной работы, поэтому Фолькер собирается продемонстрировать нам небольшую утилиту, позволяющую автоматизировать эти задачи. После демонстрации конкретных цифр (сколько используется оперативной памяти, какое быстродействие), Фолькер покажет нам глубинные детали реализации и расскажет о возникающих проблемах. И наконец, мы обзорно пройдёмся по вопросам вроде хранения строк и символов в архиве CDS, и как их можно раскидывать по нескольким виртуальным машинам, начиная с OpenJDK 9. В результате аудитория получит более глубокое понимание CDS/AppCDS и сможет понять, стоит ли использовать эту технологию для своих приложений.

Фолькер Симонис

Фолькер Симонис работает в SAP JVM Technology group. Он был одним из первых контрибуторов в OpenJDK, помогая SAP участвовать в этом проекте. Он — лидер проекта OpenJDK PowerPC/AIX и проекта по портированию на s390x, а также является ревьюером в JDK и представителем SAP в JCP Executive Committee. Кроме того, он член экспертных групп JCP JSR 379 (Java SE 9), JSR 383 (Java SE 10) и JSR 384 (Java SE 11).

Это кто там такой твитит про #jbreak?

Что может быть интересней, чем построение систем конвейерной обработки данных (data pipelines)? Давайте разберём поток твитов прямо здесь, используя модные технологии — Apache Kafka, Kafka Connect и KSQL! Мы же все знаем и любим SQL, правда? Так вот, KSQL — это почти как SQL, только для Kafka. KSQL позволяет создавать сложные системы обработки потоковых данных, без написания Java или Scala (sick!) кода! Но самое интересное начнется тогда, когда в режиме реального времени, с помощью KSQL, мы будем обрабатывать ленту твитов и разберемся, кто больше всех твитит на конференции!

Виктор Гамов

Виктор Гамов — сооснователь и лидер любимого многими программистами правильного подкаста «Разбор Полётов». По совместительству является Solution Architect в компании Confluent, которая разрабатывает платформу на базе Apache Kafka. Помогает клиентам в проектировании и разработке распределенных систем обработки потоковых данных. Соавтор книги «Enterprise Web Development» издательства O’Reilly. В свободное от работы время Виктор не забывает про качалку и бицуху. Является завсегдатаем конференций JUG.ru Group (JPoint, Joker, JBreak) и других международных конференций (JavaOne, Devoxx, OSCON, Qcon). Пишет в Twitter как gamussa. Ведет канал про Kafka в Telegram https://t.me/AwesomeKafka_ru.

Clustered event sourcing and CQRS with Akka and Java

Декомпозиция монолитных систем на микросервисы приводит не только к разделению монолитного кода, но также включает в себя ликвидацию монолитных данных. Поэтому построение систем, собранных из слабосвязанных микросервисов, требует новых стратегий как в отношении написания кода, так и в дизайне данных. Одна из часто используемых альтернативных стратегий — Event Sourcing & CQRS (Command Query Responsibility Segregation). В этом докладе мы сможем подробней познакомиться с мотивацией, лежащей за построением таких систем, и с архитектурой ES & CQRS. Мы погрузимся в специальную демонстрационную реализацию ES & CQRS, написанную целиком на Akka и Java. Akka — это тулкит, который предоставляет акторную реализацию Event Sourcing & CQRS, что по сути означает, что такие решения можно запускать на распределённых кластерах. Мы познакомимся Akka Persistence и узнаем, каким образом при этом используются другие возможности Akka, такие как кластерные синглтоны и кластерный шардинг.

Hugh McKee

Hugh McKee работает на должности developer advocate в Lightbend. Он долгое время работал над созданием приложений, которые развивались слишком медленно, неэффективно использовали инфраструктуру, были хрупкими и легко ломались. Всё это изменилось, когда он начал делать реактивные, асинхронные системы с использованием акторов. Этот радикально новый подход изменил его жизнь. В качестве дополнительного бонуса делать такие системы куда веселее. Сейчас он занимается тем, что помогает другим разработчикам открывать для себя невероятные возможности, которые приходят с переходом на новый набор принципов: responsive, resilient, elastic, message-driven и т.п.

JDK 9, Mission Accomplished: What next for Java?

JDK 9, включая Java Platform Module System (JPMS), наконец-то дошла до полноценного релиза. Этот доклад начнется с быстрого вступления, заключающегося в перечислении нововведений JDK 9 — того, как это поможет Java-разработчикам и какую работу нам подкинет. Oracle сделала несколько важных заявлений, касающихся будущего JDK вообще и Java EE в частности. Мы взглянем на предлагаемые изменения в скорости выпуска релизов, схеме наименования релизов, на бинарники с использованием лицензии GPL. Будет рассказываться о модели LTS-релизов и о том, как она скажется на разработчиках и администраторах. И наконец, мы посмотрим на будущее Java-платформы в целом. Существует множество JEP’ов и проектов OpenJDK, таких как Valhalla, Amber, Metrololis и Loom — в докладе также будет объясняться, что всё это значит для разработчиков.

Саймон Риттер

Саймон работает заместителем генерального директора в Azul Systems. Он начал заниматься информационными технологиями ещё в 1984 году, получив степень бакалавра физики в Университете Брунеля, в Англии. В 1996 году Саймон присоединился к Sun Microsystems и начал работу над Java версии 1.0. Время он тратил как на разработку непосредственно кода, так и на консультирование. После покупки Sun он перешёл в Oracle и занялся управлением командой Java-евангелистов, занимавшейся технологиями ядра Java, Java для клиентских приложений и Java для встроенных систем. Сейчас, работая в Azul, он продолжает помогать людям лучше разбираться не только в Java как таковой, но ещё и в технологиях и продуктах Azul. Саймон дважды был награждён статусом Java Rockstar на конференции Java One, и один раз — титулом Java Champion. Сейчас он представляет Azul в исполнительном комитете JCP и на экспертных группах Java SE (JSR 379 и JSR 383).

Create effective tests or create excuses — testing the Java EE way

Тестирование — это всё ещё та тему, которую старательно избегает большинство разработчиков. Несмотря на то, что тестирование очень важно для получения действительно хорошо работающего софта, разработка и поддержка тестов занимает огромное количество времени и усилий — особенно когда изменения в существующей функциональности заставляют изменяться сценарии тестирования. Можно было бы просто выбросить тесты, но это очень плохое решение. Отсюда возникает вопрос — как же мы тогда сможем писать энтерпрайзные тесты эффективно и продуктивно? Этот доклад призван показать, что необходимо для тестирования Java EE приложений — эффективно, прагматично, и конечно, автоматизированно. В докладе рассматриваются такие вопросы как получение быстрой обратной связи, достаточный объём покрытия, предсказуемая скорость разработки. Всё время будет потрачено на лайвкодинг тест-кейсов, которые будут покрывать различные спектры функциональности и использовать различные технологии. Мы увидим, как контейнеры и фреймворки для оркестрации могут реально помогать в тестировании сложных и объемных приложений. В частности, мы отчётливо увидим, как разрабатывать хорошо поддерживаемый код тестов, так, чтобы он продолжал оставаться высококачественным и мастерски написанным.

Sebastian Daschner

Sebastian Daschner — консультант в области Java-технологий, автор книг и статей, тренер по различным направлениям разработки, активно занимающийся программированием и Java (EE). Он является автором книги «Architecting Modern Java EE Applications». Себастиан участвует в JCP, и занимается там разработкой будущих версий стандартов Java EE, участвуя в работе экспертных групп JAX-RS, JSON-P и Config, взаимодействуя с различными open source проектами. За вклад в сообщество и экосистему Java, он получил титулы Java Champion, Oracle Developer Champion и JavaOne Rockstar. Кроме Java, Себастиан очень любит Linux и технологии контейнеризации типа Docker. Он проповедует практики Computer Science в блоге https://blog.sebastian-daschner.com, в собственной рассылке и на твиттере @DaschnerS. Когда он не занят Java, он путешествует по миру — не только на самолёте, но еще и на мотоцикле.

Реактивное программирование на Vert.x

Надоело отлаживать критическую секцию в сто первый раз? Хочется писать полезный код, а не решать проблему с гонками потоков? Может, стоит попробовать что-то новое? Vert.x совершенно не похож на старый добрый Spring и Java EE. В этом его сила, это таит сложности. Легко написать код, который тяжело поддерживать. С другой стороны, имея опыт, Vert.x превращается в удобный инструмент разработки. А как после этого запускать приложение на Vert.x в промышленной среде? Доклад будет полезен тем, кто хотел бы начать использовать Vert.x, но не знает, с какой стороны подойти.

Антон Ленок

Инженер-программист в Сбербанк-Технологии. Разрабатывает серверную часть для Сбербанк Онлайн. В своих проектах внедряет решения, делающие жизнь инженеров веселее: ELK, Docker, Kubernetes, реактивное программирование и т.д.

Эксплуатация IMDG со стороны Dev и Ops

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

Алексей Шарапов

Алексей несёт DevOps-культуру в мир Java-программистов компании Сбербанк-Технологии. Занимаясь сборкой и инфраструктурой, он старается сделать мир лучше, а работу девелоперов — проще. Сбербанк-Технологии стал для Алексея уникальным шансом быть одним из первооткрывателей в рамках перехода к гибким методологиям разработки в такой негибкой сфере, как банковская. В рамках этого перехода Алексею удалось максимально близко пощупать весь стек in-memory data grid-решений, о чем, собственно, он и хочет рассказать.

Верификация Java-байткода: когда, как, а может отключить?

Сегодня Java-разработчики всё чаще используют библиотеки для порождения Java-байткода в рантайме для эффективной реализации различных трюков, которые сложно или невозможно выразить на языке Javа. Но если используя язык Java, компилятор javac гарантирует, что на выходе получится корректный Java-байткод, то спускаясь на уровень непосредственно байткода, вам нужно часто самостоятельно следить за его корректностью. Иначе вы будете получать j.l.VerifyError при загрузке порождённых вами классов, потому что JVM строго следит за корректностью байткода, который она загружает, посредством верификатора Java-байткода. Таким образом, порождая байткод, вам часто недостаточно просто знать семантику байткодных инструкций, вам также нужно знать, как работает Java bytecode-верификатор, какой байткод он считает корректным, а какой — нет. В этом докладе мы разберёмся, какую миссию в JVM несёт верификатор байткода, когда и как он работает, может ли повлиять на производительность вашего приложения и почему опасно его отключать.

Никита Липский

Один из инициаторов и руководителей проекта Excelsior JET, сертифицированной реализации Java SE, разрабатываемой компанией Excelsior. Работая над проектом с 1997 года, поучаствовал в исследовании и разработке практически всех компонентов продукта от ядра до продуктовых свойств. В частности, является одним из авторов поддержки OSGI на уровне JVM в Excelsior JET, технологии Java Runtime Slim Down (модуляризация Java SE, реализованная в Excelsior JET с 2007 года), обоих верификаторов Java-байткода в Excelsior JET и многого другого.

Балансируем клиентские запросы вместе со Spring Cloud

В распределённых системах с динамической конфигурацией существует проблема корректного обнаружения работающих экземпляров сервисов и балансировки запросов между ними. Основной вопрос даже же не в том, какой экземпляр может быть вызван в принципе, а в том, какой инстанс лучше подходит для вызова в определенный момент времени, что требует умной балансировки в условиях постоянно меняющейся конфигурации системы. В докладе Александр разберет типовое решение проблемы в режиме Live Demo на базе проекта Spring Cloud, который содержит готовые реализации основных паттернов для разработки распределенных приложений. По ходу демо будет рассмотрена внутренняя реализация клиентской балансировки запросов с примерами из официальных библиотек и собственной библиотеки автора.

Александр Тарасов

Инженер-программист из Одноклассников. За плечами Александра — более 11 лет разработки, в основном на Java, более трех лет практики внедрения различного рода автоматизации. Имеет несколько open source-проектов, связанных со Spring Cloud на GitHub, ведет собственный блог, пишет статьи на Хабрахабр и DZone.

Заключение

Как видите, программа получилась просто отменная. Если захотите прийти на конференцию, то билеты можно приобрести по этой ссылке. Встретимся на JBreak 2018!