JUG.ua

Осенью прошлого года на конференции JavaOne в Сан-Франциско, традиционно были присуждены награды лучшим проектам года “2011 Duke’s Choice Awards”. И хотелось бы подготовить цикл небольших статей, коротко описывающих каждый из проектов-победителей.

Начнем данный цикл с номинации “Innovative Compiler for Java Code”, награду в которой получил проект JRebel, эстонской компании ZeroTurnaround, созданный Евгением Кабановым (Jevgeni Kabanov) и Томасом Румером (Toomas Römer).

Стоит отметить, что это не единственная их награда за прошедший год, этот проект был признан “Самой инновационной технологией Java” на JAX Innovation Awards. А в числе пользователей JRebel значатся IBM, HP, AT&T, Bank of America, Disney, LinkedIn, …

Для того, чтобы понять предназначение JRebel начнем чуть-чуть издалека

Рассмотрим два простых класса. Первый класс имеет лишь переопределенный метод toString():

public class TestModule {
    @Override
    public String toString() {
        return "TestModule, version 1!";
    }
}

Второй класс в бесконечном цикле создает экземпляр объекта первого класса и выводит его на экран:

public class Test {
  public static void main(String[] argv) {
    for (;;) {
            TestModule t = new TestModule();
            System.out.println(t);
            System.console().readLine();
    }
  }
}

Если же во время выполнения программы мы изменим строку “TestModule, version 1!” на “TestModule, version 2!”, и применяя раздельную компиляцию заново скомпилируем класс TestModule, то от этого значение выводимой строки не измениться.

Это происходит потому, что стандартный (системный) ClassLoader при первом же обращении к классу, а точнее при вызове его конструктора (либо при обращении к статическому методу или полю), динамически загружает и кеширует байт-код класса в недра JVM, и в дальнейшем уже не обращается к файловой системе. Можете даже удалить файл TestModule.class, это никак не отразиться на работе программы.

Перечень загружаемых во время работы программы классов, и директории откуда они загружаются, можно узнать подставив при запуске программы ключик java -verbose:class …. Узнаете много чего интересного ;)

Из приведенного выше примера следует, то, что после изменения исходного кода (и, соответственно, байт-кода) необходимо перезапускать все приложение. А в случае промышленного (Java Web, Java EE) приложения заново разворачивать его на сервере. Вообщем-то логично.

Все бы ничего, но проведенные исследования показали, что разработчики тратят в среднем от 10 до 13 минут на час программирования, на периодическое развертывания приложений.

Чтобы сократить потери времени, необходимо “научить” JVM обновлять байт-код классов в случаи их изменений, без необходимости перезапуска приложения.

В простом случае для этого достаточно написать свой загрузчик классов, который наследуется от абстрактного класса ClassLoader, и переопределить в нем ряд методов таким образом, чтобы при каждом создании экземпляра класса его байт-код считывался с файловой системы. Это на самом деле делается не так страшно, как может показаться и подробно, вместе с примерами, описывается в статье “ClassLoader – скрытые возможности”.

Экземпляр собственного ClassLoader-а предается в качестве параметра статического метода Class.forName(String name, boolean initialize, ClassLoader loader), после чего с помощью рефлексии создается экземпляр требуемого класса:

public class Test {
  public static void main(String[] argv) throws Exception {
    for (;;) {
      ClassLoader loader = new DynamicClassOverloader(new String[] {"."});
      // текущий каталог "." будет единственным каталогом поиска для
      // класса "TestModule"
      Class clazz = Class.forName("TestModule",true,loader);
      Object object = clazz.newInstance();
      System.out.println(object);

      //TestModule test = (TestModule) object;

      System.console().readLine();
    }
  }
}

В данном примере DynamicClassOverloader (код по ссылке) как раз и является нашим загрузчиком классов (подробности в указанной статье “ClassLoader – скрытые возможности”).

Можно проверить, что теперь во время работы программы при изменении строки “TestModule, version 1!” на “TestModule, version 2!” будет меняться и выводимое в консоль сообщение.

Все было бы замечательно, если бы не ряд особенностей. Первая из которых начнется если откомментировать 10 строчку. В результате получим замечательное RuntimeException:

Exception in thread "main" java.lang.ClassCastException: TestModule cannot be cast to TestModule

Почему оно происходит? Запустим нашу программу с ключиком java -verbose:class Test, и обратим внимание на следующий фрагмент:

...
[Loaded TestModule from __JVM_DefineClass__]
TestModule, version 1!
[Loaded TestModule from file:/C:/Projects/DynamicClassLoader/build/classes/]
...

В первой строке происходит загрузка класса TestModule с помощью нашего собственного загрузчика классов, во второй – вывод сообщения, в третей – стандартный (системный) загрузчик классов снова загружает класс TestModule, именно в тот момент когда пытаемся осуществить приведение типов:

TestModule test = (TestModule) object;

Получается, что класс к которому мы хотим привести (преобразовать) объект загружен с помощью системного загрузчика, а класс на основании которого этот объект object был создан загружен с помощью нашего собственного загрузчика. Хоть классы одинаковы (и их байт-код идентичен), но загружены разными загрузчиками, и, как следствием, JVM считает их абсолютно разными.

Такую вот особенность, и далеко не единственную, которую нужно учитывать при написании собственного загрузчика классов.

Теперь, что же такое JRebel

JRebel – это плагин к JVM, который позволяет на лету перезагружать классы и другие ресурсы, которые были изменены с момента развёртывания приложения. При этом он не имеет тех проблем и особенностей, которые возникают при написании собственного загрузчика классов.

При загрузке класса в JVM, JRebel отслеживает соответствующий ему .class-файл и в случае его изменения подгружает изменившийся класс через расширенный загрузчик классов. При этом старые экземпляры классов и сам класс сохраняется, что позволяет приложению продолжать работу без потери данных. Новые же экземпляры класса будут создаются уже на основании обновленного байт-кода класса.

На данный момент JRebel поддерживает практически все изменения, которые могут осуществляться в исходном коде (JRebel Features):

• Changes to method bodies
• Adding/removing Methods
• Adding/removing constructors
• Adding/removing fields
• Adding/removing classes
• Adding/removing annotations
• Changing static field value
• Adding/removing enum values
• Changing interfaces

за исключением изменений связанных с иерархией классов:

• Replacing superclass
• Adding/removing implemented interfaces

Есть ли аналоги? Да есть, но им далеко до возможностей JRebel. Сравнительную табличку аналогичных технологий и более подробное описание JRebel можно посмотреть в статье Get to Production Sooner.

Что еще посмотреть/почитать по теме

• Отчет - “Java EE Productivity Report 2011″
• Видео с конференции и набор статей от автора JRebel, Евгения Кабанова -  Reloading Java Classes: Technical Series
• Статья - “5 JRebel Features You Couldn’t Do In The JVM”

Также, компания  ZeroTurnaround недавно выпустила свой новый продукт LiveRebel. И если основной целью JRebel было сократить потери времени разработчиков на т.н. “Turnaround”, то LiveRebel в первую очередь рассчитан на обновление приложений на лету в “продакшане” без необходимости остановки их работы и с гарантией сохранения сессии.

Будем ждать таких же успехом LiveRebel!

P.S. Если кто-то захочет написать небольшую статью о других проектах получивших награды  “2011 Duke’s Choice Awards”, не стесняйтесь ;)

За помощь в подготовке данного материа спасибо Полянскому Дмитрию