Структура байт-кода виртуальной машины Java
У платформы java имеется две особенности. Для обеспечения кроссплатформенности программа сначала компилируется в промежуточный язык низкого уровня — байт-код. Вторая особенность загрузка исполняемых классов происходит с помощью расширяемых classloader. Это механизм обеспечивает большую гибкость и позволяет модифицировать исполняемый код при загрузке, создавать и подгружать новые классы во время выполнения программы.
Такая техника широко применяется для реализации AOP, создания тестовых фреймворков, ORM. Особенно хочется отметить terracotta, продукт с красивой идеей кластеризации jvm и на всю катушку использующей модификации байт-кода. Эта заметка будет посвящена обзору структуры байт-кода, первой части этой сильной связки.
Способы «защиты» flash-приложений

Здравствуйте. Я попытаюсь рассказать о нескольких способах защиты от исследования кода, мошенничества и воровства, используемых при разработке flash-приложений, а также о том, как можно обойти некоторые из них.
Стоит заметить, что сейчас существует немало отличных презентаций и работ на эту тему (см. ссылки в конце статьи), однако, я бы хотел немного подробней расписать некоторые нюансы, и объединить множество информации по теме в одном месте. По крайней мере, я постараюсь это сделать.
Java Bytecode Fundamentals
В статье описаны самые основы, от которых можно отталкиваться в дальнейшем раскапывании данной темы (прим. пер.).
Модификация игр на примере Arcanoid
Введение
На протяжении некоторого времени я наблюдал за блогом Assembler на хабре в виду того, что там начали появляться более чем отличные статьи по анализу различных keygen'ов и «reverse engineering». Я давно хотел заняться чем-то подобным и модифицировать какую-нибудь игру на J2ME. Я долго бродил по интернету в поисках хорошей, но в тоже время лёгкой для понимания (в плане анализа) игры. Однажды, я копался на сайте моего друга программиста (кстати, он тоже пишет программы для J2ME. Кто использовал ProPaintMobile — тот знает, о ком я говорю. И я нашёл её — это был простенький Арканоид. Видимо, это было чьё-то домашнее задание, или же он писался просто «just for fun», но тем не менее эта игра оказалась именно тем, чем нужно.
Groovy и трансформации AST на службе безопасности приложения
Предыстория
Мы разрабатываем небольшой портал на Grails и используем Spring Security для управления безопасностью. Плагин spring-security для Grails достаточно удобен и до последнего момента от него не требовалось сложной функциональности.
Недавно был обнаружен неприятный момент в использовании аннотаций @Secured для методов контроллеров Grails. Проблема заключается в том, что аннотации обрабатываются во время исполнения и преобразуются в набор правил для адресов «Адрес -> Набор требуемых ролей». Такой подход порождает ряд проблем в Grails-контроллерах в действиях сохранения/удаления данных, поскольку они отправляют данные на основной URL контроллера, то приходиться во-первых аннотировать контроллер, во вторых — невозможно задать различные ограничения для таких запросов.
Речь пойдёт о том, как решить проблему и приобрести хороший инструмент для управления правилами безопасности.
Шифруются? Вытаскиваем байткод из JVM

Привет, хабр. Я пишу на языке Java, занимаюсь, преимущественно, работой с серверами MMORPG игр. Серверные «сборки» выпускаются многими командами, работающими в этой сфере. Некоторые платно, а некото
Python изнутри. Введение

2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса
Помимо изучения стандартной библиотеки, всегда интересно, а иногда и полезно, знать, как язык устроен изнутри. Андрей Светлов (svetlov), один из разработчиков Python, советует всем интересующимся серию статей об устройстве CPython. Представляю вам перевод первого эпизода.
Мой друг однажды сказал мне: «Знаешь, для некоторых людей язык C — это просто набор макросов, который разворачивается в ассемблерные инструкции». Это было давно (для всезнаек: да, ещё до появления LLVM), но эти слова хорошо мне запомнились. Может быть, когда Керниган и Ритчи смотрят на C-программу, они на самом деле видят ассемблерный код? А Тим Бёрнерс-Ли? Может он сёрфит интернет по-другому, не так, как мы? И что, в конце концов, Киану Ривз видел в том жутком зелёном месиве? Нет, правда, что, чёрт побери, он там видел?! Эм… вернёмся к программам. Что видит Гвидо ван Россум, когда читает программы на Python?
Компиляция Try/Catch/Finally для JVM
Вместо введения
Автор статьи, Alan Keefer1, является главным архитектором компании Guidewire Software2, разрабатывающей программное обеспечение для страхового бизнеса. Еще будучи старшим разработчиком, он участвовал в работе над языком Gosu3. В частности, Алан занимался вопросами компиляции языка в байт-код Java.
Данная статья написана в 2009 году и посвящена деталям реализации try/catch/finally в JVM версии 1.6. Для ее прочтения необходимо иметь базовые знания синтаксиса Java, а также понимать назначение байт-кода, простыни которого лежат под катом. Также в конце статьи приведен ряд примеров, похожих на каверзные задачи SCJP.
Внутренности JVM
Одной из вещей, над которой по целому ряду причин мы сейчас работаем, является компиляция нашего «домашнего» языка в байт-код Java. (Для справки: не могу сказать, когда мы закончим. Даже примерно. Даже попадет ли он в будущие релизы.) Веселье заключается в изучении внутренностей JVM, а также поиске всех долбанутых острых углов собственного языка. Но больше всего «веселья» и острых углов доставляют такие операторы, как try/catch/finally. Поэтому, на этот раз, я не буду вдаваться в философию или аджайл. Вместо этого я углублюсь в JVM, куда большинству не требуется (или не хочется) углубляться.
Если бы две недели назад вы спросили меня о finally-блоках, я бы предположил, что их обработка реализована в JVM: это базовая часть языка, она должна быть встроенной, не так ли? Каково же было мое удивление, когда я узнал: нет, не так. На самом деле finally-блоки просто подставляются во все возможны места после try- или связанных с ним catch-блоков. Эти блоки оборачиваются в «catch(Throwable)», который повторно выбросит исключение после того, как finally-блок закончит работу. Осталось только подкрутить таблицу исключений, чтобы подставленные finally-блоки были пропущены. Ну как? (Небольшой нюанс: до версии JVM 1.6 для оператора finally, по всей видимости, использовались подпограммы вместо полной подстановки. Но сейчас мы говорим о версии 1.6, к которой все вышесказанное применимо.)
Пул констант
Возьмём, к примеру, такой код:
System.out.println("Hello World!");
Он транслируется в три инструкции байткода: getstatic (для загрузки статического поля System.out), ldc (для загрузки константной строки «Hello World!») и invokevirtual (для выполнения виртуальной функции println). Попробуйте прикинуть, сколько констант нужно для того, чтобы этот код работал.
Компиляция и декомпиляция try-with-resources
Введение

Признаюсь, что идеей мутационного тестирования я загорелся. Почти без дополнительных усилий получить инструмент поиска потенциально опасных мест кода — оно того стоит! Я без промедления взялся за дело. На тот момент библиотека была относительно молодой, как следствие — весьма сырой: здесь нужно немного пошаманить с конфигурацией maven’а, там — пропатчить плагин для Sonar’а. Однако через некоторое время я все же смог проверить проект целиком. Результат: сотни выживших мутаций! Эволюция в масштабе на нашем build-сервере.
Засучив рукава я погрузился в работу. В одних тестах не хватает верификаций заглушек, в других вместо логики вообще непонятно что тестируется. Правим, улучшаем, переписываем. В общем, процесс пошел, но число выживших мутаций убывало не так стремительно, как хотелось. Причина была проста: PIT давал огромное количество ложных срабатываний на блоке try-with-resources. Недолгие поиски показали, что баг известен, но до сих пор не исправлен. Что ж, код библиотеки открыт. От чего бы не склонировать его и не посмотреть, в чем же дело?
Java байткод «Hello world»
Для своего эксперимента я создал директорию src, куда в папку hello положил файл App.java:
package hello;
public class App {
public static void main(String[] args) {
System.out.println("Hello world!");
}
}
JCoro — асинхронность на сопрограммах в Java
startReadSocket((data) -> {
startWriteFile(data, (result) -> {
if (result == ok) ...
});
});
мы можем переписать так:
data = readSocket();
result = writeFile(data);
if (result == ok) ...
Здесь readSocket() и writeFile() — сопрограммы, в которых асинхронные операции вызываются следующим образом:
byte[] readSocket() {
byte[] result = null;
startReadSocket((data) -> {
result = data;
resume();
});
yield();
return result;
}
Методы yield() и resume() сохраняют и восстанавливают контекст выполнения, со всеми фреймами и локальными переменными. Происходит следующее: при вызове readSocket() мы планируем асинхронную операцию вызовом startReadSocket() и выполняем yield(). Yield() сохраняет контекст выполнения и поток завершается (возвращается в пул). Когда асинхронная операция будет выполнена, мы вызовем resume() перед выходом из callback'a, и тем самым возобновим выполнение кода. Управление снова получит основная функция, которая вызовет writeFile(). writeFile() устроен аналогично, и всё повторится.
Сделав единожды такое преобразование для всех используемых асинхронных операций и поместив полученные функции в библиотеку, мы получаем инструмент, позволяющий нам писать асинхронный код так, как будто это обычный синхронный код. Мы получаем возможность сочетать плюсы синхронного кода (читабельность, удобная обработка ошибок) и асинхронного (производительность). Плата за это удобство — необходимость как-то сохранять и восстанавливать контекст выполнения. В статье автор описывает реализацию на С++, мне же захотелось заиметь что-то такое в Java. Об этом и пойдёт речь.
Модификация программы и что лучше менять: исполняемый код или AST программы?
- манипуляции с исполняемым кодом программы после компиляции или во время загрузки кода;
- изменение исходного кода перед компиляцией.

Лучше в райнтайме, чем никогда: расширяем API JIRA «на лету»

Последней надеждой в этой ситуации может быть применение средств пакета java.lang.instrument. Всем, кому интересно, что и как в Java можно сделать с кодом в уже запущенной VM, добро пожаловать под кат.
Вызов методов через reflection
Все программисты на Java явно или неявно пользуются reflection для вызова методов. Даже если вы не делали этого сами, это за вас наверняка делают библиотеки или фреймворки, которые вы используете. Давайте посмотрим, как этот вызов устроен внутри и насколько это быстро. Будем глядеть в OpenJDK 8 с последними обновлениями.
Оптимизация хвостовой рекурсии в Java
Попробуем разобраться с причинами и посмотрим, что можно сделать своими руками.
Знакомство с командой курсов стека Java на Hexlet

Что там с JEP-303 или изобретаем invokedynamic
Блогеры и авторы, пытающиеся быть на передовой, уже немало писали про проект Amber в Java 10. В этих статьях обязательно упоминается вывод типов локальных переменных, улучшения enum и лямбд, иногда пишут про pattern matching и data-классы. Но при этом незаслуженно обходится стороной JEP 303: Intrinsics for the LDC and INVOKEDYNAMIC Instructions. Возможно, потому что мало кто понимает, к чему это вообще. Хотя любопытно, что именно об этой фиче ребята из NIX_Solutions фантазировали на Хабре год назад.
Широко известно, что в виртуальной машине Java, начиная с версии 7, есть интересная инструкция invokedynamic (она же indy). Про неё многие слышали, однако мало кто знает, что она делает на самом деле. Кто-то знает, что она используется при компиляции лямбда-выражений и ссылок на методы в Java 8. Некоторые слышали, что через неё реализована конкатенация строк в Java 9. Но хотя это полезные применения indy, изначальная цель всё же немного другая: делать динамический вызов, при котором вы можете вызывать разный код в одном и том же месте. Эта возможность не используется ни в лямбдах, ни в конкатенации строк: там поведение всегда генерируется при первом вызове и остаётся постоянным до конца работы программы (всегда используется ConstantCallSite). Давайте посмотрим, что можно сделать ещё.