Компактный runtime-DI для Java: JSR-330, Class-File API и миграция за 2 дня

Когда начинал разработку системы многомерного анализа данных временных рядов Dimension-UI, для внедрения зависимостей в исходном коде решил использовать Dagger 2. Практический опыт показал, что для приложений с большим количеством динамически создаваемых объектов инверсия зависимостей, реализованная в Dagger 2, не подходит.

Да, создание графа зависимостей в compile-time — это, во-первых, очень быстро, и, во-вторых, удобно: получаешь сообщения об ошибках конфигурации уже при компиляции.

Но накладные расходы на сопровождение всего этого хозяйства – прямо скажем, это боль.

Чтобы реализовать scope-зависимости, приходится писать и поддерживать много инфраструктурного кода внутри объектов, куда мы внедряем зависимости. В Dagger 2 такая реализация, во-первых, «загрязняет» код, а во-вторых, серьезно осложняет тестирование. Изолировать методы удобным способом не получается: в тестах нужно писать очень много кода, чтобы прокинуть необходимый контекст и корректно мокировать внешние зависимости. Я туда просто не полез — покрывал unit- и UI-тестами только базовую функциональность, где были Singleton-зависимости.

Даже с одними Singleton’ами приходится поднимать отдельную тестовую инфраструктуру для запуска приложения в тестовом режиме. Это не просто неудобно — это очень затратно по времени. Если сравнить усилия, которые надо потратить на реализацию тестирования подобного функционала в Spring и Dagger… Сравнение будет не в пользу Dagger. В целом я начал думать о переходе на runtime-генерацию графа зависимостей.

Поиск альтернатив

Итак, мы попробовали compile-time генерацию графа зависимостей в Dagger 2 — и нам это не подходит. Какие альтернативы? Если смотреть глобально, остаются Spring и Guice. Spring реализует runtime-генерацию графа зависимостей через рефлексию. Spring не рассматриваем — это большая и массивная библиотека; тащить её в наш tiny and cozy проект не очень правильно (плюс вопросы производительности/оптимизации).

Остается Guice — он тоже runtime (через рефлексию), вроде подходит. Смотрим активность проекта на GitHub: последний релиз май 2023 года — это жжж неспроста. Я понимаю, время было непростое для Google, но сам факт намекает на охлаждение интереса к направлению. Косвенно это подтверждает движение Micronaut и Quarkus в сторону compile-time контейнеров DI.

Хорошо, «большая тройка» лидеров — с ними понятно. Есть и нишевые решения. Честно говоря, я смотрел их по верхам — просто не было времени. Полная таблица со сравнением есть в конце статьи, здесь приведу предварительный итог:

• Spring/Guice: мейнстрим enterprise-разработка, runtime;

• PicoContainer: нишевый инструмент для специфических задач, runtime;

• HK2: специализированный инструмент для JAX-RS/OSGi-экосистем, runtime;

• Avaje Inject: современная альтернатива Micronaut/Quarkus с упором на простоту, compile-time

Все варианты с runtime построением графа зависимостей используют Java Reflection API.

Из предложенных альтернатив более-менее близок был PicoContainer, но инвестировать время в инструмент, у которого на GitHub затишье, я не решился.

Это все понятно, вроде как разложено по полочкам (что-то я разложил сейчас, когда писал эту статью). Но в основном, у меня были ощущения, что торопиться в этом деле не нужно.

Все-таки надо попробовать разведать вариант с написанием собственного DI – с учетом того что по любому, в новых версиях Java должна быть какая возможность сделать runtime DI основанных на других принципах.

Помощь магистров искусственного разума LLM

Решил обратиться к трем LLM (gpt-5-high, gemini-2.5-pro и deepseek-v3.2-exp-thinking) с вопросом, как можно реализовать DI на runtime с поддержкой JSR-330 в последних версиях Java. С задачей справился только Google Gemini и в одном из вариантов предложил формировать граф зависимостей, сканируя class-файлы на наличие аннотаций JSR-330 с помощью Class-File API (JEP 484, JDK 24+).

По сути это та же схема, что и с Dagger 2, но в runtime и с минимальным использованием рефлексии — с поддержкой функций @Singleton, @Named и @Provides. Все с прицелом на простую миграцию с Dagger 2 и с минимальными правками в коде. Без использования устаревшего javax.inject: вместо него — jakarta.inject обновленная версия стандарта JSR-330.

После нескольких итераций, генерации тестов, документации - на выходе получился легковесный контейнер для внедрения зависимостей, оптимизированный для производительности и простоты использования – Dimension-DI.

• Использует JSR-330 (@Inject, @Named) для чистого кода с внедрением через конструктор;

• Поддерживает scope @Singleton, обнаружение циклических зависимостей и явную привязку для интерфейсов.

• Использует сканирование classpath через JDK Class-File API (без загрузки классов) для быстрого запуска.

• Никаких прокси, генерации байт-кода или магии во время выполнения — только простой, потокобезопасный сервис-локатор "под капотом".

1. Конфигурация на этапе сборки: Гибкий API Builder используется для настройки DI-контейнера. Этот этап включает сканирование classpath на наличие компонентов, помеченных @Inject, анализ их зависимостей и регистрацию провайдеров (рецептов для создания объектов). Именно здесь проявляется "DI" часть.

2. Разрешение во время выполнения: Во время выполнения зависимости разрешаются с помощью внутреннего, глобально доступного ServiceLocator. Хотя реализация использует Service Locator, дизайн настроен на написание кода вашего приложения с использованием чистого Внедрения через конструктор (Constructor Injection), отделяя ваши компоненты от самого DI-фреймворка. Можно напрямую вызывать ServiceLocator - но только в отдельных случаях, об этом ниже.

Смена DI в Dimension-UI

Процесс перехода Dimension-UI с Dagger 2 на Dimension-DI занял пару дней.

Сначала все файлы конфигурации разобрали и перевели в формат конфигурации Dimension-DI (с помощью LLM):

package ru.dimension.ui.config;

import dagger.Binds;
import dagger.Module;
import javax.inject.Named;
import ru.dimension.ui.cache.AppCache;
import ru.dimension.ui.cache.impl.AppCacheImpl;

@Module
public abstract class CacheConfig {

  @Binds
  @Named("appCache")
  public abstract AppCache bindAppCache(AppCacheImpl appCache);
}

package ru.dimension.ui.config;

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import dagger.Module;
import dagger.Provides;
import java.nio.file.Paths;
import javax.inject.Singleton;
import ru.dimension.ui.helper.FilesHelper;
import ru.dimension.ui.helper.ReportHelper;

@Module
public class FileConfig {

  @Provides
  @Singleton
  public FilesHelper getFilesHelper() {
    return new FilesHelper(Paths.get(".").toAbsolutePath().normalize().toString());
  }

  @Provides
  @Singleton
  public Gson getGson() {
    return new GsonBuilder()
        .setPrettyPrinting()
        .create();
  }

  @Provides
  @Singleton
  public ReportHelper getReportHelper() {
    return new ReportHelper();
  }
}

package ru.dimension.ui.config;

import dagger.Binds;
import dagger.Module;
import javax.inject.Named;
import ru.dimension.ui.state.NavigatorState;
import ru.dimension.ui.state.SqlQueryState;
import ru.dimension.ui.state.impl.NavigatorStateImpl;
import ru.dimension.ui.state.impl.SqlQueryStateImpl;

@Module
public abstract class StateConfig {

  @Binds
  @Named("navigatorState")
  public abstract NavigatorState bindNavigatorState(NavigatorStateImpl navigatorState);

  @Binds
  @Named("sqlQueryState")
  public abstract SqlQueryState bindSqlQueryState(SqlQueryStateImpl sqlQueryState);
}

package ru.dimension.ui.config.core;

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import java.nio.file.Paths;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import ru.dimension.db.core.DStore;
import ru.dimension.di.DimensionDI;
import ru.dimension.di.ServiceLocator;
import ru.dimension.ui.cache.AppCache;
import ru.dimension.ui.cache.impl.AppCacheImpl;
import ru.dimension.ui.collector.Collector;
import ru.dimension.ui.collector.CollectorImpl;
import ru.dimension.ui.collector.collect.prometheus.ExporterParser;
import ru.dimension.ui.collector.http.HttpResponseFetcher;
import ru.dimension.ui.collector.http.HttpResponseFetcherImpl;
import ru.dimension.ui.helper.ColorHelper;
import ru.dimension.ui.helper.FilesHelper;
import ru.dimension.ui.helper.ReportHelper;
import ru.dimension.ui.manager.ConfigurationManager;
import ru.dimension.ui.warehouse.LocalDB;

public final class CoreConfig {

  private CoreConfig() {
  }

  public static void configure(DimensionDI.Builder builder) {
    builder
        // Cache
        .bindNamed(AppCache.class, "appCache", AppCacheImpl.class)

        // Collector
        .bindNamed(Collector.class, "collector", CollectorImpl.class)

        // Executors
        .provideNamed(ScheduledExecutorService.class, "executorService", ServiceLocator.singleton(
            () -> Executors.newScheduledThreadPool(10)
        ))
        .provideNamed(ru.dimension.ui.executor.TaskExecutorPool.class, "taskExecutorPool",
                      ServiceLocator.singleton(ru.dimension.ui.executor.TaskExecutorPool::new))

        // File/Gson/Report helpers
        .provide(FilesHelper.class, ServiceLocator.singleton(
            () -> new FilesHelper(Paths.get(".").toAbsolutePath().normalize().toString())
        ))
        .provide(Gson.class, ServiceLocator.singleton(
            () -> new GsonBuilder().setPrettyPrinting().create()
        ))
        .provide(ReportHelper.class, ServiceLocator.singleton(ReportHelper::new))

        // Color helper (uses FilesHelper and ConfigurationManager)
        .provide(ColorHelper.class, ServiceLocator.singleton(
            () -> new ColorHelper(
                ServiceLocator.get(FilesHelper.class),
                ServiceLocator.get(ConfigurationManager.class, "configurationManager"))
        ))

        // Local DB
        .bindNamed(DStore.class, "localDB", LocalDB.class)

        // HTTP / Parser
        .provideNamed(ExporterParser.class, "exporterParser", () -> ServiceLocator.get(ExporterParser.class))
        .bindNamed(HttpResponseFetcher.class, "httpResponseFetcher", HttpResponseFetcherImpl.class);
  }
}

После этого поправили точку входа в приложение Application:

package ru.dimension.ui;

import lombok.extern.log4j.Log4j2;
import ru.dimension.ui.config.MainComponent;
import ru.dimension.ui.laf.LaF;
import ru.dimension.ui.laf.LaFType;
import ru.dimension.ui.prompt.Internationalization;
import ru.dimension.ui.view.BaseFrame;

@Log4j2
public class Application {

  private static MainComponent mainComponent;

  public static MainComponent getInstance() {
    return mainComponent;
  }

  /**
   * Use LaF parameter in VM option to enable dark, light or default theme
   * <p>
   * Supported any of: "-DLaF=dark", "-DLaF=light", "-DLaF=default"
   * <p>
   * Example: java -DLaF=dark -Dfile.encoding=UTF8 -jar desktop-1.0-SNAPSHOT-jar-with-dependencies.jar
   */
  public static void main(String... args) {
    System.getProperties().setProperty("oracle.jdbc.J2EE13Compliant", "true");

    if ("ru".equals(System.getProperty("user.language"))) {
      Internationalization.setLanguage("ru");
    } else if ("en".equals(System.getProperty("user.language"))) {
      Internationalization.setLanguage("en");
    } else {
      Internationalization.setLanguage();
    }

    try {
      System.setProperty("flatlaf.uiScale", "1.1x");

      String lafVMOption = "LaF";
      if (LaFType.DEFAULT.name().equalsIgnoreCase(System.getProperty(lafVMOption))) {
        LaF.setLookAndFeel(LaFType.DEFAULT);
      } else if (LaFType.LIGHT.name().equalsIgnoreCase(System.getProperty(lafVMOption))) {
        LaF.setLookAndFeel(LaFType.LIGHT);
      } else if (LaFType.DARK.name().equalsIgnoreCase(System.getProperty(lafVMOption))) {
        LaF.setLookAndFeel(LaFType.DARK);
      } else {
        LaF.setLookAndFeel(LaFType.DEFAULT);
      }
    } catch (Exception e) {
      log.catching(e);
    }

    mainComponent = ru.dimension.ui.config.DaggerMainComponent.create();

    BaseFrame baseFrame = mainComponent.createBaseFrame();
    baseFrame.setVisible(true);
  }
}

package ru.dimension.ui;

import lombok.extern.log4j.Log4j2;
import ru.dimension.di.ServiceLocator;
import ru.dimension.ui.config.DIConfig;
import ru.dimension.ui.laf.LaF;
import ru.dimension.ui.laf.LaFType;
import ru.dimension.ui.prompt.Internationalization;
import ru.dimension.ui.view.BaseFrame;

@Log4j2
public class Application {

  /**
   * Use LaF parameter in VM option to enable dark, light or default theme
   * <p>
   * Supported any of: "-DLaF=dark", "-DLaF=light", "-DLaF=default"
   * <p>
   * Example: java -DLaF=dark -Dfile.encoding=UTF8 -jar desktop-1.0-SNAPSHOT-jar-with-dependencies.jar
   */
  public static void main(String... args) {
    System.getProperties().setProperty("oracle.jdbc.J2EE13Compliant", "true");

    if ("ru".equals(System.getProperty("user.language"))) {
      Internationalization.setLanguage("ru");
    } else if ("en".equals(System.getProperty("user.language"))) {
      Internationalization.setLanguage("en");
    } else {
      Internationalization.setLanguage();
    }

    try {
      System.setProperty("flatlaf.uiScale", "1.1x");

      String lafVMOption = "LaF";
      if (LaFType.DEFAULT.name().equalsIgnoreCase(System.getProperty(lafVMOption))) {
        LaF.setLookAndFeel(LaFType.DEFAULT);
      } else if (LaFType.LIGHT.name().equalsIgnoreCase(System.getProperty(lafVMOption))) {
        LaF.setLookAndFeel(LaFType.LIGHT);
      } else if (LaFType.DARK.name().equalsIgnoreCase(System.getProperty(lafVMOption))) {
        LaF.setLookAndFeel(LaFType.DARK);
      } else {
        LaF.setLookAndFeel(LaFType.DEFAULT);
      }
    } catch (Exception e) {
      log.catching(e);
    }

    DIConfig.init();

    BaseFrame baseFrame = ServiceLocator.get(BaseFrame.class);
    baseFrame.setVisible(true);
  }
}

Затем автозаменой в OpenIDE поменяли javax.inject —> jakarta.inject и начали тестирование работы приложения.

Особых проблем не обнаружилось. Единственное — в нескольких файлах проекта Dimension-DI выявил циклические зависимости и сообщил об этом в консоли при старте — удобно. Как справлялся с ними Dagger 2? Через позднее связывание Lazy. Надо написать автору, чтобы больше так не делал.

Следующий этап — правка тестов. Тут особых проблем тоже не возникло. Особенно порадовало раскомментирование @Disabled на классах тестирующих автоматику по пересозданию графиков при SeriesExceedExceptionи последующее успешное прохождение тестов с первого раза. Отключены тесты были из-за сложностей конфигурации Dagger 2.

Да, внутри тестируемых классов пришлось использовать ServiceLocator напрямую — но: а) это минимальное изменение (одно), которое сейчас покрыто тестами; и б) теперь эти классы можно тестировать в изолированном окружении — удобно, а не так, как это было в Dagger 2.

Кстати, во время тестирования два DI работали совместно не мешая друг другу.

Небольшое сравнение Dimension-DI с другими решениями

Dimension-DI против "Большой тройки"

Dimension-DI против альтернативных легковесных контейнеров

Выводы

Внедрение зависимостей в Java с использованием compile-time генерации графа зависимостей обладает рядом неустранимых проблем, побороть которые у меня не получилось без смены DI провайдера. Не исключаю, что в других системах подобные задачи решаются по другому, но – получилось вот так.

С другой стороны, runtime-генерация практически во всех DI – это Java Reflection API, что снижает быстродействие (особенно на больших объемах объектов в графе) и требует ресурсов на сопровождение всей этой инфраструктуры. Для небольших и среднего размера проектов – это очевидный overhead.

Dimension-DI исключает рефлексию на этапе discovery (Class-File API) и использует MethodHandles при создании объектов. То есть это runtime-DI без java.lang.reflect на «горячем пути» инстанцирования — в моих сценариях это быстро. Посмотрим, что из этого выйдет – на будущее, надо бы добавить бенчмарки и кэш графа для реальных метрик.

Ссылки и дополнительные материалы

• Dimension DI: https://github.com/akardapolov/dimension-di — компактный, быстрый DI-фреймворк для Java с простой конфигурацией и внедрением зависимостей в runtime.

• Dimension UI: https://github.com/akardapolov/dimension-ui — десктопное приложение для сбора, хранения, визуализации и анализа данных временных рядов.

• Dagger 2: https://dagger.dev/

• Guice: https://github.com/google/guice

• PicoContainer: https://github.com/picocontainer/picocontainer

• HK2: https://github.com/eclipse-ee4j/glassfish-hk2

• Avaje Inject: https://github.com/avaje/avaje-inject

• Micronaut: https://micronaut.io/

• Quarkus: https://quarkus.io/

• Class-File API (JEP 484): https://openjdk.org/jeps/484

• JSR 330: https://github.com/javax-inject/javax-inject

Вроде все, спасибо за внимание!