Здравствуйте, эта статья не про аниме, но мы точно знаем как пропатчить Idea для FreeBSD. И не боимся об этом рассказывать.

Intellij и FreeBSD

Помимо проблем с блокировками пользователей из РФ, у команды Intellij есть еще явное предубеждение против моей любимой операционной системы — FreeBSD, поддержку которой они постоянно ломают в своих продуктах, препятствуя использованию в этом окружении.

Но волю советского инженера не сломить, поэтому автор продолжает цинично использовать то что нельзя там где это невозможно, невзирая на мнение этой замечательной компании и ее сотрудников.

Потому что когда-то учил инженерное дело настоящим образом и неоднократно патчил Idea вручную. Ну да ладно, вернемся к теме:

на примере популярной среды разработки Intellij Idea, показываю как патчить софт на Java подручными средствами с помощью синей изоленты.

Все поддается доработке если ты инженер.

Изучение проблемы

Недавно при попытке автоматического обновления, моя Idea в очередной раз самоубилась, не выдержав ужасов эксплуатации, поэтому был скачан последний релизный билд с официального сайта:

251.25410.129

К сожалению, в этой версии при попытке запуска появляется искусственная ошибка с сообщением про неподдерживаемую ОС, запуск Idea на этом останавливается:

./bin/idea.sh 
[0.005s][warning][cds] Archived non-system classes are disabled because the java.system.class.loader property is specified (value = "com.intellij.util.lang.PathClassLoader"). To use archived non-system classes, this property must not be set

**Start Failed**

Internal error

java.lang.UnsupportedOperationException: Unsupported OS:FreeBSD
	at com.intellij.openapi.application.PathManager.getLocalOS(PathManager.java:501)
	at com.intellij.openapi.application.PathManager.platformPath(PathManager.java:927)
	at com.intellij.openapi.application.PathManager.getDefaultConfigPathFor(PathManager.java:394)
	at com.intellij.openapi.application.PathManager.getCustomOptionsDirectory(PathManager.java:448)
	at com.intellij.openapi.application.PathManager.loadProperties(PathManager.java:710)
	at com.intellij.idea.Main.mainImpl(Main.kt:65)
	at com.intellij.idea.Main.main(Main.kt:47)

Эту же ошибку но в графическом исполнении вы можете узреть на заглавном скриншоте к статье — до такой степени в Jetbrains не любят BSD‑шников.

Исходный код сommunity-версии Idea находится в репозитории на Github, поэтому класс из которого выбрасывается ошибка:

com.intellij.openapi.application.PathManager

легко можно найти поиском по репозиторию.

Точное место выглядит так:

..
@ApiStatus.Internal
public static @NotNull OS getLocalOS() {
    if (SystemInfoRt.isMac) {
      return OS.MACOS;
    }
    else if (SystemInfoRt.isWindows) {
      return OS.WINDOWS;
    }
    else if (SystemInfoRt.isLinux) {
      return OS.LINUX;
    }
    else if (SystemInfoRt.isUnix) {
      return OS.GENERIC_UNIX;
    }
    else {
      throw new UnsupportedOperationException("Unsupported OS:" + SystemInfoRt.OS_NAME);
    }
  }
..

Как видите, основная логика находится в другом классе:

com.intellij.openapi.util.SystemInfoRt

который и отвечает за определение текущей ОС из переменных окружения.

Основная логика класса SystemInfoRt выглядит следующим образом:

 ..
 public static final String OS_NAME;
 public static final String OS_VERSION;

  static {
    String name = System.getProperty("os.name");
    String version = System.getProperty("os.version").toLowerCase(Locale.ENGLISH);

    if (name.startsWith("Windows") && name.matches("Windows \\d+")) {
      // for whatever reason, JRE reports "Windows 11" as a name and "10.0" as a version on Windows 11
      try {
        String version2 = name.substring("Windows".length() + 1) + ".0";
        if (Float.parseFloat(version2) > Float.parseFloat(version)) {
          version = version2;
        }
      }
      catch (NumberFormatException ignored) { }
      name = "Windows";
    }

    OS_NAME = name;
    OS_VERSION = version;
  }

  private static final String _OS_NAME = OS_NAME.toLowerCase(Locale.ENGLISH);
  public static final boolean isWindows = _OS_NAME.startsWith("windows");
  public static final boolean isMac = _OS_NAME.startsWith("mac");
  public static final boolean isLinux = _OS_NAME.startsWith("linux");
  public static final boolean isFreeBSD = _OS_NAME.startsWith("freebsd");
  public static final boolean isSolaris = _OS_NAME.startsWith("sunos");
  public static final boolean isUnix = !isWindows;
  public static final boolean isXWindow = isUnix && !isMac;
..

Казалось бы все ОК и проблемы не видно.

Для проверки я создал простенький shebang-скрипт (да Java теперь тоже так умеет), в который вставил логику из класса SystemInfoRt:

#!/usr/local/openjdk24/bin/java --source 11

import java.util.Locale;
public class batchjob {

final static class SystemInfoRt {
  public static final String OS_NAME;
  public static final String OS_VERSION;

  static {
    String name = System.getProperty("os.name");
    String version = System.getProperty("os.version")
                             .toLowerCase(Locale.ENGLISH);

    if (name.startsWith("Windows") && name.matches("Windows \\d+")) {
      // for whatever reason, JRE reports "Windows 11" as a name and 
      // "10.0" as a version on Windows 11
      try {
        String version2 = name.substring("Windows".length() + 1) + ".0";
        if (Float.parseFloat(version2) > Float.parseFloat(version)) {
          version = version2;
        }
      }
      catch (NumberFormatException ignored) { }
      name = "Windows";
    }

    OS_NAME = name;
    OS_VERSION = version;
  }

  private static final String _OS_NAME = OS_NAME.toLowerCase(Locale.ENGLISH);
  public static final boolean isWindows = _OS_NAME.startsWith("windows");
  public static final boolean isMac = _OS_NAME.startsWith("mac");
  public static final boolean isLinux = _OS_NAME.startsWith("linux");
  public static final boolean isFreeBSD = _OS_NAME.startsWith("freebsd");
  public static final boolean isSolaris = _OS_NAME.startsWith("sunos");
  public static final boolean isUnix = !isWindows;
  public static final boolean isXWindow = isUnix && !isMac;

  public static final boolean isJBSystemMenu = isMac 
          && Boolean.parseBoolean(System
             .getProperty("jbScreenMenuBar.enabled", "true"));

  public static final boolean isFileSystemCaseSensitive =
    isUnix && !isMac || "true".equalsIgnoreCase(System
             .getProperty("idea.case.sensitive.fs"));

  private SystemInfoRt() {}
}

    public static void main(String[] args) {
        System.out.println("name: '" + System.getProperty("os.name")+"'");
	    System.out.println("unix:" + SystemInfoRt.isUnix);
    }
}

Запуск показал что логика рабочая, название ОС и признак isUnix определяются корректно:

Так как же тогда получилось что правильная логика не работает?

Все опросто:

версия класса в релизной версии отличается от версии в репозитории.

Чтобы в этом убедиться, достаточно декомпилировать PathManager.class из релизной сборки Idea:

Как видите проверки на isUnix тут нет:

 ..
 else if (SystemInfoRt.isUnix) {
      return OS.GENERIC_UNIX;
    }
 ..

Что и порождает эту искусственную ошибку.

Исправление

Проблема найдена, что уже неплохо, но к сожалению чтобы ее исправить стандартным путем необходимо:

• внести правку в код класса PathManager;

• пересобрать как минимум библиотеку, в которой этот класс находится, как максимум — среду целиком;

• скопировать обновленную библиотеку в дистрибутив Idea, либо использовать собранную кастомную версию.

Помимо того что все правки, внесенные таким способом удалятся при следующем обновлении Idea, есть еще проблема самой сборки:

в Idea давно присутствуют нативные библиотеки, поэтому полная сборка из исходников под FreeBSD представляет определенную проблему.

Да, можно попробовать собрать Idea и под Linux, если у вас есть возможность выкачать ~20Гб исходного кода и время для того чтобы развернуть весь тулчейн для сборки — вперед, это налучший вариант для долгосрочного сопровождения.

К сожалению в моем случае нужно было какое-то решение «здесь и сейчас», времени и сил для развертывания полноценной сборки всей Idea из исходников не было.

Так что мы пойдем другим путем ультрахардкора:

Java позволяет частичную пересборку с использованием готовой бинарной сборки с совпадающими классами.

Это означает что можно взять обновленную версию PathManager.java из репозитория и собрать локально только один этот класс, подложив в CLASSPATH библиотеки из бинарной сборки Idea.

Целиком скрипт сборки выглядит так:

#!/usr/local/bin/bash
# путь к распакованной Intellij Idea
export IDEA=/opt/app/idea-IC-251.25410.129/lib
# скачивание рабочей версии PathManager.java
curl https://raw.githubusercontent.com/JetBrains/intellij-community/refs/heads/master/platform/util/src/com/intellij/openapi/application/PathManager.java -o PathManager.java
# создаем каталоги пакетов
mkdir -p com/intellij/openapi/application
# компилируем класс с использованием библиотек из Idea
javac -cp .:$IDEA/annotations.jar:$IDEA/util.jar:$IDEA/util_rt.jar:$IDEA/util-8.jar com/intellij/openapi/application/PathManager.java 
# создаем .jar-файл с пропатченной версией
jar cf patch.jar com/intellij/openapi/application/*.class

В результате выполнения в текущем каталоге должен появиться файл patch.jar с исправленной версией PathManager.

Но сборка патча лишь половина проблемы, вторая половина — как его теперь установить в текущую бинарную копию Idea не привлекая внимание санитаров.

Установка патча

В Java есть т. н. «иерархия загрузчиков классов» и учет порядка библиотек (JAR-файлов), указываемых в CLASSPATH при запуске приложения.

Это означает, что если указать JAR с патчем в списке CLASSPATH до JAR с оригиналом класса, то будет загружен и инициализирован класс из патча, а оригинал — пропущен.

В скрипте запуска Idea (файл bin/idea.sh) есть перечисление стартовых библиотек:

..
CLASS_PATH="$IDE_HOME/lib/platform-loader.jar"
CLASS_PATH="$CLASS_PATH:$IDE_HOME/lib/util-8.jar"
CLASS_PATH="$CLASS_PATH:$IDE_HOME/lib/util.jar"
CLASS_PATH="$CLASS_PATH:$IDE_HOME/lib/app-client.jar"
..

Так что для установки патча достаточно будет скопировать файл с патчем в каталог lib и добавить его в этот список до оригинала util-8.jar.

Выглядит это как-то так:

..
CLASS_PATH="$IDE_HOME/lib/platform-loader.jar"
# наш адский патч
CLASS_PATH="$CLASS_PATH:$IDE_HOME/lib/patch.jar"
# библиотека с оригиналом класса, который будет пропущен при загрузке
CLASS_PATH="$CLASS_PATH:$IDE_HOME/lib/util-8.jar"
CLASS_PATH="$CLASS_PATH:$IDE_HOME/lib/util.jar"
CLASS_PATH="$CLASS_PATH:$IDE_HOME/lib/app-client.jar"
..

Ну и собственно результат:

Применимость

Это точно не последний случай, когда приходится вручную исправлять софт замечательной компании Jetbrains — альтернативные ОС там действительно не любят, поэтому описанная технология «кровавого патчинга» будет применяться во славу высоких технологий и прогресса еще не раз и не два.

Но мы BSD‑шники привычные — таков путь.

Добавлю, что возможность переопределения и частичной перекомпиляции чужих классов — очень мощный инструмент, который неоднократно меня выручал, поэтому вам точно стоит о нем знать.

Таким способом можно например вставлять отладочные строки внутрь классов Spring Framework, можно менять логику поведения классов из чужих библиотек и все это без заморочек с полной релизной сборкой, рефлексией, модификацией байт-кода или технологией Java Agent.

Этим же методом мы неоднократно делали бекпорт нужных фич, которые реализовывались только в новой версии библиотеки и никогда бы не появились в старой.

Собственно описываемый выше патч — пример такого бекпорта функционала, реализованного в текущей develop‑версии, но еще не перенесенного в релизную.

К сожалению известно о таком методе лишь очень небольшому количеству современных разработчиков, так что надеюсь этой статьей приоткрыл некоторым из читателей новые горизонты разработки на Java.

PS

Оригинал статьи как обычно в нашем блоге, опыт эксплуатации Idea в BSD‑системах — большой, поэтому смогу помочь и другим BSD‑шникам, если кому‑то из них вдруг придет в голову заниматься разработкой на BSD.

Контакты в профиле.