JavaOne 2013
23 и 24 апреля в Москве проходила конференция JavaOne, которую я посетил. И хотя не в моей привычке что-либо писать в блог, я всё же решил, что будет уместнее опубликовать эту запись один раз, чтобы при необходимости хвастаться достаточно было кинуть ссылку.
Кстати, никаких вводных слов и впечатлений об организации мероприятия я писать не собираюсь - мне просто не о чем сказать.
Итак, на keynote я не попал. Попал на первую серию докладов, из которой я выбрал "Файберы. Лёгкие потоки на Java" Сергей Загурского из mail.ru. Хотелось так же посетить "Борьба с паузами GC", но я всё же выбрал доклад про файберы в силу того, что посчитал эту тему сильно похожей на то, что я делаю. И я не ошибся. Дело в том, что для описания бизнес-процессов в одном проекте, над которым я работаю, я решил использовать javaflow, чтобы иметь возможность приостановить workflow, пока он ожидает реакции от пользователя. Собственно, про что-то подобное javaflow я и ожидал услышать, так оно и вышло.
Сергей Загурский руководит командой, работающей на серверной логикой SkyForge. Там одной стороны приходится обрабатывать большое количество различных объектов, а с другой стороны, нужно обеспечить взаимодействие между объёктом и какими-то внутренними сервисами. Делать всё в async-стиле, понятное дело, не хотелось, а вот RPC приводит к порождению кучи потоков со всеми вытекающими последствиями. В общем, они взяли те же continuations и использовали их, чтобы организовать легковесные потоки, aka fiber'ы. Оказалось, что javaflow они не используют (но знают про него), а написали свою библиотеку. Как сказал Сергей, помимо того, что разработка javaflow идёт достаточно медленно, библиотека ещё и медленно работает. Но вообще, это не совсем так. Просто javaflow достаточно медленно сохраняет и восстанавливает состояние, а в штатном режиме накладных расходов практически нет. Механизм из проекта SkyForge, наоборот, даёт заметные накладные расходы при исполнении, но на сохранение/восстановление почти ничего не затрачивает. Полагаю, в их случае это более оправданное поведение, т.к. нужно постоянно посылать RPC-запросы, а вот в моём случае время сохранения не так уж важно, потому что не так уж часто за время своего исполнения workflow что-то спрашивает у пользователя. К тому же, состояние workflow с достаточно большой вероятностью будет сериализовано и попадёт в БД.
Второй доклад назывался "Тестирование с использованием инструментирования байт-кода". Автор - Владислав Пономарёв из IBM - рассказал о том, что в процессе тестирования бывает нужно от некоторой используемой библиотеки получить определённое поведение, но это поведение достаточно сложно вызвать. Такое может быть в силу ряда причин - очень сложная логика вызываемого метода, сложно вызываемые исключения (например, java.lang.OutOfMemoryError). Для того, чтобы нужное поведение воспроизвести, Владислав предлагал изменить байт-код вызываемого метода так, чтобы он вёл себя так, как нужно. Для изменения предлагалось использовать java.lang.instrument и ASM. Про них я ничего нового не узнал, так что практическая часть доклада была мне не интересна. Разумеется, сразу же возник вопрос - а почему бы не вызывать библиотечный код через интерфейс, а в тесте не написать stub или mock? Докладчик сказал, что иногда такое бывает в legacy-коде или при необходимости использовать библиотеки с кривым дизайном. Ну что же, я ему верю, но это крайне редкая ситуация, так что доклад был не очень полезен с практической стороны, но был интересен в плане "о, ещё и так можно сделать".
Потом последовал доклад Владимира Иванова (Oracle) "Invokedynamic: роскошь или необходимость". Владимир работает над JIT-компилятором в HotSpot. Из его доклада я плохо понял, что такое Invokedynamic. Он пошёл таким галопом по Европам, что человеку неподготовленному было сложно что-либо понять, а подготовленный и так знает, что такое Invokedynamic. Уже потом я почитал про ID в Интернете и для себя составил следующую картину. Когда инструкция invokedynamic выполняется в первый раз, JVM выполняет некоторый (зависящий, как я понял, от той страшной записи в constant pool'е) boostrap-метод. Bootstrap-метод - это обычный java-метод, который принимает на вход CallSite (последний, разумеется, формируется JVM) и генерирует MethodHandler, и invokedynamic преобразуется в вызов этого самого MethodHandler'а (разумеется, байт-код никто не меняет, все преобразования идут где-то на уровне JIT).
Четвёртый доклад, под названием "JDK8: Я, лямбда", читал Сергей Куксенко из Oracle. Читал его он в популярной форме, с шутками, чтобы даже самые маленькие поняли всё про лямбду. Чего-то существенно нового я не узнал, что такое лямбда и какой она будет в Java, я уже был в курсе. Прояснились лишь кое-какие детали. Но главное, что удалось почерпнуть из доклада, - это реализация лямбд. Оказывается, есть спецификация на эту тему, и она утверждает, что лямбду необходимо компилировать в метод в том же классе, а оборачивать в объект - с помощью некоторой мифической lambda factory, природа которой может быль любой. В частности, пока речь идёт о сгенерированном анонимном классе, но в будущем ничто не должно препятствовать переходу на invokedynamic.
Последним посещённым в первый день докладом был "Building Modular Enterprise Applications in the Cloud Age" неких Berk Ertman и Paul Bakker. Честно говоря, зря я пошёл на этот доклад, потому что в итоге не понял, что до меня хотели донести. Возможно потому, что я пропустил первую часть доклада. Рассказчики рекламировали свою облачную платформу, где можно запускать OSGi-бандлы в их настроенном облачном окружении. Потом показывали, как писать приложение в OSGi-среде, и теоретически такое приложение должно было исполняться у них в облаке. При этом я не увидел каких-либо преимуществ перед другими известными мне технологиями вроде Spring или maven, которые решают львиную долю проблем, решаемых OSGi. В общем, у меня после доклада был обильный холивар с коллегами на эту тему. Ну и ещё они ужасно быстро тараторили, а я не настолько хорошо воспринимаю на слух английский язык.
Вероятно, о втором дне на JavaOne я напишу в следующий раз.