Eclipse, NetBeans и наследие: где они остались и почему

Это не некролог. Про Eclipse и NetBeans принято писать в прошедшем времени, и статистика вроде бы даёт на это право: в Stack Overflow Developer Survey 2025 VS Code набирает 75,9%, а Eclipse — около 7%. В Java Developer Productivity Report 2025 от JRebel, где выборка целиком состоит из Java-разработчиков, IntelliJ IDEA берёт 84%, VS Code — 31%, Eclipse — 28% (годом раньше было 39%). NetBeans в обоих исследованиях болтается в районе нескольких процентов.

Но у этих цифр есть два дна.

Первое: опросы меряют оболочку, а не код. Компилятор Eclipse запускается на каждом сервере Apache Tomcat, который компилирует JSP. Движок Eclipse JDT обслуживает автодополнение Java в VS Code у миллионов людей, которые Eclipse в глаза не видели. Eclipse CDT — каркас, внутри которого ST, Texas Instruments и NXP поставляют свои тулчейны для микроконтроллеров. Проект «умер» ровно в том смысле, в каком «умер» WebKit.

Второе: самоотбор выборки. И SO, и JRebel опрашивают людей, которые читают блоги про разработку и заполняют формы. Программист, который двадцать лет пишет COBOL под z/OS в IBM Developer for z/OS, в такую выборку не попадает почти никогда. Это не значит, что Eclipse недооценён — он действительно потерял мейнстрим. Это значит, что абсолютное число установок и абсолютное число статей про инструмент связаны слабее, чем кажется.

Разберёмся по порядку: что это за архитектура, что в ней было по-настоящему хорошо, почему она всё равно проиграла, где осталась и что делать, если вы сидите в ней сегодня.

Как мы сюда пришли

Из этой ленты стоит вынести не даты, а форму. Eclipse и NetBeans — оба продукты крупного вендора, оба потом отданы фонду. Разница в том, что Eclipse получил собственный фонд с членскими взносами и корпоративной поддержкой, а NetBeans — общую инфраструктуру Apache и чисто волонтёрскую разработку. Отсюда разная скорость и разная судьба.

Eclipse — это не IDE, это контейнер приложений, который притворяется IDE

Ключ ко всему остальному. То, что вы скачиваете с eclipse.org, — сборка примерно из шестидесяти независимых проектов, собранных «поездом релизов», работающая поверх реализации OSGi под названием Equinox. Никакого монолитного «Eclipse» не существует: есть рантайм модулей и набор бандлов, которые в нём живут.

OSGi: динамические модули за пятнадцать лет до контейнеров

OSGi решает задачу, которую Java не решала до модулей JPMS (Java 9, 2017), а по-настоящему не решила и после: несколько версий одной библиотеки в одной JVM, с явными границами видимости и с возможностью установить, обновить и удалить модуль без перезапуска процесса. Каждый бандл — обычный JAR, у которого в META-INF/MANIFEST.MF описано, что он экспортирует и что импортирует:

Bundle-SymbolicName: com.example.metrics.ui;singleton:=true
Bundle-Version: 2.4.0.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-21
Import-Package: org.osgi.framework;version="[1.10,2.0)",
 com.example.metrics.core;version="[2.0,3.0)"
Export-Package: com.example.metrics.ui.widgets;version="2.4.0"
Bundle-ActivationPolicy: lazy

Import-Package с диапазоном версий — это то, чего в classpath-мире нет в принципе: обычный Java-classpath плоский, первый найденный класс выигрывает, версии не существует. Резолвер OSGi строит граф зависимостей на пакетах, а не на архивах, и подставляет каждому бандлу собственный загрузчик классов с собственной видимостью.

У каждого бандла — явный жизненный цикл, и это не бюрократия, а то, что делает возможным «установить плагин без перезапуска»:

Ленивая активация — недооценённая вещь. У вас может быть установлено 400 бандлов, но в ACTIVE перейдут десятки: остальные проснутся, когда до них дойдёт дело. Это ровно та идея, к которой много лет спустя пришли Neovim с lazy.nvim (см. https://courses.digitable.life/post/editors/03-neovim-and-config/) и VS Code с activationEvents в package.json.

Extension points: декларативная композиция

Второй столп — механизм точек расширения. Бандл объявляет в plugin.xml, куда он подключается, а платформа инстанцирует класс только когда он реально понадобится:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
   <!-- добавляем пункт в контекстное меню редактора Java -->
   <extension point="org.eclipse.ui.menus">
      <menuContribution locationURI="popup:#CompilationUnitEditorContext?after=additions">
         <command commandId="com.example.tools.generateBuilder"
                  label="Сгенерировать Builder"
                  style="push">
            <visibleWhen checkEnabled="false">
               <!-- показываем только для файлов .java с непустым выделением -->
               <with variable="activeEditorId">
                  <equals value="org.eclipse.jdt.ui.CompilationUnitEditor"/>
               </with>
            </visibleWhen>
         </command>
      </menuContribution>
   </extension>

   <!-- собственно обработчик: класс загрузится только при первом вызове -->
   <extension point="org.eclipse.ui.handlers">
      <handler commandId="com.example.tools.generateBuilder"
               class="com.example.tools.internal.GenerateBuilderHandler"/>
   </extension>
</plugin>

Идея хороша: описание отделено от реализации, платформа читает XML при старте и не грузит байт-код. Проблема — в цене входа. Чтобы написать этот пункт меню, нужно знать locationURI, язык выражений visibleWhen, разницу между командой и хендлером, разницу между org.eclipse.ui.menus и устаревшим actionSets, и как всё это собирается через Tycho. Для сравнения — то же самое в VS Code:

{
  "contributes": {
    "commands": [{ "command": "tools.generateBuilder", "title": "Сгенерировать Builder" }],
    "menus": {
      "editor/context": [
        { "command": "tools.generateBuilder", "when": "editorLangId == java" }
      ]
    }
  }
}

Пятнадцать строк против пятидесяти, и никакого Tycho. Это не мелочь стиля — это разница между «за выходные написал расширение» и «неделю читал документацию платформы». Экосистема — функция от стоимости первого плагина, и Eclipse проиграл именно здесь.

SWT: правильная ставка, сделанная в неправильном десятилетии

Третий столп — тулкит. В 2001 году Swing рисовал всё сам и выглядел чужеродно на любой ОС, поэтому IBM написала SWT — тонкую обёртку над нативными виджетами: GTK на Linux, Win32 на Windows, Cocoa на macOS. Тогда это дало Eclipse решающее преимущество: он выглядел и работал как родное приложение, а NetBeans на Swing — как Java-программа.

Через двадцать лет ставка сыграла в минус. Нативность означает три реализации вместо одной, три набора багов и зависимость от чужих графических стеков. SWT привязан к GTK3; переход экосистемы Linux на GTK4 и Wayland идёт медленно и болезненно. HiDPI и дробное масштабирование годами были источником тикетов. Стилизация тем упирается в то, что нативный виджет нельзя перекрасить произвольно. А конкуренты тем временем ушли в web-рендеринг (Electron) или в собственный GPU-рендер (Zed, о котором в https://courses.digitable.life/post/editors/08-modern-editors/), где «нативность» перестала быть аргументом, потому что пользователи привыкли к неродному виду.

Что в Eclipse было по-настоящему великим: JDT и компилятор ECJ

Если из всего Eclipse оставить одну вещь, это будет JDT Core — и внутри него ECJ, Eclipse Compiler for Java. Это полноценный отдельный компилятор Java, не обёртка над javac, со своими свойствами, которых у javac нет.

Инкрементальность. ECJ построен вокруг модели дельт ресурсов: платформа сообщает, какие файлы изменились, JDT вычисляет транзитивно затронутые единицы компиляции и перекомпилирует только их. Практический эффект: на монолите в несколько тысяч классов сохранение файла даёт готовые .class за десятки-сотни миллисекунд, и Hot Code Replace подсовывает их в отлаживаемую JVM без перезапуска. Цикл «поправил — увидел» в Eclipse до сих пор один из самых коротких в Java-мире.

Устойчивость к ошибкам. ECJ компилирует код, который не компилируется. Метод с ошибкой получает тело, которое бросает Error при вызове, — остальной класс собирается нормально:

// Файл не компилируется целиком, но Eclipse всё равно выдаст .class:
public class OrderService {

    public BigDecimal total(Order order) {          // корректный метод
        return order.lines().stream()
                .map(OrderLine::amount)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
    }

    public void broken() {
        this.нетТакогоМетода();                      // ошибка компиляции
    }
}
// Вызов total() работает. Вызов broken() кинет java.lang.Error
// с текстом "Unresolved compilation problem". Тесты на total() можно
// запустить прямо сейчас, не дочинив broken().

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

Аннотационный анализ null. Задолго до Kotlin и до Optional-моды JDT умел @NonNull/@Nullable с внешними аннотациями для чужих библиотек (.eea-файлы) и полноценным потоковым анализом. Включается в .settings/org.eclipse.jdt.core.prefs, работает как дополнительный компилятор ошибок.

И самое интересное — где этот код живёт сегодня.

Три факта из этой картинки стоит проговорить прямо:

1. Tomcat. В lib/ любой поставки Tomcat лежит ecj-*.jar. JSP компилируются компилятором Eclipse — потому что он умеет работать в рантайме, без JDK на машине, и умеет компилировать по одному файлу. То есть ECJ крутится в проде у людей, которые про Eclipse не думали никогда.
2. VS Code. Расширение Language Support for Java by Red Hat — сердце официального Extension Pack for Java от Microsoft — это клиент к eclipse.jdt.ls, языковому серверу, собранному из JDT Core и запущенному headless. Автодополнение Java в VS Code — это Eclipse.
3. Встроенка. STM32CubeIDE, TI Code Composer Studio, NXP MCUXpresso, Renesas e2 studio — Eclipse CDT с вендорскими плагинами. А MPLAB X от Microchip построен, наоборот, на платформе NetBeans.

Вот как выглядит пункт 2 в динамике:

Заметьте, что случилось с точки зрения бизнес-модели: язык программирования перестал быть конкурентным преимуществом IDE. До LSP «поддержка Java» означала «купите продукт целиком». После LSP это означает «поставьте сервер». Eclipse отдал свой лучший актив в чужую оболочку — и это, пожалуй, самое честное объяснение, куда делись 39% доли.

Если вы сегодня пишете Java в VS Code, вот рабочий кусок settings.json, который настраивает именно этот сервер:

{
  // сервер — JVM-процесс, ему нужна своя память; на монорепо мало 1 ГБ
  "java.jdt.ls.vmargs": "-XX:+UseZGC -XX:MaxRAMPercentage=60 -Xmx4G -XX:+UseStringDeduplication",

  // несколько JDK: сервер сам запустится на 21, а проекты соберёт на нужной
  "java.configuration.runtimes": [
    { "name": "JavaSE-17", "path": "/usr/lib/jvm/temurin-17" },
    { "name": "JavaSE-21", "path": "/usr/lib/jvm/temurin-21", "default": true },
    { "name": "JavaSE-25", "path": "/usr/lib/jvm/temurin-25" }
  ],

  // форматирование берётся из того же XML, что и в Eclipse — общий стиль для смешанной команды
  "java.format.settings.url": "${workspaceFolder}/config/eclipse-formatter.xml",
  "java.format.settings.profile": "TeamStyle",

  // не индексировать сборочные каталоги — экономит минуты на большом проекте
  "java.import.exclusions": ["**/node_modules/**", "**/target/**", "**/build/**", "**/.git/**"],

  // «нулевой» режим сборки, если проект гигантский и вам нужен только просмотр
  // "java.server.launchMode": "LightWeight",

  "java.configuration.updateBuildConfiguration": "interactive",
  "java.saveActions.organizeImports": true
}

Строка java.format.settings.url — тот самый мост: она принимает экспорт форматтера Eclipse. Об этом ниже отдельно, потому что это ключ к сосуществованию IDE в одной команде.

Модель проекта: главная причина, по которой Eclipse ненавидят

Технически Eclipse силён. Больно с ним по другой причине — из-за модели воркспейса.

Eclipse старше Maven. Его модель проекта — .project (природа проекта и билдеры), .classpath (пути сборки) и .settings/*.prefs (настройки компилятора и форматтера) — проектировалась как первичная. Maven и Gradle появились позже и стали первичными сами, а Eclipse получил плагины-мосты: m2e для Maven, Buildship для Gradle. Мост генерирует .classpath из pom.xml. Пока вы его не трогаете — всё хорошо. Как только вы что-то сделали мышкой, две модели расходятся, и начинается «у меня работает».

IntelliJ прошёл ту же эволюцию и вышел из неё лучше: там модуль тоже свой, но импорт Gradle/Maven агрессивнее, а .idea/ по умолчанию хочется игнорировать целиком. NetBeans пошёл радикально и, на мой взгляд, правильнее всех: у него Maven-проект — это pom.xml, без промежуточных файлов вообще. Открыли папку — открыли проект. Ирония в том, что самая аккуратная модель оказалась у IDE с наименьшей долей рынка.

Что коммитить, а что нет

Практическое правило: всё, что влияет на результат сборки, живёт в pom.xml/build.gradle; всё остальное — производный кэш.

# --- Eclipse: производное состояние, генерируется импортом ---
.project
.classpath
.factorypath
.settings/
.metadata/
bin/
# --- NetBeans ---
nbproject/private/
nbactions.xml
# --- IntelliJ ---
.idea/
*.iml
# --- сборка ---
target/
build/

Возражение, которое вы услышите: «а как же общие настройки компилятора и форматтера?» Ответ: их место не в IDE, а в сборке. Смотрите следующий раздел.

Стиль кода: развязать IDE и правила форматирования

Самый частый способ поссорить команду — сделать форматирование свойством редактора. Один человек на Eclipse, второй на IntelliJ, третий на VS Code, и каждый коммит наполовину состоит из переставленных пробелов. Решение известное и скучное: правила задаёт сборка, IDE их только читает.

Экспортируем профиль из Eclipse (Preferences → Java → Code Style → Formatter → Export) в config/eclipse-formatter.xml, кладём в репозиторий и подключаем Spotless:

<!-- pom.xml -->
<plugin>
  <groupId>com.diffplug.spotless</groupId>
  <artifactId>spotless-maven-plugin</artifactId>
  <version>2.44.0</version>
  <configuration>
    <java>
      <!-- тот же движок форматирования, что внутри Eclipse и внутри jdt.ls -->
      <eclipse>
        <version>4.33</version>
        <file>${project.basedir}/config/eclipse-formatter.xml</file>
      </eclipse>
      <importOrder>
        <order>java,javax,jakarta,org,com,</order>
      </importOrder>
      <removeUnusedImports/>
      <formatAnnotations/>
    </java>
  </configuration>
  <executions>
    <execution>
      <!-- на CI падаем, локально чиним через mvn spotless:apply -->
      <goals><goal>check</goal></goals>
      <phase>verify</phase>
    </execution>
  </executions>
</plugin>

Дальше каждый настраивает свою IDE читать тот же XML:

Это работает и решает 90% межредакторных войн. Заодно отвечает на вопрос «а нужно ли коммитить .settings/»: не нужно.

Настройка Eclipse, которая реально влияет на жизнь

Львиная доля жалоб «Eclipse тормозит» — это либо дефолтная куча, либо индексация мусора.

eclipse.ini

Файл лежит рядом с исполняемым (на macOS — в Eclipse.app/Contents/Eclipse/). Порядок строк важен: всё после -vmargs уходит в JVM, всё до — в лаунчер.

-startup
plugins/org.eclipse.equinox.launcher_1.6.900.v20240613-2009.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.900.v20240613-2009
-product
org.eclipse.epp.package.java.product

# Явно указываем JVM — не полагаемся на JAVA_HOME.
# -vm ДОЛЖЕН идти до -vmargs и путь ДОЛЖЕН быть на отдельной строке.
-vm
/usr/lib/jvm/temurin-21/bin/java

-vmargs
# Куча: 2 ГБ — разумный минимум для реального проекта, 4-6 для монорепо.
-Xms2g
-Xmx6g
# ZGC даёт паузы в доли миллисекунды — UI перестаёт «залипать» на GC.
-XX:+UseZGC
-XX:+ZGenerational
# Метаспейс растёт от числа загруженных бандлов, а их сотни.
-XX:MaxMetaspaceSize=1g
-XX:+UseStringDeduplication
# Диагностика зависаний UI: лог, если поток SWT занят дольше 2 с.
-Dorg.eclipse.ui.monitoring.enabled=true
-Dorg.eclipse.ui.monitoring.longEventErrorThreshold=2000
# HiDPI на Linux при дробном масштабе.
-Dswt.autoScale=200
-Dswt.autoScale.method=nearest

Три ошибки, которые тут делают чаще всего: пишут -vm /path/java в одну строку (не работает), ставят -Xmx до -vmargs (игнорируется), выставляют -Xmx больше физической памяти и получают своп вместо ускорения.

Горячие клавиши, ради которых стоит потерпеть

У Eclipse есть несколько по-настоящему хороших находок. Ctrl+3 — универсальная строка команд, появившаяся раньше, чем «палитра команд» стала стандартом.

Ctrl+1 заслуживает отдельного слова: в Eclipse он работает не только на ошибках, но и как Quick Assist на корректном коде — «преобразовать в enhanced for», «разделить объявление и присваивание», «вынести в поле». Это ровно та механика, которую IntelliJ развил в Alt+Enter.

Диагностика «Eclipse завис»

Порядок действий, который экономит часы:

# 1. Кто занял UI-поток? Дамп потоков живого процесса.
jcmd $(pgrep -f org.eclipse.equinox.launcher) Thread.print > /tmp/eclipse-threads.txt
grep -A 40 '"main"' /tmp/eclipse-threads.txt      # main == UI-поток SWT

# 2. Что на самом деле происходило — лог самой платформы.
tail -n 200 "$WORKSPACE/.metadata/.log"

# 3. Сколько памяти реально нужно.
jcmd $(pgrep -f org.eclipse.equinox.launcher) GC.heap_info

# 4. Ядерный вариант: пересобрать конфигурацию бандлов, не трогая проекты.
./eclipse -clean -refresh

# 5. Настоящее лечение при порче воркспейса — новый воркспейс и переимпорт.
#    Работает потому, что весь смысл проекта живёт в pom.xml, а не в .metadata.

Пятый пункт — проверка того, правильно ли у вас устроен репозиторий. Если удаление воркспейса означает потерю дня, значит, конфигурация сборки утекла в IDE, и это надо чинить.

NetBeans: чем он был хорош и что от него осталось

NetBeans сегодня — Apache NetBeans, четыре релиза в год, версия 30 вышла в мае 2026, версия 31 на подходе. Это живой проект, но с маленькой командой и без корпоративного спонсора: Oracle передал его Apache в 2016 году, полностью выйдя из управления.

Три вещи, которые NetBeans делал лучше всех, и это не ностальгия:

1. Maven как первоклассная модель. В NetBeans нет импорта Maven-проекта — есть открытие pom.xml. Нет генерируемых .classpath, нет рассинхронизации, нет кнопки «Reimport». Изменили pom.xml — IDE перечитала. Это единственная из четырёх больших IDE, где вопрос «почему IDE видит зависимость, а Maven нет» не возникает структурно.

2. Matisse — конструктор Swing-форм. Он использовал модель GroupLayout вместо абсолютных координат, генерировал читаемый код и корректно вёл себя при смене размеров и локализации. До сих пор это лучший визуальный построитель Java-десктопа. Ниша умерла вместе с десктопной Java, но в вузах и в промышленной автоматике живёт.

3. Встроенный профайлер. Профайлер NetBeans — прямой родственник VisualVM, встроен в IDE без отдельной лицензии. Для быстрого «где горит CPU» на локальной JVM этого хватает.

Настройка живёт в etc/netbeans.conf (или в ~/.netbeans/<версия>/etc/netbeans.conf):

# Каталог пользовательских данных и кэша — вынесите кэш на быстрый диск
netbeans_default_userdir="${DEFAULT_USERDIR_ROOT}/30"
netbeans_default_cachedir="${DEFAULT_CACHEDIR_ROOT}/30"

# Явный JDK для самой IDE (проекты могут собираться другим)
netbeans_jdkhome="/usr/lib/jvm/temurin-21"

netbeans_default_options="-J-XX:+UseZGC \
  -J-Xms1g -J-Xmx4g \
  -J-XX:MaxMetaspaceSize=768m \
  -J-Dapple.laf.useScreenMenuBar=true \
  -J-Dsun.java2d.dpiaware=true \
  -J-Dsun.java2d.uiScale=2 \
  --add-opens=java.base/java.net=ALL-UNNAMED \
  --add-opens=java.base/java.lang.ref=ALL-UNNAMED"

Префикс -J — не опечатка: он говорит лаунчеру передать аргумент в JVM. --add-opens нужны потому, что Swing-платформа NetBeans лезет во внутренности JDK, а модульная система с Java 17 это запрещает по умолчанию.

Честная оценка: NetBeans стоит рассматривать, если вы преподаёте Java, ведёте небольшой Maven-проект или работаете с Java-десктопом. Во всех остальных случаях меньший плагин-экосистема, более медленный отклик на новые версии JDK и меньшее сообщество перевесят архитектурную аккуратность.

Почему они проиграли — по-честному, без «плохого UI»

«Тормозной» и «уродливый» — плохие объяснения: Eclipse 3.x был быстрее современного IntelliJ на тогдашнем железе, а внешний вид дело поправимое. Настоящих причин четыре.

Причина №1 — in-process модель расширения. В Eclipse плагин — это код в вашей JVM с полным доступом ко всему. Мощно и опасно: криво написанный плагин вешает UI-поток, и виноват в глазах пользователя Eclipse. VS Code с самого начала вынес расширения в отдельный процесс (Extension Host) и общается с ними по JSON-RPC — расширение физически не может заблокировать отрисовку. Это архитектурное решение, за которое заплатили ограничениями API, и оно окупилось.

Причина №2 — отсутствие владельца UX. Поезд релизов — гениальный инженерный механизм (шестьдесят проектов синхронно выпускают согласованные версии четыре раза в год), но у него нет продуктового менеджера. Отсюда три места, где настраивается кодировка, и диалог «New Project» с двадцатью вариантами.

Причина №3 — LSP обесценил главный актив. Eclipse торговал «мы лучше всех понимаем Java». После 2016 года это понимание стало переносимым.

Причина №4 — экономика. JetBrains берёт деньги и на них нанимает людей, которые целый год шлифуют один диалог. Бесплатный фонд на членских взносах так не может: взносы идут в инфраструктуру и в проекты, интересные членам фонда, а не в полировку окна настроек.

Ту же мысль полезно увидеть как карту позиционирования:

Правый верхний угол занят одним игроком, и он платный. Левый верхний — самое интересное место: VS Code с jdt.ls подобрался туда, где раньше сидел только Eclipse, но с более живой экосистемой. Именно этот переход и съел долю.

Экономика: посчитаем честно

Аргумент «Eclipse бесплатный» звучит убедительно, пока его не посчитать.

Порядок цен на 2026 год: IntelliJ IDEA Ultimate — около 719 долларов на пользователя в год для организации и около 199 для физического лица (прайс JetBrains, проверяйте актуальные цифры — они меняются). Возьмём команду из 100 разработчиков.

Теперь встречный счёт. Возьмём полную стоимость разработчика для компании 60 $/час (это консервативно). Год — примерно 1800 рабочих часов. Если IDE экономит 30 минут в неделю на человека (одна нормальная автоматическая инспекция плюс один рефакторинг вместо ручного), это 22 часа в год, то есть около 1300 $. При цене лицензии 719 $ точка безубыточности — примерно 17 минут экономии в неделю.

Иначе говоря: экономический аргумент почти всегда не в пользу «бесплатного». Но экономика — не единственный аргумент. Реально Eclipse удерживают три вещи, которые в таблицу не помещаются: отсутствие процедуры закупки, требования по офлайн-работе и запрет телеметрии, и наличие плагина, которого нет больше нигде.

Где Eclipse и NetBeans действительно остались

Не «по инерции», а потому что альтернативы нет или она хуже.

1. Встраиваемые системы. STM32CubeIDE (Eclipse CDT), TI Code Composer Studio, NXP MCUXpresso, Renesas e2 studio, Xilinx Vitis — все на Eclipse; MPLAB X — на NetBeans. Вендору нужен каркас с готовым редактором C, отладчиком поверх GDB, системой сборки и лицензией, позволяющей поставлять закрытые плагины (EPL это разрешает, GPL — нет). Eclipse даёт всё это бесплатно и без копилефта на ваш код.

Но и здесь фронт двигается: и ST, и Microchip уже поставляют расширения для VS Code, а STM32CubeMX научился генерировать нативные CMake-проекты, минуя IDE. Через несколько лет вендорские сборки Eclipse, скорее всего, останутся только там, где к ним привязана сертификация.

2. Мейнфреймы и корпоративная Java. IBM Developer for z/OS — разработка COBOL и PL/I под z/OS в Eclipse, с редактированием датасетов, JCL и отладкой на живом мейнфрейме. SAP ABAP Development Tools — единственный современный способ писать ABAP. Здесь Eclipse не «остался» — он пришёл как модернизация вместо зелёных терминалов и продолжает активно развиваться.

3. Моделирование и MBSE. Стек EMF → Xtext → Sirius → Papyrus/Capella. Если вам нужен графический редактор архитектуры по стандарту Arcadia или SysML с генерацией кода из модели — за пределами Eclipse просто нет ничего сопоставимого. Это самая здоровая из оставшихся ниш.

4. Регулируемые и изолированные контуры. Госсектор, оборонка, банки: утверждённые списки ПО, отсутствие интернета на рабочем месте, запрет телеметрии. Eclipse ставится с офлайн-зеркала p2, его исходники можно предъявить аудитору, а лицензия EPL не требует ни с кем разговаривать.

5. Образование. NetBeans и BlueJ в вузах — потому что бесплатно навсегда, ставится одним файлом и не требует аккаунта.

6. Легаси-кодовые базы. Ant-сборки, WebSphere и WebLogic, JSF, Struts, кастомные кодогенераторы, завязанные на билдеры Eclipse. Миграция здесь стоит реальных денег, а выгода неочевидна.

Дерево решений, если вы прямо сейчас в такой ситуации:

Обратите внимание на два красных узла: самая частая ошибка миграции — начать с IDE. Пока сборка и стиль не вынесены из редактора, смена редактора превращается в катастрофу на ровном месте.

Сравнение без фанатизма

Подробнее про IntelliJ — в https://courses.digitable.life/post/editors/06-jetbrains/, про VS Code и devcontainers — в https://courses.digitable.life/post/editors/05-vscode/, сводная таблица по всем инструментам трека — в https://courses.digitable.life/post/editors/10-comparison/.

Типичные ошибки

Ошибка 1. Считать .metadata ценностью. Воркспейс — кэш. Если его потеря болезненна, у вас проблема с репозиторием, а не с Eclipse.

Ошибка 2. Править Build Path мышкой в Maven-проекте. m2e перезатрёт правку при следующем обновлении проекта, а CI не увидит её никогда. Любая зависимость — только в pom.xml.

Ошибка 3. Коммитить .settings/ «чтобы у всех был одинаковый стиль». Работает ровно до первого человека на IntelliJ. Стиль — в Spotless.

Ошибка 4. Ставить плагины из маркетплейса в вендорскую сборку. STM32CubeIDE — это протестированный набор бандлов конкретных версий. Установка постороннего плагина может подтянуть другую версию общей зависимости, сломать резолв OSGi и превратить IDE в кирпич. Держите вендорскую IDE в неприкосновенности, а общий инструментарий — в отдельной установке.

Ошибка 5. Оставлять дефолтную кучу. -Xmx по умолчанию рассчитан на демонстрацию, а не на ваш монорепо. Половина жалоб на тормоза лечится строчкой в eclipse.ini.

Ошибка 6. Не исключать сборочные каталоги из индексации. target/, build/, node_modules/, распакованные WAR — индексатор честно обойдёт всё, что вы ему дали.

Ошибка 7. Один воркспейс на всё. Eclipse деградирует нелинейно с числом открытых проектов. Воркспейс на продукт, а не на компанию. Проекты, с которыми не работаете сейчас, — Close Project (Ctrl+3 → «Close Unrelated Projects»).

Ошибка 8. Мигрировать всех разом. Пилот на 5 человек, две недели, зафиксированные критерии («сборка проходит», «отладка работает», «diff не шумит») — и только потом остальные.

Ошибка 9. Считать, что «Eclipse мёртв», и не проверять факты под задачу. Если вам нужен редактор моделей SysML или разработка под z/OS, «мёртвый» Eclipse — единственный работающий вариант.

Ошибка 10. Переносить привычки один в один. Раскладка Eclipse в IntelliJ доступна (Settings → Keymap → Eclipse), в VS Code есть расширение Eclipse Keymap. Это хорошая подпорка на месяц. Но если оставить её навсегда, вы не получите Alt+Enter, Shift+Shift и постфиксные шаблоны — то есть заплатите за IntelliJ и не воспользуетесь им.

Мини-итог

• Eclipse — не IDE, а OSGi-контейнер, в котором IDE — одно из приложений. Отсюда и сила (вендорские сборки, RCP-приложения, модульность), и слабость (порог входа, отсутствие владельца UX).
• Лучшее, что в нём есть, — JDT Core с компилятором ECJ: инкрементальный, устойчивый к ошибкам, с анализом null. Этот код сегодня работает в Tomcat и в VS Code, обслуживая на порядок больше разработчиков, чем сама IDE.
• NetBeans архитектурно аккуратнее в модели проекта (pom.xml как единственный источник правды) и до сих пор непревзойдён в конструкторе Swing-форм, но живёт на волонтёрских силах и проигрывает по темпу.
• Проиграли они не из-за внешнего вида, а из-за in-process модели плагинов, размытого управления, появления LSP и того, что полировку UX кто-то должен оплачивать.
• Экономически «бесплатная IDE» почти никогда не выигрывает: точка безубыточности коммерческой лицензии — около 17 минут сэкономленного времени в неделю. Настоящие причины остаться — уникальные плагины, офлайн-контур и процедуры закупки.
• Живые ниши: встроенка, мейнфреймы и ABAP, MBSE-моделирование, регулируемые контуры, образование, тяжёлое легаси.
• Если мигрируете — сначала вынесите сборку в Maven/Gradle и стиль в Spotless, и только потом меняйте редактор. В обратном порядке будет дорого и больно.

Источники

• Eclipse IDE — New & Noteworthy 2026-06 (4.40) — что реально меняется в поезде релизов
• Eclipse IDE Simultaneous Release — как устроен квартальный цикл
• OSGi Core Specification — жизненный цикл бандла и модель резолвинга
• eclipse.jdt.ls и vscode-java — JDT как языковой сервер
• Eclipse Compiler for Java (JDT Core) — исходники ECJ
• Apache NetBeans — релизы и документация
• Apache NetBeans Release Schedule — квартальный цикл
• Stack Overflow Developer Survey 2025 — Technology — общая доля редакторов
• JRebel Java Developer Productivity Report 2025 — срез именно по Java
• Language Server Protocol Specification — то, что изменило правила игры
• Spotless — форматирование как часть сборки
• Eclipse Tycho — сборка OSGi-бандлов и RCP через Maven
• Eclipse Theia — что стало с идеей платформы в вебе
• Erich Gamma, Kent Beck. Contributing to Eclipse — каноническая книга про модель плагинов, устарела технически, но не концептуально

Что дальше

Мы прошли путь от модальных редакторов до тяжёлых платформ и увидели, почему поколение Eclipse и NetBeans уступило место. Логичное продолжение — посмотреть на тех, кто пришёл следом и учится на этих ошибках: редакторы с GPU-рендерингом, встроенной коллаборацией и внимательным отношением к задержке ввода.

Zed, Sublime Text, Atom-подобные и новая волна редакторов