Введение
Когда я работал в одной зарубежной компании, мне поставили задачу мигрировать COBOL-систему расчета инвойсов с мейнфрейма на Java. Она звучала довольно просто: «Нужно переписать старый COBOL-код на Java, чтобы система жила дальше».
Я тогда подумал, что это будет очередная рутина - взять дремучее легаси, аккуратно переложить его на современную версию Java, возможно, чуть подчистить архитектуру, внести небольшие косметические правки и закрыть задачу. В голове уже созрел рабочий план: пара итераций по автогенерации кода с помощью нейронки и готово. В общем, казалось, что ничего особенного.
Каково же было моё удивление, когда я увидел реальные объёмы и связанность компонентов этого легаси. Сотни модулей на COBOL, вызывающие друг друга, десятки лет эволюции, copybook«и, которые тянутся через полсистемы, логика, размазанная между PERFORM, GO TO и неочевидными условиями. Стало ясно, что весь этот код физически не поместится в контекст ни одной из существующих нейронок, а даже если и поместится — понять его целиком она не сможет. Отсюда следует, что нужно было придумать какое‑то оригинальное нетривиальное решение для данной инженерной задачи. Именно в этот момент и возникло желание поделиться накопленным опытом в данной статье. Не как универсальным рецептом, а как инженерным путём — с ошибками, тупиками и выводами, потому что рано или поздно подобная задача может возникнуть еще у кого-либо: в банках, телекоме, страховании, госсекторе.
Первая попытка — вручную, «по-честному»
Сначала я решил по-честному попробовать переписать хотя бы один модуль вручную. Взял относительно небольшой COBOL-файл, начал читать PROCEDURE DIVISION, разбираться в WORKING STORAGE и FILE STORAGE, искать, откуда приходят данные и куда они потом уходят.
Очень быстро выяснилось, что:
один модуль почти никогда не живёт сам по себе;
за ним тянется цепочка copybook’ов;
бизнес-логика зависит от глобального состояния;
понимание потока выполнения требует держать в голове полпрограммы.
Через несколько дней стало очевидно: даже если переписывать идеально, этот подход не приведёт к результату за разумное время. Слишком медленно, слишком дорого и слишком рискованно.
Вторая попытка — с помощью AI
Следующим шагом стало использование нейронок. Казалось логичным: COBOL — текст, Java — текст, значит, можно просто транслировать исходники кусками. На маленьких фрагментах это даже выглядело многообещающе: нейронка аккуратно превращала DISPLAY в вызовы логгера, IF — в if, иногда даже приводила код в приличный вид.
Но стоило попробовать применить этот подход не к игрушечному, а к реальному коду, как вскрылись ограничения:
AI терял контекст между файлами;
copybook’и интерпретировались каждый раз по-разному;
сложные PERFORM THRU разваливались;
один и тот же вход мог давать разный результат.
Самое неприятное — результат нельзя было формально проверить. Код выглядел правдоподобно, но уверенности, что бизнес‑логика сохранена полностью, не было. Для business critical системы это означало экстремально высокую вероятность наличия ошибок, что недопустимо.
Осознание проблемы
В какой-то момент стало ясно, что проблема не в COBOL, не в Java и даже не в инструментах трансляции кода. Проблема в том, что я пытался мигрировать текст, а не язык программирования.
COBOL — это формальный язык со строгой грамматикой и предсказуемой структурой. Пока транслятор не понимает эту структуру, любая миграция либо превращается в ручной труд, либо остаётся вероятностной.
Почему ANTLR — основа надёжной миграции
После того как стало ясно, что без формального понимания COBOL дальше не продвинуться и задача миграции сводится к практическому инженерному вопросу: как вообще должна выглядеть а��хитектура такого транслятора COBOL кода ?
Важно было не просто «распарсить код», а выстроить процесс, который:
масштабируется на сотни и тысячи COBOL модулей;
даёт воспроизводимый результат;
позволяет проверять корректность миграции;
не привязан жёстко к конкретной версии Java или COBOL-диалекту.
Вот здесь и появляется парсер ANTLR (ANother Tool for Language Recognition), который оказывается удобной точкой сборки для такой архитектуры, а также отвечает всем указанным требованиям.
ANTLR является генератором лексеров и парсеров, который позволяет формально описать транслируемый язык и получать его структурное представление.
Архитектура ANTLR-подхода к миграции
В упрощённом виде пайплайн миграции выглядит так:
Каждый этап решает свою задачу и изолирован от остальных. Это принципиально важно: ошибки и изменения на одном уровне не должны «протекать» дальше по пайплайну.
1. Preprocessing: подготовка COBOL-кода
До того, как ANTLR вообще сможет что-либо разобрать, COBOL-код нужно привести в форму, пригодную для парсинга. На практике это означает:
обработку COPY и REPLACING;
разворачивание copybook’ов в единый текст;
работу с fixed-format (колонки 1-6, 7, 8-72);
нормализацию кодировки и строк.
Этот этап часто недооценивают, но именно здесь отсеивается значительная часть проблем.
Важно понимать: ANTLR парсит уже «собранный» COBOL, а не хаотичный набор файлов.
2. Грамматика COBOL
В основе всего лежит грамматика. ANTLR-грамматика описывает:
структуру DIVISION / SECTION / PARAGRAPH;
синтаксис управляющих конструкций (IF, EVALUATE, PERFORM);
объявления данных в DATA DIVISION;
специфические конструкции диалектов (CICS, EXEC SQL и т. д.).
Ключевой момент:
грамматика — это не эвристика и не «примерное понимание языка», а формальное описание, по которому ANTLR строит парсер.
Это принципиальное отличие от AI-подхода, где понимание языка вероятностное.
3. Lexer и Parser
На основе грамматики ANTLR генерирует:
лексер, который превращает текст в токены;
парсер, который строит parse tree.
На этом этапе:
выявляются синтаксические ошибки;
код получает чёткую структуру;
исчезает неоднозначность интерпретации.
Важно: parse tree — это ещё не то, с чем удобно работать. Это лишь отражение грамматики, а не смысла программы.
4. Построение AST (Abstract Syntax Tree)
Следующий шаг — преобразование parse tree в AST (Abstract Syntax Tree).
AST — это уже инж енерная модель программы, а не отражение грамматики. В AST:
объединяются логически связанные конструкции;
нормализуется управление потоком;
убираются синтаксические детали, не важные для семантики.
Например:
PERFORM PARAGRAPH превращается в узел вызова;
IF/ELSE — в единый условный блок;
группы данных — в иерархию структур.
Именно AST становится центральной точкой всей миграции.
5. Семантический анализ
После того как структура программы понятна, начинается самый важный этап — семантика.
Здесь решаются вопросы:
где объявлена переменная и в какой области видимости;
какие copybook’и реально используются;
какие данные модифицируются и где;
как устроен реальный control flow.
ANTLR сам по себе не делает семантический анализ, но он даёт идеальную основу для его реализации. В отличие от AI, здесь всё:
детерминировано;
трассируемо;
проверяемо.
6. Трансформация в Java
Только после этого имеет смысл переходить к генерации Java.
Преимущество ANTLR-подхода в том, что генерация:
не зависит от исходного текста;
опирается на структурную модель;
легко адаптируется под нужную архитектуру.
Типичные соответствия выглядят так:
COBOL record → Java class / record;
WORKING-STORAGE → state object;
PERFORM → метод или лямбда;
FILE-CONTROL → DAO / repository;
EXEC SQL → слой доступа к БД.
Важно, что правила генерации можно менять, не переписывая парсер и анализатор.
7. Проверяемость и воспроизводимость
Одно из главных преимуществ ANTLR-подхода — возможность проверки результата.
Поскольку:
парсинг детерминирован;
AST строится одинаково каждый раз;
генерация следует формальным правилам,
мы можем:
повторять миграцию сколько угодно раз;
находить полученную разницу в результатах;
автоматизировать тестирование;
уверенно утверждать, что поведение системы сохранено.
Это ровно то, чего не хватает AI-based подходам.
Пример реализации транслятора COBOL с использованием ANTLR-подхода
Далее покажу базовый пример реализации такого пайплайна миграции
Пример входной COBOL-программы:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "HELLO, WORLD".
STOP RUN.Maven: зависимости + генерация парсера:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>ru.alfastrah</groupId>
<artifactId>cobol-to-java-antlr</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
<antlr4.version>4.13.1</antlr4.version>
</properties>
<dependencies>
<dependency>
<groupId>org.antlr</groupId>
<artifactId>antlr4-runtime</artifactId>
<version>${antlr4.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.antlr</groupId>
<artifactId>antlr4-maven-plugin</artifactId>
<version>${antlr4.version}</version>
<executions>
<execution>
<goals>
<goal>antlr4</goal>
</goals>
<configuration>
<visitor>true</visitor>
<listener>false</listener>
<packageName>demo.cobol</packageName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>Упрощённая ANTLR-грамматика:
grammar CobolMini;
program
: identificationDivision procedureDivision EOF
;
identificationDivision
: IDENTIFICATION DIVISION '.' PROGRAM_ID '.' progName '.'
;
procedureDivision
: PROCEDURE DIVISION '.' statement*
;
statement
: displayStmt
| stopRunStmt
;
displayStmt
: DISPLAY stringLiteral '.'
;
stopRunStmt
: STOP RUN '.'
;
progName
: IDENTIFIER
;
stringLiteral
: STRING
;
IDENTIFICATION : [Ii][Dd][Ee][Nn][Tt][Ii][Ff][Ii][Cc][Aa][Tt][Ii][Oo][Nn] ;
PROGRAM_ID : [Pp][Rr][Oo][Gg][Rr][Aa][Mm]'-'[Ii][Dd] ;
PROCEDURE : [Pp][Rr][Oo][Cc][Ee][Dd][Uu][Rr][Ee] ;
DIVISION : [Dd][Ii][Vv][Ii][Ss][Ii][Oo][Nn] ;
DISPLAY : [Dd][Ii][Ss][Pp][Ll][Aa][Yy] ;
STOP : [Ss][Tt][Oo][Pp] ;
RUN : [Rr][Uu][Nn] ;
IDENTIFIER : [A-Za-z][A-Za-z0-9-]* ;
STRING : '"' (~["\r\n])* '"' ;
DOT : '.' ;
WS : [ \t\r\n]+ -> skip ;
Java: парсинг COBOL и генерация Java-класса (Visitor):
package ru.alfastrah;
import ru.alfastrah.cobol.CobolMiniBaseVisitor;
import ru.alfastrah.cobol.CobolMiniParser;
public class CodeGenVisitor extends CobolMiniBaseVisitor<Void> {
private String programName;
private final StringBuilder body = new StringBuilder();
@Override
public Void visitIdentificationDivision(CobolMiniParser.IdentificationDivisionContext ctx) {
programName = ctx.progName().getText();
return null;
}
@Override
public Void visitDisplayStmt(CobolMiniParser.DisplayStmtContext ctx) {
String literal = ctx.stringLiteral().getText();
body.append(" System.out.println(").append(literal).append(");\n");
return null;
}
@Override
public Void visitStopRunStmt(CobolMiniParser.StopRunStmtContext ctx) {
body.append(" return;\n");
return null;
}
public String toJavaSource() {
String className = (programName == null || programName.isBlank()) ? "CobolProgram" :programName;
return ""
+ "public class " + className + " {\n"
+ " public static void main(String[] args) {\n"
+ body
+ " }\n"
+ "}\n";
}
}Запуск: читаем COBOL, транслируем, выводим сгенерированный Java
package ru.alfastrah;
import ru.alfastrah.cobol.CobolMiniLexer;
import ru.alfastrah.cobol.CobolMiniParser;
import org.antlr.v4.runtime.*;
import org.antlr.v4.runtime.tree.ParseTree;
import java.nio.file.Files;
import java.nio.file.Path;
public class MigrateDemo {
public static void main(String[] args) throws Exception {
String cobol = Files.readString(Path.of("src/main/resources/sample.cob"));
CharStream input = CharStreams.fromString(cobol);
CobolMiniLexer lexer = new CobolMiniLexer(input);
CommonTokenStream tokens = new CommonTokenStream(lexer);
CobolMiniParser parser = new CobolMiniParser(tokens);
ParseTree tree = parser.program();
CodeGenVisitor gen = new CodeGenVisitor();
gen.visit(tree);
String java = gen.toJavaSource();
System.out.println(java);
}
}Что получится на выходе
public class HELLO {
public static void main(String[] args) {
System.out.println("HELLO, WORLD");
}
}Заключение
Оглядываясь назад, могу сказать, что миграция COBOL-системы с мейнфрейма на Java оказалась совсем вообще нетривиальной задачей, какой виделась в самом начале.
Ручной подход дал полезный, но очень дорогой опыт — он помог увидеть особенности транслируемого кода, но быстро упёрся в ограничения времени и масштаба. AI‑инструменты выглядели многообещающе и действительно помогали в мелочах, но как основа миграции они оказались слишком непредсказуемыми. Когда речь идёт о критической бизнес‑логике, «похоже на правду» — при миграции этого недостаточно.
Переломным моментом стало осознание простой вещи: COBOL — это язык программирования, а не просто текст. И, если мы хотим мигрировать систему надёжно, нам нужен инструмент, который понимает этот язык формально, а не вероятностно. Именно здесь ANTLR оказался тем самым недостающим элементом.
ANTLR не сделал задачу простой — миграция всё равно остаётся сложной инженерной работой. Но он сделал её контролируемой. Появилась структура, воспроизводимость, возможность проверять результат и масштабировать процесс. Исчезло ощущение, что мы каждый раз начинаем с нуля и надеемся, что в этот раз «прокатит».
Важно и то, что этот подход не противоречит современным инструментам. AI отлично вписывается в процесс и дополняет его — как помощник, как средство рефакторинга, как ускоритель работы разработчика. Но фундамент миграции, особенно для больших систем из финтеха, должен оставаться формальным и детерминированным.
В этой статье мне хотелось поделиться не «правильным» решением, а реальным инженерным опытом, который мне пришлось пройти на практике и собрать все подводные камни подобных трансляторов. Если кому‑то она поможет быстрее выбрать верное направление или избежать очевидных ловушек при миграции COBOL‑систем — значит, цель достигнута.
А если перед вами сейчас стоит похожая задача — не бойтесь сложности. С правильной архитектурой и инструментами она вполне решаема.
Комментарии (40)
kivan_mih
26.12.2025 16:55Вы либо уже долларовый миллионер, либо скоро им станете :)
gsaw
26.12.2025 16:55Тоже хотел об этом написать. Сейчас многие фирмы мигрируют с мэйнфрейма либо через аплифтинг, либо переписывая систему заново, либо переносят на SAP. И суммы платят там шестизначные, как минимум.
Хотя хз. Описанный подход, ближе к аплифтингу. Да, код становится понятным явистам, но опять же, вся эта завязка на zOS, текстовые файлы, MVS, мало, что поменяют, все равно нужны люди понимающие в энтих самых mainframe-х. Только что как промежуточный шаг, а потом все равно переписывать, модернизировать.
У нас лет десять назад пытались вместо COBOL-а писать модули на java. Мэйнфреймисткие админы хотели такую же систему версионирования, как и с COBOL модулями, что бы все было точно так же. Выходило все запутанным.
zVlad909
26.12.2025 16:55Привет коллега.
Сейчас многие фирмы мигрируют с мэйнфрейма
Сейчас это уже лет 30 как минимум. На Западе один перец прорачил что последний МФ будет выключен в 1995 году.
переписывая систему заново, либо переносят на SAP
В нашем случае вендор приложения, изначально написанного на Кобол, новую версию сделал на Java. Но это была не чистаю Java, а что-то промежуточное. Похоже они зная как их продукт был написан написали какой то "переходник" что ли. Мне программист один расскзавал кратко. Я запомнил что это была какая то собственная технология вендора для этого.
Многоие другие пользователи этого продукта (типа SAP) остались на МФ с последней версией на Коболе.
вся эта завязка на zOS, текстовые файлы, MVS,
Что Вы хотели сказать? Я не понял, что не так с файлами? Почему именно текстовыми? Что плохого в MVS?
все равно нужны люди понимающие в энтих самых mainframe-х.
Это совсем нен плохо и не сложно понимать "в энтих самых". Эти самые вполне себе живы и развиваются и еще долго будут развиваться. Переходить с них, особенно сейчас, нет никакого смысла. Только терять много денег и времени и оставаться даже не там же, а откатываться назад.
Второе приложение у нас переписывали по новой. Это была многосерийная трагедия. Последний мэйнфрэймный программист, который начинал это перписывание умер в начале прошедшего лета. Несколько команд несколько раз брались за это, бросали, снова брались.
Наконец выиучили что-то, руковолство плетками пользователей согнали с МФ. Они даже после уже наяала работы в новом приложении все равно паслись на МФ и просили до нового года хотя бы им оставить. Норуководство приказало мне остановить системы. Сейчас МФ стоит включенным, системы все down, лишь изредка запускаю их что-нибудь посмотреть из того о чем говорим здес на форуме.
У нас лет десять назад пытались вместо COBOL-а писать модули на java. Мэйнфреймисткие админы хотели такую же систему версионирования, как и с COBOL модулями, что бы все было точно так же. Выходило все запутанным.
Что значит система версионирование Cobol модулей и причем здесь админы мэйнфрэймовские? Я админ такой, мне все равно какую систему версионирования используют программисты что для Cobol что для JAVA. Это не админов задача вовсе. Возможно Вы имеете ввиду каких-нибудь админов прикладного уровня, не системого. Тогда да всякой ерунды могло быть. Конечгно Cobol в работе с модулями это не что может быть с Java и это надо было понимать и изменять подход.
P.S. Я знаю почему программисты радостно сбегали и сбегают с МФ. Потому на МФ им никто и никогда не даст полный доступ к системе, а на Windows and Linux они не мытьем так катанием выкруживают себ и administrator и root. Их конечно обкладывают всякими условностями, но в итоге они имею полный доступ.
На МФ программистом дают не полный доступ, а тот который только и нужен. Полный доступ зачастую даже у системщиков нет. У меня был полный. И я всегда помогал программистам если у них были трудности какие-либо. Конечно я не давал программистам "ковырятся" в системе, но все разумное если надо я им обеспечивал всегда, и даже больше.
Я знаю тип программистов, которые все пытаются писать сами, даже если это есть в системе и этим просто надо воспользоваться правильено. Это вот другая причина нелюбви МФ. Вместо писания своих поделушек надо было уметь находить и использовать системные возможности. Но и на МФ были такие программисты. Их я тоже видел, чего только они ни напридумывали, только диву даешься. Смотришь, ну просто геройства какие-то, а рядом лежит тоже самое только лучше и не надо ничего писать.
Сного субъективного в этом вопросе.
gsaw
26.12.2025 16:55Я знаю одно крупного клиента, который хочет съехать с мэйнфрейма до 2027 и запланировали на это дело 90 миллионов евров. Не сменить COBOL на java, а именно съехать. Текущим системам уже лет по тридцать, спецов, трудно найти тех, кто хочет заниматься COBOL. Молодежи подавай облака, copilot. Те, кто знают эту конкретную систему уходят на пенсию. Один два человека знают все эту паутину джобов. К тому же Microisoft дает или давала большие скидки для некоторых энтерпрайзных клиентов для использования Azure облаков. Я конечно точно не знаю, но мне думается привязка к IBM выходит дороже. Любая фича стоит огромных денег. Помню год назад, что то было с MQS, написали модуль на JAVA, который работал с MQS в клиентском режиме и не смогли запустить, потому как MQS был настроен через SSL, а на данном Mainframe не было фичи, что бы работать в данном режиме. И не стали покупать. Переписали на MQ через unix сокеты. А Java на мэйнфрейме, только пол года назад перешли на Java 17, до того была все еще Java 8. Приходилось в проекте, все, что работало на мэйнфрейме писать и тестировать с Java 8, когда остальной код уже на java 17/21 был написан.
> Что значит система версионирование Cobol модулей и причем здесь админы мэйнфрэймовские?
Я конечно не писал на COBOL, но в данной системе была какая то странная система версионирования из прошлого века. Код редактировался прямо на мэйнфрейме, модули получали новую версию в виде суффикса в имени. И такие же требования были к Java программам, не знаю, вроде от админов, который этой системой занимались. В JCL прописывался java класс с main функцией, и нам приходилось его с каждой новой версией переименовывать com.example.dj001.DJ00102 и потом еще в папочку с файлом тоже соответственно называть, с версией.
Короче, чуждый современному программисту мир :)zVlad909
26.12.2025 16:55К тому же Microisoft дает или давала большие скидки для некоторых энтерпрайзных клиентов для использования Azure облаков.
Компанию где я работаю тоже заманили в Azure разнымии плюшками. Сейчас руководство плачит потому что дорого. Почему дорого ясно как свет, но ничего поделать с этих невозможно. Это следствие подходов принятых на платформе х86-64. Мэйнфрэйм здесь ни причем.
Я конечно точно не знаю, но мне думается привязка к IBM выходит дороже.
Тут не думать надо, а считать. И еще правильно конфигурировать МФ. И еще надо как больше работы валить на МФ. И это реальная возможность экономить.
Часто бывает что еще со старых времен когда на старых МФ было нормально выполнять одно какое-нибудь приложение. Со временем, ничего не меняя переходили на новые МФ, их цена снижалась, казалось это не плохо и коптили дальше как есть. А можно было грузить новые МФ новыми приложениями на новых технологиях Java, Linix, WeSphere, виртуальные машины. Под это все IBM тоже дает хорошие скидки. Более того выставляет счет за софтвар в зависимости от количества реально выполненной работы, а не за сконфигурированные CPU, память ввод-вывод как в Azure. Наша проблема в Azure в том что используется и не используется сконфигуриванное оборудование счет за это один и тот же. На МФ это уже давно не так.
Т.е. ппроблема не в том что старые МФ-щики уходят на пенсии, а в том что возможность привлечь молодых с ихними хотелками не используется.
Любая фича стоит огромных денег
Например какая? Вот моя компания в 2016 помнится году купила WebSphere for z/OS за C$400 000 на все МФ и навсегда, с поддержкой. Но использовать не стала. Вместо этого сейчас использует "бесплатный" WildFly в Azure на десятках серверов и платит за это сумашедшие деньги. А могла бы обойтись одним МФ далеко не самым мощным а IBM за использование то что они называют "New Workload" еще бы скидки давало.
Java на МФ чем хороша относительно Cobol? Тем что Java может исполняться на Specialty Engines - zIIP. Это обычный CPU МФ, но он гораздо дешевле.
Есть много способов сделать МФ гораздо эффективней за теже деньги что надо тратить на Azure.
Если этим не занимать и этого не знать тогда конечно дело дрянь. Но это и везде так, чудес не бывает.
Еще проблема в том что молодёжи нынче никто не рассказывает правду про МФ. В худшем случае молодёжь наслушивается баек, в лучшем вообще ничего. С последними можно было бы работать.
Я лет 15 назад думал что мне придется перед пенсией передавать мой опыт и знания молодёжи. А вон он как сложилось - я остановил все системы МФ и собираюсь учится Кубернетес. Работать я на нем вряд ли буду, не видно ясных планов руководства на это. Сокращать они меня тоже не хотят потому что много денег должны были бы мне вывалить. Я конечно же ушел бы с подушкой которая мне при сокращении светит, но и сидеть ничего не делаю мне пока тоже не влом. Зиму перезимую а там видно будет.
Помню год назад, что то было с MQS, написали модуль на JAVA, который работал с MQS в клиентском режиме и не смогли запустить, потому как MQS был настроен через SSL, а на данном Mainframe не было фичи, что бы работать в данном режиме.
Это попахичвает явной ерундой. У Вас (у них) с системщиками все в порядке? Они могут делать свою работу? Я с SSL работал лет 15 назад.
Где стоит MQS? На МФ? Или не на МФ? Если нет то с чем тогда на МФ должен был работать клиент. Мало информации чтобы давать точные отвтеы, но чувствуется здесь какой то подвох. Если речь про z/OS то в коробочной поставке в нем столько всего напихано что дай бог половину использовать суметь. SSL это базовая фича, ее не может не быть или Вы недоговариваете.
Переписали на MQ через unix сокеты. А Java на мэйнфрейме, только пол года назад перешли на Java 17, до того была все еще Java 8. Приходилось в проекте, все, что работало на мэйнфрейме писать и тестировать с Java 8, когда остальной код уже на java 17/21 был написан.
В моей компании остановили апгрейды z/OS больше 10 лет назад. Мы использовали z/OS 1.13 текущая версия 3.2 (сентябрь 2025). Если у вас тоже такой же ерундой занимаются то не удивительно. Но Java это отдельный продукт и может быть установлена любая в любую версию если нет каких то дополнительных требований. Вот что я с ходу нашел на Гугле:
For z/OS
IBM offers several options for Java on z/OS, including no-cost runtimes for development and testing and products for production environments.
-
IBM Semeru Runtime Certified Edition for z/OS: This is the latest runtime available in various Java SE versions (11, 17, 21, and 25 are supported). It is available in SMP/E or PAX archive formats.
For Development (no cost): You can download it from the IBM Semeru Runtimes Downloads page.
For Production: This is typically ordered through IBM Shopz or downloaded via IBM Fix Central if using the IBM Installation Manager format.
IBM SDK, Java Technology Edition, Version 8: This older version is still available and widely used. Downloads are available from the IBM Java SDK Version 8 page.
Как видите с этим нет, и не могло быть, проблем. Опять упирается в ваших системщиков или их руководство, а вовсе не в МФ как таковой. С ним и с z/OS все Ок.
Я конечно не писал на COBOL, но в данной системе была какая то странная система версионирования из прошлого века. Код редактировался прямо на мэйнфрейме, модули получали новую версию в виде суффикса в имени. И такие же требования были к Java программам, не знаю, вроде от админов, который этой системой занимались. В JCL прописывался java класс с main функцией, и нам приходилось его с каждой новой версией переименовывать com.example.dj001.DJ00102 и потом еще в папочку с файлом тоже соответственно называть, с версией.
Короче, чуждый современному программисту мир :)
О мой бог. Как все у вас запущено. Системы версионирования на МФ могли быть и могут быть какими угодно. На это ни в Коболе и в чем другом не было и нет никаких указаний и.или ограничений. Какую систему версионирования используют у Вас я конечно не знаю и ничего сказать не могу про это.
Вам весь JCL приходится с новой версией менять (переписывать) или только переименовывать класс? А Вы знаете про то что в JCL можно использовать переменные и передавить их значения в момент запуска?
Я еще много что мог бы Вам сказать и думаю что любые ваши и ваших коллег проблемы решить на МФ к общему и полному удовольствию. Это реально.
gsaw
26.12.2025 16:55Все это было у крупного производителя автомобилей. Там на всех заводах такая система и не думаю, что там кто то, что то будет менять. Там всем этим чудом управляет тоже огромный IT хаус. И вся эта система с 90-х.
Я участвовал в проекте, который использовал WebSphere на мэйнфрейме. Там часть кода была на java, часть на COBOL.
Потом перешел на проект, где мы большую систему переписывали на java, и переносили в облако Azure. Там были расчеты деталей для производимых автомобилей на всех заводах. Тысячи автомобилей ежедневно, по 6000-8000 деталей на автомобиль. Сократили время обсчета дневного объема завода с нескольких часов на мэйнфрейме до полутра на java/azure. Новую систему запустили как раз, когда все ключевые кабалисты ушли на пенсию. И ценник снизился, с миллиона евров в год за mainframe систему и спецов, на один завод, до несколько десятков тысяч на azure/java.А сейчас я от туда ушел, взял отступные.
Не, я против мэйнфрейма ничего не имею против, если знать как его готовить правильно, то наверняка он не хуже прочих. Меня всегда поражали объемы данных, которые там обсчитываются из коробки. Но вот опыт у меня такой корявый был, что я думаю, что не зря от туда съезжают.zVlad909
26.12.2025 16:55Не, я против мэйнфрейма ничего не имею против, если знать как его готовить правильно, то наверняка он не хуже прочих. Меня всегда поражали объемы данных, которые там обсчитываются из коробки. Но вот опыт у меня такой корявый был, что я думаю, что не зря от туда съезжают.
Я уже описывал мое видение про то что приводит к съездам. Кратко:
прекращение поддержки базового ПО в плане обновления. Обновлять базовое ПО на МФ гораздо проще чем где либо еще.
недоиспользование возможностей МФ по расширению функций, которые могли быть установлены как на МФ так и на других платформах
недоучет возможностей МФ для использования "новых технологий" в раках либо виртуальных машин Linux или в партициях МФ без издержек ВМ.
Сократили время обсчета дневного объема завода с нескольких часов на мэйнфрейме до полутра на java/azure.
Я уверен 100% что сократить обсчет объема завода с неских часов на МФ до полутора часов на том же МФ (если это только не модель МФ начала 21-го века. К сожалению Вы про это не можете сказать) без переписывания на java/Azure и без модификации Кобол программ было бы возможно.
У смежного с нашей компанией предприятиях - электросети всего Онтарио - на МФ крутися дневной, недельный, месячные циклы заданий обсчитывающих счета потребителей элетроэнергии всего Онтарио.
Днлалось это на минимально возможной конфигурации МФ с 1(одним) CPU зажатом по производительности до минимума (модель А01. Максимальная производительность одного CPU была бы на моделе Z01. Все промежуточные буквы тоже возможны). И это была не современная модель МФ (они ушли с МФ давно). Процесс был вылизан так что МФ был 100% busy круглосуточно и все результаты выдавались вовремя.
Всю эту работу можно было бы добавить к нашему МФ модели O04 и тот МФ сократить. Но это были разные компании, разъехавшиеся в конце 90-х, когда были составными частями одного Ontario Hydro.
-
savenkom Автор
26.12.2025 16:55Привет. Чтобы миллионером стать, нужно самому искать клиентов для модернизации их легаси и своими силами делать реализацию, тогда точно будете миллионером))
durnoy
26.12.2025 16:55Как заказчик (и вы) планировал проверять, что новая система делает то, что нужно, или хотя бы то же самое, что и старая?
Другими словами, как было устроено тестирование этого всего?
ToniDoni
26.12.2025 16:55Судя по тому, что автору было непонятно, рабочий ли код написала нейронка или нет - никак)
savenkom Автор
26.12.2025 16:55Привет. Мы делали snapshot testing. Фреймворк для тестирования - pytest. Shapshot testing - это когда фиксируется состояние программы после каждого значимого шага выполнения, а затем результаты выполнения шага сравниваюися с эталоном. Если кратко, то это выглядит так: 1. Выполнение процесса разбивается на контрольные точки (snapshots) по control flow. 2. После каждого этапа сохраняется снимок состояния: – записи в БД (ключевые поля), – статус инвойса, – рассчитанные суммы/налоги, – выходные файлы или сообщения. 3. Эти снимки, полученные из COBOL-версии, становятся эталоном. 4. Java-версия прогоняется с теми же входными данными, и на каждом этапе состояние побайтно или семантически сравнивается с результатами выполнения COBOL-версии. 5. Любое расхождение сразу указывает, на каком шаге нарушена эквивалентность. Идея не в проверке отдельных функций, а в подтверждении, что весь бизнес-процесс проходит те же состояния в том же порядке и с теми же результатами.
durnoy
26.12.2025 16:55Выглядит разумно при условии, что есть достаточное количество таких тестовых сценариев, и что эти сценарии покрывают нужные ситуации.
savenkom Автор
26.12.2025 16:55Естественно, без полного понимания, как мигрируемую систему правильно тестировать, модернизация будет обречена на провал.
mvv-rus
26.12.2025 16:55Первая мысль, которая меня посетила при чтении статьи: зачем понадобился свой велосипед? Задача-то перезаписи программы с одного формального языка на другой - типовая, постоянно возникающая по мере развития вычислительной техники (ВЕ), меняются только пары языков, способ ее формального решения - транскомпиляция - давным давно понятен. Опять же, пара языков COBOL-Java не нова и должна была возникать в последние два-три десятка лет неоднократно (вспомним хотя бы ту же древнюю "пробему Y2K"). Меня несколько удивило, что не было найдено доступных средств (пусть не свободных, но хотя бы коммерческих) для ее решения. Но, допустим - я про этот рынок мало что знаю.
Вторая мысль, которая меня посетила сразу (а автора - спустя некоторое время) - зачем тут мысль о нейронке вообще в голову приходила. Задача состояла в транскомпиляции - значит должна решаться средствами ускорения и упрощения разработки компиляторов, благо их за время развития ВТ появилось в ассортименте. Автор взял ANTLR, я бы, как человек немолодой, взял yacc (Yet Another Compiler Compiler) - который уже настолько древний, что ещё пару десятков лет назад был типовым средством для студенческих курсовых по компиляторам.
Но, в любом случае, автору респект за то, что он отверг модный негодный способ в пользу старого рабочего, а статья будет полезна подрастающему поколению для приобретения понимания, что не надо всё пытаться делать стильномодномолодежными примочками, а стоит иногда поискать и поучить старую матчасть.
savenkom Автор
26.12.2025 16:55Здравствуйте! Спасибо за положительный отзыв о статье! Ваш комментарий/вопрос совершенно в точку. Выбор в пользу ANTLR был не случайным. Если сранивать с YACC, ANTLR требует меньших трудозатрат со стороны программиста. Дело в том, что у ANTLR уже есть встроенная реализация синтаксического дерева AST, которое необходимо имплементировать самостоятельно, если мы захотим пользоваться YACC. Кроме того, для ANTLR в свободном доступе есть описание всей COBOL грамматики. Плюс, Java - родной язык для ANTLR. По-сути вся работа с ANTLR сводится к тому, что программист должен правильно разобрать уже собранное за него AST, тогда, как в YACC все это нужно сделать вручную. Если говорить про коммерческие продукты для подобных миграций, то конечно, они есть, но перед нами стояла задача строгой экономии бюджета, поэтому, они были для нас непозволительной роскошью. Голь на выдумки хитра...
mvv-rus
26.12.2025 16:55Здравствуйте. Спасибо за наводку на ANTLR, хотя мне по жизни ближе C# нежели Java.
Причину построения своего велосипеда понял и считаю по жизни адекватной.
zVlad909
26.12.2025 16:55Оглядываясь назад, могу сказать, что миграция COBOL-системы с мейнфрейма на Java оказалась совсем вообще нетривиальной задачей, какой виделась в самом начале.
Прочитал всю статью. Что сказать? Работа по конвертации (замена слова трансляция и чего-то подобного) чего-то во что-то другое это интересная работа. Во время этой работы можно узнать много нового как о том что совсем не знал раньше и о том чем много занимался до того.
Я не так давно переводил DDL базы данных IDMS в DDL реляционой СУБД. Использовал для этого REXX в нем очень хорошие средства для работы с строчными данными и текстами, и вообще этот язык хорош для написания таких коневертаций. Не буду заявлять что это идеальный тулз, возможно есть полные и даже продвинутые аналоги для этого. Все таки REXX это древний продукт, хотя бы поэтому может быть что-то и лучше. Но я знаю REXX давно и знаю о нем много. Ну да ладно не про REXX мы.
Конвертация DDL намного проще чем конвертация комплекса программ Кобол (не только с процедурной прадигмой, но и построенного по модульному принципу и не совсем структурному (многоэтажные IF THEN ELSE и GO ТО, области определния имен и данных, и т.п.). Там еще есть т.н. Редактор Связей (Linkage Editor), который определенным образом связывает модули используя специфическую информацию, которую генерирует компилятор Кобол в процессе построения исполняемого модуля и про который в статье нет ни слова.
Все возможно если очень постораться. Но я бы поставил задачу как бы так сделать чтобы ничего никуда не переносить, но обеспечить экономичную среду выполнения Кобольной системы, при этом научиться находить и исправлять ошибки в Кобол (мне удавалось это делать без специального изучения Кобол как языка в целом), пересобирать квесь комплекс с исправлениями. А также создать некие интерфейсы в Кобольный комплекс с тем чтобы расширять функциональность Кобольного комплекса используя, например, Java или .NET. Типа API.
В принципе есть эмуляторы МФ на которых можно ранить Кобол без МФ или AS-400. Геркулес называется. Это конечно совсем не МФ, но все таки (я много в 90-е годы перевел программ PL/I с МФ на х86 с помощью транслятора PL/I написанного Microsoft. Есть и с Кобол трансляторы на х86-64.
На Западе эта тема точно давно решается и есть определенные успехи на верняка, Я конечно этим не интересовадся, мне это не было нужно поскольку я работал на МФ. Но вот наше ERP-класс приложение написанное на Кобол и в виде как раз мощного комплекса, вендором этого прилоржения, было переписано и перенесено на Java полностью. У них наверняка был тулз, который они хранят в секрете и может быть за деньги помогают другим сделать такой же фортель. Я готов сказать что уверен - на Западе есть тулзы недоступные ИИ по переводу приложений с Кобол на что угодно. Доступ ИИ к этм тузам закрыт потому что это деньги. И никогда, может только когда уже не останется ни одной Кобол программы, этого доступа ИИ не получить, а сгенерироать такой тудз сам ИИ не в состоянии.
Надо покупать тулз или не трогать Кобол, а наоборот подружиться с ним. Я уверен что автор статьи уже сам почти что эксперт по Коболу. Ему надо только еще немного разобраться в тем что в z/OS называется Language Environment (LE) и все будет в порядке. Кобол позноваем, кправляем и развиваем. Это не тупик.
Приложение:
This book introduces you to the Language Environment® architecture, a system of constructs and interfaces that provides a common runtime environment and runtime services for all Language Environment-conforming programming language products (those products that adhere to Language Environment's common interface). The book contains an overview of Language Environment, descriptions of its full program model, and callable services. This is not a programming manual, but rather a conceptual introduction to Language Environment. Language Environment is offered on z/OS.
z/OS® Language Environment is the prerequisite runtime environment for applications that are generated with the following IBM® compiler products:
z/OS XL C/C++ (feature of z/OS)
z/OS C/C++
OS/390® C/C++
C/C++ for MVS/ESA
C/C++ for z/VM®
XL C/C++ for z/VM
AD/Cycle C/370
IBM Toolkit for Swift on z/OS
VisualAge® for Java™, Enterprise Edition for OS/390
Enterprise COBOL for z/OS
Enterprise COBOL for z/OS and OS/390
COBOL for OS/390 & VM
COBOL for MVS™ & VM (formerly COBOL/370)
Enterprise PL/I for z/OS
Enterprise PL/I for z/OS and OS/390
VisualAge PL/I
PL/I for MVS & VM (formerly PL/I MVS & VM)
VS FORTRAN and FORTRAN IV (in compatibility mode)
IBM Open Enterprise SDK for Go
IBM Open XL C/C++ for z/OS
zVlad909
С первой строки захотелось прокомментировать:
Cobol и Java это языки программирования. Мэйнфрэйм это компьютер. Ладно если с мэйнфрэйма то наверное на х86.
Java это язык который используется на мэйнфрэймах едфа ли не с самого начала появления Java. Вот что дает AI:
apcs660
и на 390, и на системах пожиже, 400, java была с 90х, подтверждаю, копался.
zVlad909
ИБМ была одной из коалиции компаний занимающихся Java. Microsoft в той коалиции не было. Поэтому повился C#.
apcs660
Попытки были - я успел поработать с J++ и J# (одновременно с C#) но М$. действительно лепила что то специфическое по мотивам, не совместимое.
Натолкнулся как то на одну проблему с IBM JVM - обфускатор использовал трюки с байткодом (ломал его), которые sun/oracle и openjdk виртуалки проглатывали а IBM JVM падала.
Похоже что у IBM реализация была строже.
zVlad909
Я не писал на Java, а только деплоил написаное в WebSphere как на МФ так и на х86-64. То что я деплоил не подало, думаю потому что написано юыло правильно для IBM JVM.
Еще я занимался деплойментом Java приложения написаного под WebSphere на х86-64 с Oracle в WebSphere МФ с DB2. Деплоймент прошёл успешно, но рантайм лег на бок. Но имея контакт с разработчиком этого приложения предлагал им поработать вместе и подшаманить их приложение для работы на МФ. Это не выглядело сложным. Они отказались, напрочь. Странные люди.
apcs660
со сферой имел дело с 4й или 5й версии и до 9й.
На МФ не копался, на АС 400 было дело.
Однажды был такой прикол - не смог поставить IBM Websphere Everyplace Suite, в начале 2000х, на 10 или 11 СД дисках шла. Представитель IBM еще сказал будете 3м в Канаде если поставите. Ставил на AIX. В общем, психанул на предпоследнем диске и декомпилировал установщик. Код похоже писал неуч какой то, именно для этого диска (остальные код образцовый) - не было имени пакета (дефолный, что моветон) и самое главное, не убран отладочный хак с харкоднутым путем к базе. Ответ на вопросы " выберите тип базы и путь к ней" игнорировался и заменялся на константу и если твоей системе не повезло, установка падала. Моей не повезло - у нас был Оракл, а в константе в коде был DB2. Как подобный гавнокод прошел в IBM, большой вопрос.
Ценник на все был негуманный. Вебсфера под сотню штук местных баксов, сетевая карточка полторы (AS400).
этой весной мигрировал старый репозиторий на полтора миллиарда доков, с IBM image services, на filenet и пришлось реверснуть IBM cold формат документов, конвертил их в пдф. Забавный формат оказался, интересный. И закрытый, поэтому пришлось ломать.
zVlad909
Я начинал с до 4-ой версии. 4-ую пропустил и дошел до 9-ой на х86-64 и до 8-ой на МФ.
Проблем таких не имел. Никогда с CD не устанавливал. Все проблемы, если они и были, решал через ИБМ саппорт.
Большие деньги это как сравнивать. Если Вы делаете домашний веб сайт, то Вам WebSphere не нужен. А вот для бизнесов с миллоирдным оборотом C$400 000 (компания где я работаю в свое время заплатила, но использовать не стала. Теперь платит Azure за десятки серверов с WildFly и Оракл-у миллионы денег) за веб для критическиго приложения вполне обосновано. Причем это фиксированная цена за все последущие версии и поддержку. На МФ за жти деньги можно было бы заменить десятки серверов ч86-64 в облаке, а там все за деньги, любой писк.
savenkom Автор
Да вредо понятно, что речь идет о миграции COBOL-кода на Java. Если я уберу из предложения "с мейнфрейма" Ваш вопрос будет еще актуален ?
zVlad909
Да в принципе пусть остается так. Понятно что это как бы два в одном и с МФ и из Кобола. Java переносимый язык и может испольняться (в теории) где угодно.
Кстати (извините статью не читал. Может там есть ответ) как Вы (или Ваши тулзы) сочетаете тот факт что когда Кобол это процедурный язык, то Java это ООП. Т.е. в Коболе вообще нет объектов, а в Java они есть и никакой парзер-конвертер не сможет перевести программу из одной парадигмы программирования в другую. Как у Вас с этим? Если об этом сказано в статье дайти ссылочку короткую я сам найду и прочитаю. Спасибо.
savenkom Автор
Сам по себе парсер (включая ANTLR) не переводит процедурную парадигму в ООП и не должен этого делать - для миграции достаточно построить корректное AST COBOL-программы и сгенерировать поведенчески эквивалентный Java-код, а переход к ООП является отдельной, последующей задачей рефакторинга, а не трансляции.
zVlad909
Вы сказали другими словами ровно то что я имел в виду. Только я бы усилил "не должен" до "не спобовен/не может" сколько бы интеллекта в него не добавлялось. Это может сделать только человек знающий проблематику написаную на Кобол и знающий парадигму ООП.
Кстати, насколько я помню к Кобол прилеплялось некое ООП расширение, как к С где получился С++. Сам я такие расширения не признают поскольку признаю ООП только в таком виде какой есть в SmallTalk.
savenkom Автор
Полностью солидарен! Парсер (даже с любым количеством “интеллекта”) принципиально не способен перевести процедурный COBOL-код в корректную ООП-модель, потому что такая трансформация требует человеческого доменного понимания и осознанного проектирования, а не синтаксического или даже семантического анализа; для миграции достаточно построить AST и сгенерировать поведенчески эквивалентный Java-код, а переход к ООП — это отдельная сложная инженерная задача, выполняемая человеком.
zVlad909
И при этом такой Java код превращается в процедурную программу с издержками реализации ООП через байт код и JVM. Процедурную программу можно странслировать в машинный код, ООП программу нет. Поэтому производительность Кобол програм будет всегда выше чем Java аналог.
На МФ это решается хитрвм ходом через использование Specialty Engine - zIIP. И в принципе мог бы иметь смысл переписывать Cobol на Java с оставлением рантайма на МФ с zIIP, это снизило бы расходы на МФ существенно (хотя надо конечно считать, исследовать конкретные случаи) просто за счет того что можно было бы сократить вес General Purpose CPU и тем самым цену лицензий за z/OS и Соbol.
Как кстати выполнялись те программы Кобол, которые Вы переносите на Java? Как батчджобс или под CICS? Или как? Java программы можно ранить в CICS (давно уже, в прошлом веке) и тем самым экономить существенно с zIIP, оставаясь в z/OS и CICS. Это мог бы быть хороший бизнес.
P.S. А полнял, Вы на AS-400 крутите Кобол. Тогда я не в тему.
mvv-rus
Программисты на C++ и на Delphi смотрят на эту вашу фразу с недоумением, я - в том числе.
Или вы про какие-то чисто мейнфреймовские заморочки?
zVlad909
Ну и пусть смотрят как хотят. Мне то что от этого?
mvv-rus
Вы написали неверное утверждение. Вас это не беспокоит?
zVlad909
Мы вроде с Вами уже прощались в другой теме. Стоит ли снова вести к этому?
mvv-rus
Я это написал не только для вас, но и для других читателей. Чисто потому, что мне не нравится распространение ошибочных утверждений среди неограниченного круга лиц.
mvv-rus
Не понял, где тут проблема? Ограничения процедурной парадигмы тривиально эмулируются тем, что в программе делается одиночный объект (singleton), поля которого заменяют глобальные переменные, а методы - процедуры. Это сработает даже если в языке нет глобальных (внеэкземплярных) объектов/методов (а в C#, например, они есть: static, про Java я уже не помню, очень давно с ней дело имел).
Вот программу с объектами перевести на процедурный язык (к примеру, с Java на C) - это менее тривиально, впрочем и на C вполне можно эмулировать объекты (структурами), полиморфизм и виртуальные функции (через указатели на функции в этих структурах) и т.д.
zVlad909
Это чисто структурный подход, на уровне переименований элементов структуры программы.
На самом деле (может Вы про это не знаете) ООП предлагает программные возможности напрочь отсутствующие в процедурном Кобол:
Кроме перечисленного в SmallTalk и я полагаю других настоящих ООП диалектов (а как известно многоие такие диалекты есть процедурные основы притянутые за уши к прадигме ООП. Является ли Java более натуральным ООП языком я не знаю) за переменными не закрепляется тип данных. Тип данных одной и той же переменной может меняться во время исполнения программы. Что можно реализовать только интерпретацией кода, но не трансляцией.
Следователь ничто из этого просто нет в процедурном языке и следовательно конвертируя (по-Вышему переименовывая) процедурный код в синтаксис ООП языка мы получаем процедурную программу с дополнительным гемороем в виде всего того что делает язык программирования ООП.
Конвертировать Кобол в С или Бэйск более адекватная задача.
mvv-rus
Как я понимаю, именно это и было нужно. Задача переписать программу на другой язык явно была вызвана стремлением уйти с той же самой (семантически) программой на другой набор средств разработки, специалисты, владеющие которым более распространены - что означает меньшие затраты на их оплату и меньшие риски. Плюс - уйти на другую платформу, не привязанную к производителю, работающему в недружественной юрисдикции - что тоже создает заметные риски.
То есть задача, описанная в статье, была чисто деловая, а не идеологическая или эстетическая, про деньги, а не про истины и чувство прекрасного.
Таки знаю. Но конкретно чистотой ООП-парадигмы не заморачиваюсь. ООП - это средство снижения сложности программ, и оно может быть использовано в этом качестве достаточно хорошо и без Smalltalk с его чистотой принципов, с реализацией на языках типа C++/Java и прочих подобных. А восхищение чистотой и красотой принципов Smalltalk и лично Алана Кея я бы оставил теоретикам, чтобы просто поднимать бабло, оно не нужно.
В языках со статической типизацией (Java относится именно к ним) тип переменной фиксируется и проверяется на момент компиляции, а содержать переменная может только этот тип и производные (унаследованные) от него типы.
Неверно, всё реализуется. Поля в базовом и производных типах лежат ровно по тем же смещениям в структуре объекта, так что для работы с производными объектами как базовыми не нужно никаких специальных мер. Полиморфизм методов (оно же позднее связывание) в C++, Java и им подобных языках реализуется путем косвенного вызова методов через таблицу виртуальных методов (VT). Доступ к информация о типе во время выполнения, где она есть в языке (в C++ она есть очень ограниченно, AFAIK фактически - только VT, в Java или C# она весьма подробна) реализуется через специальное поле, ссылающееся на структуру, содержащую нужную информацию. И так далее.
Вообще, как можно говорить, что возможности Java можно реализовать только интерпретацией кода, когда в современных программах этот код часто компилируется JIT-компилятором из байт-кода в машинный? В C# дело обстоит аналогично, а в последних версиях можно выполнить эту компиляцию заранее (называется это AOT, не знаю, реализовано ли это для Java, но технических затруднений сделать это не вижу).
Весь этот дополнителный геморрой (его обычно именуют boilerplate) творится автоматически, а потому никому и ничему не мешает.
Да, но, похоже, у автора не было возможности решить задачу так: выходной язык был задан по ее условиям.