Да, ту самую, из коробки, которая пылится на полке, потому что друзья разбежались.
Я скинул Логосу PDF с правилами.
Он, как любой хороший ИИ, сразу выдал километровый код и архитектурные предложения.
И я его остановил:

«Логос, стоп. Сначала — механики, потом код. Ты знаешь, какие карты есть в игре?»
«Нет»
«Тогда не лети вперёд паровоза»

Этот момент — ключевой. ИИ — это инструмент ускорения, а не замена мышлению.

📋 Первый реальный шаг: таблица карт

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

💬 Вопросы к сообществу (не ради галочки)

1. Как вам вообще моя затея?
   Серьёзно. Мне нужен честный взгляд со стороны. Есть ли в этом смысл или я занимаюсь ерундой?

2. У кого был опыт, когда проект на старте казался простым, а потом превращался в снежный ком?
   Как вы не сдавались и доводили дело до конца?

3. Какую настолку вы бы сами перенесли в онлайн, если бы умели кодить?
   Может, я выбрал не ту игру? Посоветуйте — я открыт.

📌 Что дальше?

Следующий шаг — в следующем посте. 💯

P.S. Т-академия отказала.
И это, наверное, к лучшему — теперь точно никто не будет отвлекать от моего собственного маршрута.
Иногда «нет» — это «да» с отсрочкой.

А вы сталкивались с отказами, которые обернулись удачей?
Расскажите — вдохновимся вместе.

Это не первый мой курс по программированию, но первый, который я прошёл в тандеме с DeepSeek. И разница — просто небо и земля:
- 🚀 Учился в разы быстрее — потому что Логос (мой AI-напарник) всегда был под рукой
- 🧠 Любую непонятную тему можно было разжевать до состояния каши — пока не дойдёт
- 💬 Прокачал навык общения с ИИ — теперь я не просто спрашиваю, а выстраиваю диалог , как с живым коллегой

🤔 А ЧТО ДАЛЬШЕ? ГЛАВНЫЙ ВОПРОС

Скажу честно: в текущей ситуации я мало верю, что меня возьмут джуном сходу. Поэтому активных поисков работы пока не веду.
Но пару недель назад на почту пришла ссылка: Т-академия набирает учеников. Я заполнил анкету, прошёл тесты.
Возьмут — не возьмут, пока хз. И если возьмут, пойду ли — тоже под вопросом. Но шаг сделан, это уже прогресс.

🎲 ПРОЕКТ, КОТОРЫЙ РОДИЛСЯ ИЗ БОЛИ

Все вокруг твердят: «Сделай свой проект! Вот тогда ты реально разработчик».
А я сижу и думаю: «Что делать-то?» Всё уже придумали, всё уже есть.
И тут ИИ выдал гениальную простоту: «Сделай то, чего тебе не хватает в жизни».
А чего мне не хватает?
Я люблю настольные игры. У меня даже небольшая коллекция. Но с годами играть стало не с кем:
- У друзей нет времени
- Кто-то уехал
- Кому-то просто не интересно

И я понял: я же не один такой! В других городах и странах полно людей, которые хотят играть, но не с кем.
И тут меня осенило. 💡
Я открыл коробку с одной из своих любимых игр и понял: я хочу перенести её онлайн.
Посовещались с ИИ. Пришли к выводу: будет сложно, но шаг за шагом — реально.

🎬 СЕЗОН 2: ОТ ЗНАКОМСТВА К РЕАЛЬНОМУ ПРОЕКТУ
Так что первый сезон нашего сериала «Мясник + ИИ = знакомство» я считаю завершённым.
И объявляю о старте второго сезона:
Butcher in IT: реальный проект 🚀
Я буду делать онлайн-версию настолки. С нуля. На Java. С помощью ИИ. И всё это — на ваших глазах.

💬 ВОПРОСЫ К СООБЩЕСТВУ (ОТ МЯСНИКА С АМБИЦИЯМИ)

1. Кто-нибудь сталкивался с переносом реальной настольной игры в онлайн? Это вообще легально? 🤔
2. Нужно ли писать издателю и просить разрешения? Или можно сделать «свою» версию с изменённой механикой?
3. Стоит ли менять правила, чтобы игра стала «уникальной», или сделать точную копию?
4. Если у кого-то есть опыт подобных проектов — расскажите, с чего начать, чтобы не утонуть в коде с первых дней? 🙏

---

P.S. Подписывайтесь, если ещё не — дальше будет жарко! 🔥 Я впервые за долгое время вижу конкретную цель, а не просто «хочу в IT».

P.P.S. И да, я всё ещё режу мясо. Но теперь ещё и пишу код. Две параллельные вселенные, одна голова. 😅

Для кнопочного телефона это была вообще пушка. Бегаешь по дворцу, прыгаешь, карабкаешься, избегаешь ловушек, и всё это с ощущением, будто у тебя в руках почти настоящая консоль. После совсем простеньких мобилок эта игра казалась чем-то взрослым.

Особенно мне нравилось, что в ней был какой-то дух приключения. Не просто "нажимай кнопки и собирай монетки", а реально путь через ловушки, стены, шипы и всю эту восточную атмосферу. Для маленького экрана это работало очень даже бодро, да я бы и сейчас поиграл в неё на кнопочном телефоне, на каком нибудь Nokia 6233

Asphalt

Какая именно часть была у меня первой, я уже честно не помню. По-моему, я успел скачать несколько, и отличались они одна от другой не то чтобы сильно

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

Splinter Cell

Вот эта игра мне тогда вообще снесла башку.

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

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

Age of Heroes

Вот это уже прям жир.

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

Мне всегда нравились такие штуки, где ты не просто проходишь уровень за уровнем, а именно идёшь по миру, лутаешь, дерёшься, качаешься и чувствуешь, что у тебя есть хоть какое-то развитие персонажа. Age of Heroes как раз давала это ощущение. и как классно что у телефонов была память и сохранения, например на приставке у меня был картридж без батарейки, и попробуйте Final Fantasy пройти за один присест, во первых долго, во вторых кинескоп посадишь.

Magnetic Joe

Вот тут, возможно, не все со мной согласятся, но лично мне Magnetic Joe нравилась больше, чем тот же Bounce. Хотя концептуально игры, конечно, разные.

В Magnetic Joe был свой очень кайфовый вайб. Маленький робот, магниты, платформы, вся эта механика с притягиванием и отталкиванием реально цепляла. Игра не выглядела слишком шумной или перегруженной, но в ней было какое-то особое удовольствие от самого процесса.

Мне она запомнилась именно как одна из самых приятных Java-игр. Не самая хайповая, не самая попсовая, но очень цепляющая. Бывают такие игры, которые не у всех на слуху, но лично тебе заходят вообще идеально. Вот Magnetic Joe у меня как раз из таких.

Послесловие:

Вообще забавно, насколько мощные эмоции тогда могли вызывать игры, которые сегодня весят меньше одной фотки в памяти телефона.

Но в этом и был весь кайф. Телефон кнопочный, экран маленький, памяти почти нет, а удовольствия было дофига, и как классно было когда родители покупают новую мобилу уже с поддержкой карт памяти, можно было не выбирать, а качать всё что угодно, пока трафик не кончится.

Да конечно, я не добавил в этот топ: Кто хочет стать миллионером, Gangster Crime city, Bounce, AssАсинс Крид, пишите в комментариях свой топ игр

Короче, я, похоже, иду по понижающей по поколениям, так что следующим постом сделаю уже мой личный топ игр на SEGA, а потом и на Dendy, только не заставляйте меня делать топ игр на Тетрисе.

Исходный код отрефакторенной версии выложен на Github.

Задача

Допустим есть некий софт, созданный еще «при царе Горохе» неким гордым но умным одиночкой, которого с тех пор никто не видел. Софт живой и с пользователями, которые приносят прибыль, поэтому его надо как‑то развивать и поддерживать.

В попытке расширить команду разработки, вы начинаете нанимать новых разработчиков, но раз за разом происходит одна и та же ситуация:

проработав месяц-два, нанятые программисты в ужасе убегают в закат.

Кто‑то при увольнении намекает на причины такого поступка, в диапазоне от «ваш проект попахивает» до надо «срочно все переписать». После примерно десятого убежавшего программиста, вы наконец начинаете задумываться, что возможно с проектом действительно что‑то не так и стоит провести этот самый «рефакторинг».

Так это обычно начинается.

Образец

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

The fast x86 PC emulator in 100% pure Java

Самый настоящий эмулятор старого x86-компьютера, реализованный без всяких нативных частей — на чистой Java!

Как-то так это выглядит у автора(ов) в работе:

Проект старый, но и интересный:

Read more about JPC - since it's launch at JavaOne 2007, JPC can now boot many more operating systems (including graphical linuxes) and it's much faster.

Не очень большой (~6500 файлов с исходным кодом), но имеет стадию «внутренней генерации» — часть исходного кода создана не вручную а путем запуска кодогенератора по метаданным, что довольно часто встречается у больших проектов с историей, причем на любом языке.

Еще к сожалению JPC немного заброшен, что для статьи только в плюс поскольку добавляет реалистичности — именно в таком состоянии чаще всего пребывают проекты, которые просят «привести в чувство».

Текущее состояние

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

Никаких тестов в проекте нет, по всей видимости тестировалось все вручную с помощью молитвы, еще судя по исходному коду — далеко не весь функционал является рабочим, что также характерно для проектов в «пред‑рефакторинговом» состоянии.

Думаю теперь очевидно почему для этой статьи был выбран именно JPC — несмотря на редкость решаемой задачи, для рефакторинга это самый типичный клиент.

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

make application

Примерно как собирать проект на QT с помощью Gradle или (еще лучше) — sbt.

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

Для сборки необходимо указать путь к JDK в переменной PATH, при этом сборка проходит успешно даже с последними версиями (автор использовал OpenJDK 21).

Готовое приложение JPCApplication.jar появится в корне проекта после завершения сборки, но на этом хорошие новости заканчиваются:

Собранное приложение отказывается запускаться, что мы исправим чуть ниже.

Стадия первая: новый скелет

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

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

Разумеется существуют варианты и с произвольной структурой проекта, но эффективность рефакторинга будет заметно ниже. Поэтому автор сделал стандартный (для своей практики) «финт ушами»:

перевел сборку проекта на Apache Maven, максимально широко поддерживаемый средствами анализа кода, CI-системами и средами разработки.

Реализовать такую миграцию в данном случае оказалось очень просто, поскольку JPC совсем не использует внешние библиотеки. Все что я сделал — раскидал ресурсы и исходный код в стандартную для Maven структуру каталогов:

Исходный код был перенесен из каталога src в src/main/java, ресурсы — в src/main/resources. Также был добавлен очень простой pom.xml, описывающий минимальные шаги сборки проекта:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.x0x08.samples</groupId>
<artifactId>jpc-refactored</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.13.0</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.4.2</version>
<configuration>
<archive>
<manifest>
<mainClass>
org.jpc.j2se.JPCApplication
</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
</project>

Обратите внимание на куда более упрощенную генерацию манифеста:

<manifest>
<mainClass>
org.jpc.j2se.JPCApplication
</mainClass>
</manifest>

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

В оригинальной сборке происходит добавление еще и атрибута, отвечающего за параметры запуска «по-умолчанию»:

echo "Default-Args: -fda mem:resources/images/floppy.img -hda mem:resources/images/dosgames.img -boot fda" >> jpc.manifest

Это было убрано, поскольку точно такой же параметр запуска зашит еще и в код:

Наследие «былых времен», которое также достаточно часто встречается в устаревших проектах — во времена Java 1.5 и апплетов было модным использовать собственные атрибуты в манифесте.

Стадия вторая: удаление ненужного

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

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

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

В JPC внутренние утилиты реализованы в виде отдельных классов в пакете «tools» и нескольких шелл-скриптов в корне проекта.

И то и другое я просто не стал переносить в новую версию, также я убрал часть исходного кода эмулятора, отвечающего за отладку (пакет org.jpc.debugger) — по той же самой причине.

Что потребовало правок в классе org.jpc.emulator.PC.java:

был убран импорт класса org.jpc.debugger.LinearMemoryViewer а используемая статичная функция translateLinearAddressToInt перенесена в класс PC.

Все эти действия позволили сократить кодовую базу проекта практически вдвое, что сильно упростило следующий шаг рефакторинга.

Стадия третья: критические проблемы

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

Первый запуск анализатора дает следующий результат:

24 критических ошибки и ~ 37 тысяч предупреждений — не так уж плохо, по сравнению с тем что бывает на свете.

Смотрим глубже и видим, что все 24 ошибки — действительно самые критичные, поскольку из-за них проект может перестать собираться в самом ближайшем будущем:

Так что эти места стоит рефакторить в первую очередь, пока проект хотя-бы собирается из исходников.

Есть и хорошая новость:

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

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

Но все несколько сложнее, поскольку еще есть вложенные классы, один из которых используется снаружи (org.jpc.j2se.JPCApplication):

JPCApplet.PlayPausePanel pp = new JPCApplet.PlayPausePanel(this);

Я просто перенес этот класс по месту использования, что позволило наконец удалить JPCApplet из проекта целиком.

Получилось минус 13 критических ошибок.

Еще один источник проблем — класс LinkBorder также можно удалить, поскольку он использовался лишь из удаленного JPCApplet.

Что дало еще минус три критических ошибки.

Дальше смотрим класс org.jpc.emulator.peripheral.Mixer, который забит предупреждениями от анализатора буквально через каждую строчку, однако вносить массовые правки пока не стоит — «всемогущая» Idea временами ошибается и это именно такой случай.

Ограничимся лишь одним методом:

private void ShowVolume(String name,FloatRef vol0,FloatRef vol1) {
System.out.printf("%-8s %3.0f:%-3.0f %+3.2f:%-+3.2f \n",new Object[] {name,
new Float(vol0.value*100),new Float(vol1.value*100),
new Float(20*Math.log(vol0.value)/Math.log(10.0f)),new Float(20*Math.log(vol1.value)/Math.log(10.0f))}
);
}

Анализатор ругается (в первую очередь) на конструктор new Float(), поскольку его прямое использование объявлено устаревшим, а в новых версиях Java стоит использовать Float.valueOf() в качестве замены.

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

System.out.printf("%-8s %3.0f:%-3.0f %+3.2f:%-+3.2f \n",
name,
vol0.value * 100, vol1.value * 100,
20*Math.log(vol0.value)/Math.log(10.0f),
20*Math.log(vol1.value)/Math.log(10.0f));

Следующий класс для изучения org.jpc.j2se.PCMonitorFrame, где анализатор ругается на два места с критическими ошибками.

Первое место характерно для устаревших проектов и встретится еще не раз:

catch (AccessControlException e)
{
LOGGING.log(Level.WARNING, "Not able to add some components to frame.", e);
}

Дело в том что класс ошибки, которая тут обрабатывается объявлен устаревшим в новых версиях:

'java. security. AccessControlException' is deprecated since version 17 and marked for removal

Поскольку исключение AccessControlException в новых версиях не выбрасывается, весь блок try-catch можно спокойно удалить.

Следующее место, код в этом же классе:

if (runner.isAlive())
{
try
{
runner.stop();
}
catch (SecurityException e) {}
}

Ругается анализатор на уникальный метод stop(), который был отмечен как устаревший еще до того как я начал писать на Java:

'stop()' is deprecated since version 1.2 and marked for removal

Примерно до версии 1.8 использование данного метода еще можно было как‑то оправдать наличием устаревших библиотек, в нынешних реалиях этот метод — просто еще один способ «выстрелить себе в ногу»:

Stopping a thread causes it to unlock all the monitors that it has locked.

Так что в коде использование этого метода точно стоит заменить на стандартный .interrupt() :

if (runner.isAlive())
{
runner.interrupt();
}

Блок try-catch также можно спокойно убрать, поскольку SecurityException не выбрасывается в новых версиях Java при попытке остановки нити.

На этом все критические проблемы в проекте решены и получен минимальный практический смысл от всей затеи:

убраны места, которые могут сломать сборку проекта в новых версиях Java

Стадия четвертая: ошибки выполнения

Пришло время наконец попробовать запустить нашего «франкенштейна».

Сборка разумеется завершится успешно (не зря же старались), но при запуске будет выбрасываться все та же ошибка поиска ресурсов:

В оригинальной версии JPC, часть ресурсов (например образы биоса) загружались только из jar‑файла, часть (образы дисков) — только снаружи, из каталога resources, при этом каталог с ресурсами был общим.

Сию дичь необходимо пресечь и сделать в более адекватном стиле, например как это реализовано в движке знаменитого Quake:

сначала ищем внешний файл, если не найден — ищем в ресурсах, если не найден в ресурсах — падаем с ошибкой

За чтение образа BIOS отвечает вот такой метод в классе org.jpc.emulator.motherboard.Bios:

private static final byte[] getBiosData(String image) throws IOException {
InputStream in = Bios.class.getResourceAsStream(image);
if (in == null) {
throw new IOException("resource not found: " + image);
}
try {
ByteArrayOutputStream bout = new ByteArrayOutputStream();

while (true) {
int ch = in.read();
if (ch < 0) {
break;
}
bout.write((byte) ch);
}

return bout.toByteArray();
} finally {
try {
in.close();
} catch (IOException e) {
}
}
}
}

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

Конечный вариант после всех чисток выглядит так:

private static byte[] getBiosData(String image) throws IOException {

File f = new File(image);
if (f.exists() && f.isFile() && f.canRead())
return Files.readAllBytes(f.toPath());

f = new File("resources",image);
if (f.exists() && f.isFile() && f.canRead())
return Files.readAllBytes(f.toPath());

final URL u = Bios.class.getResource(image);
if (u == null)
throw new IOException("resource (bios) not found: %s".formatted(image));

try (InputStream in = u.openStream()) {
return in.readAllBytes();
}
}

Логика переделана на возможности современной Java 17, поэтому кода стало сильно меньше, также были добавлены проверки на наличие ресурса:

• по полному пути,

• по частичному (предполагается что файл находится в каталоге resources),

• поиск внутри jar приложения.

Но при следующей попытке запуска получаем еще одно исключение, уже в другом месте:

Причиной является искусственная проверка:

if (!(cl instanceof URLClassLoader))
throw new IllegalStateException();

Когда-то давно системный загрузчик классов действительно наследовался от URLClassLoader, так что проверка бы отработала.

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

Однако одним лишь удалением проверки дело не ограничилось — необходимо почистить еще один метод, реализующий «закат солнца вручную»:

private static final Iterator<String> getResources(String directory)
{
ClassLoader context = Thread.currentThread().getContextClassLoader();

List<String> resources = new ArrayList<String>();

ClassLoader cl = JPCApplication.class.getClassLoader();
if (!(cl instanceof URLClassLoader))
throw new IllegalStateException();
URL[] urls = ((URLClassLoader) cl).getURLs();

int slash = directory.lastIndexOf("/");
String dir = directory.substring(0, slash + 1);
for (int i=0; i<urls.length; i++)
{
if (!urls[i].toString().endsWith(".jar"))
continue;
try
{
JarInputStream jarStream = new JarInputStream(urls[i].openStream());
while (true)
{
ZipEntry entry = jarStream.getNextEntry();
if (entry == null)
break;
if (entry.isDirectory())
continue;

String name = entry.getName();
slash = name.lastIndexOf("/");
String thisDir = "";
if (slash >= 0)
thisDir = name.substring(0, slash + 1);

if (!dir.equals(thisDir))
continue;
resources.add(name);
}

jarStream.close();
}
catch (IOException e) { e.printStackTrace();}
}
InputStream stream = context.getResourceAsStream(directory);
try
{
if (stream != null)
{
Reader r = new InputStreamReader(stream);
StringBuilder sb = new StringBuilder();
char[] buffer = new char[1024];
try
{
while (true)
{
int length = r.read(buffer);
if (length < 0)
{
break;
}
sb.append(buffer, 0, length);
}
} finally
{
r.close();
}

for (String s : sb.toString().split("\n"))
{
if (context.getResource(directory + s) != null)
{
resources.add(s);
}
}
}
}
catch (IOException e)
{
LOGGING.log(Level.INFO, "Exception reading images directory stream", e);
}

return resources.iterator();
}

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

С учетом того что .class файлов внутри ~6500 — такое решение мягко говоря «не оптимально».

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

Поскольку в проекте используется очень небольшое количество образов диска и нет вариантов по резкому увеличению их количества, я просто зашил названия в код:

private static final String[] IMAGES = {
"images/dosgames.img",
"images/floppy.img",
"images/linux.img",
"images/odin070.img",
};

private static Iterator<String> getResources(String directory)
{
final List<String> resources = new ArrayList<String>
(Arrays.stream(IMAGES).toList());
final File f = new File(directory);

if (!f.exists() || !f.isDirectory()) {
return resources.iterator();
}

final File[] files = f.listFiles();

if (files == null) {
return resources.iterator();
}
for (File ff: files) {
resources.add(directory + ff.getName());
}

return resources.iterator();
}

Метод getResources() используется для отображения списка доступных образов дисков через меню приложения, все внутренние образы (зашитые в.jar) добавляются в этот список автоматически.

После столь примитивной правки, приложение стало запускаться визуально быстрее даже на мощном современном ноутбуке, так что не стоит недооценивать силу простых решений ;)

Хотя всех правок выше оказалось недостаточно, следующая остановка — класс org.jpc.support.ArrayBackedSeekableIODevice, который (внезапно) играет ключевую роль в проекте.

Метод configure() отвечает непосредственно за загрузку образов дисков и дискет:

public void configure(String spec) throws IOException
{
resource = spec;
imageOffset = 0;

InputStream in = ArrayBackedSeekableIODevice.class.getClassLoader().getResourceAsStream(resource);
if (in == null) {
LOGGING.log(Level.SEVERE, "resource not found: {0}", resource);
throw new IOException("resource not found: " + resource);
}
try {
byte[] buffer = new byte[1024];
ExposedByteArrayOutputStream bout = new ExposedByteArrayOutputStream(32*1024);

while (true) {
int read = in.read(buffer);
if (read < 0)
break;
bout.write(buffer, 0, read);
}

imageData = bout.getBuffer();
length = bout.getPosition();
} catch (IOException e) {
LOGGING.log(Level.SEVERE, "could not load file", e);
throw e;
} finally {
try {
in.close();
} catch (IOException e) {
}
}
}

Переделываем с учетом современных реалий:

public void configure(String spec) throws IOException {
resource = spec;
imageOffset = 0;

File f = new File(spec);
if (f.exists() && f.isFile() && f.canRead()) {
imageData = Files.readAllBytes(f.toPath());
length = imageData.length;
return;
}

f = new File("resources",spec);
if (f.exists() && f.isFile() && f.canRead()) {
imageData = Files.readAllBytes(f.toPath());
length = imageData.length;
return;
}
final URL u = ArrayBackedSeekableIODevice.class.getResource(spec);
if (u == null)
throw new IOException("resource (image) not found: %s"
.formatted(spec));

try (InputStream in = u.openStream()) {
imageData = in.readAllBytes();
length = imageData.length;
}
}

Тут тоже три последовательные проверки на поиск образа диска и использование современного API для минимизации кодовой базы.

Эта доработка оказалась финальной и наконец можно успешно запустить эмулятор:

java -jar target/jpc-refactored-1.0-SNAPSHOT.jar -hda src/main/resources/images/linux.img

Будет запущен Qemu Linux Test Distribution:

Или так:

java -jar target/jpc-refactored-1.0-SNAPSHOT.jar -fda mem:images/odin070.img

запустится FreeDOS ODIN:

На этой стадии была проведена самая настоящая «коммерческая оптимизация» — доведен до ума функционал актуальный конечным пользователям.

Так что вас за такое-то скотство, проведенное с рабочим проектом уже точно не уволят ;)

Стадия пятая: массовые правки

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

массовые и сквозные правки исходного кода, во всем проекте целиком

Рабочая область выглядит как-то так:

Собственно все «желтенькое» на скриншоте ниже — места для рефакторинга, заботливо подсказанные средой разработки:

К сожалению на практике все несколько сложнее чем подсказывает Idea и просто нажимать «Alt + Shift + Enter» на каждую подсказку не стоит:

Все потому, что в проекте активно используется Reflection API для загрузки и обращения к методам класса необычными способами:

try {
Method valueOf = type.getMethod("valueOf", String.class);
return valueOf.invoke(type, value);
} catch (NoSuchMethodException e) {
System.err.println(type + " :No suitable method");
}

Что сводит анализаторы исходного кода с ума, поэтому примерно половина методов в проекте десктоп-приложения, не использующего никакие IoC-контейнеры отмечено как неиспользуемые:

Скотство?

Конечно скотство, но и в реальных больших и старых проектах такое тоже будет в обязательном порядке — когда‑то использование Reflection API считалось модным и молодежным явлением, убрать которое "под капот" смогли только те самые IoC‑контейнеры вроде Spring.

Следующим примером кода, нуждающегося в массовой зачистке является использование анонимных классов:

Лямбды появились еще в Java 8 и с тех пор уже нет никакого здравого смысла их игнорировать — они здорово сокращают объем кода:

В любом legacy-проекте, особенно если это приложение для десктопа такого будет очень и очень много:

Следующий повод для массовых правок — прямой результат ручной разработки, без использования средств проверки и анализа кода:

Хороший пример, подсказанный анализатором:

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

Следующие две проблемы — также частые гости устаревших проектов:

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

Хотя пример выше это совсем уж старый код, поскольку метод Arrays.asList () появился еще в Java 7 — былинные времена далекого прошлого, как можно было его сохранить до сих пор — загадка.

Эпилог

Если вы никогда не видели JPC то стоит посмотреть, поскольку он в свое время несколько расширил мнение о возможности Java, в первую очередь в плане производительности — тема о которой много и сильно шутили еще 10 лет назад.

Ну а если перед вами стоит задача провести подобный рефакторинг — стадии с первой по четвертую фактически являются руководством к действию.

Массовые правки я бы с ходу делать не рекомендовал — очень уж высокие риски, что что‑то пойдет не так.

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

P.S.

Статья была опубликована на Хабре,  оригинал доступен в нашем блоге.

Все началось когда автор наткнулся на одну интересную статью где эксперт по 3D-технологиям вместил специально оптимизированный и обфусцированный код рейтрейсера на C++ в размеры своей визитки.

Вот такой код:

#include <stdlib.h> // card > aek.ppm
#include <stdio.h>
#include <math.h>
typedef int i;typedef float f;struct v{
f x,y,z;v operator+(v r){return v(x+r.x
,y+r.y,z+r.z);}v operator*(f r){ return
v(x*r,y*r,z*r);}f operator%(v r){return
x*r.x+y*r.y+z*r.z;}v(){}v operator^(v r
){return v(y*r.z-z*r.y,z*r.x-x*r.z,x*r.
y-y*r.x);}v(f a,f b,f c){x=a;y=b;z=c;}v
operator!(){return*this*(1/sqrt(*this%*
this));}};i G[]={133022, 133266,133266,
133022, 254096, 131216, 131984, 131072,
258048,};f R(){return(f)rand()/RAND_MAX
;}i T(v o,v d,f&t,v&n){t=1e9;i m=0;f p=
-o.z/d.z; if(.01<p)t=p, n=v(0,0,1),m=1;
for(i k=19;k--;)for(i j=9;j--;)if(G[j]&
1<<k){v p=o+v(-k,0,-j-4);f b=p%d,c=p%p-
1,q=b*b-c;if(q>0){f s=-b-sqrt(q);if(s<t
&&s>.01)t=s,n=!(p+d*t),m=2;}}return m;}
v S(v o,v d){f t;v n;i m=T(o,d,t,n);if(
!m)return v(.7,.6,1)*pow(1-d.z,4);v h=o
+d*t,l=!(v(9+R(),9+R(),16)+h*-1),r=d+n*
(n%d*-2);f b=l%n;if(b<0||T(h,l,t,n))b=0
;f p=pow(l%r*(b>0),99);if(m&1){h=h*.2;
return((i)(ceil(h.x)+ceil(h.y))&1?v(3,1
,1):v(3,3,3))*(b*.2+.1);}return v(p,p,p
)+S(h,r)*.5;}i main(){printf("P6 512 "
"512 255 ");v g=!v(-6,-16,0),a=!(v(0,0,
1)^g)*.002,b=!(g^a)*.002,c=(a+b)*-256+g
;for(i y=512;y--;)for(i x=512;x--;){v p
(9,9,9);for(i r=64;r--;){v t=a*(R()-.5)
*99+b*(R()-.5)*99;p=S(v(17,16,8)+t,!(t*
-1+(a*(R()+x)+b*(y+R())+c)*16))*3.5+p;}
printf("%c%c%c",(i)p.x,(i)p.y,(i)p.z);}}

После компиляции:

c++ -O3 -o card card.cpp

Генерировал у автора вот такую картинку:

Мы позеленели от зависти тоже захотели себе что-то такое, но поскольку занимаемся все же серверами а не 3D-графикой и больше Java, чем C++ — решили что будет круто уместить на обратной стороне нашей визитки простейший HTTP-сервер на Java.

Вместе с запуском и компиляцией.

Еще при наличии графического окружения будет запущен браузер.

Плюс немного криптографии для защиты от подделки.

Весь код уместился в 18 строк, выровненных по ширине так чтобы влезть в размеры визитки:

Вбиваете код с визитки в любимый редактор, сохраняете файл как vcard.sh и запускаете:

chmod +x ./vcard.sh
./vcard.sh

Результат:

Локально запустится простейший HTTP-сервер, который отдаст текстовую страничку с нашими контактами. При наличии GUI  — запустится еще и браузер по-умолчанию, с автоматическим открытием страницы этого сервера.

И все это в 18 строк кода.

Да, еще будет нужен любой Linux/BSD/MacOS/Solaris и любая версия JDK начиная с 1.8 на машине.

Поддержку запуска на Windows делать не стал (хотя это и возможно технически), но можно спокойно запустить в WSL .

Чтобы вы не мучились с вводом кода с картинки, вот текстовая версия:

#!/bin/sh
t=$(mktemp -d);e=$(realpath $0);sed '1,4d' $0|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java
cd $t;javac -XDignore.symbol.file -cp . Yo.java && java -cp . Yo $e;exit 0
i com.sun.net.httpserver.*;i j.awt.Desktop;i j.io.*;i j.util.*;i j.net.*;i j.nio.file.*;
i java.security.MessageDigest;i javax.crypto.Cipher;i javax.crypto.spec.SecretKeySpec;
p class Yo{p static void main(String[]args)throws E!{Cipher dcipher=Cipher.getInstance("AES");
dcipher.init(2,new SecretKeySpec(Arrays.copyOf(MessageDigest.getInstance("SHA-1").digest(
new String(Files.readAllBytes(Paths.get(args[0]))).replaceFirst("ED=\"([^<]*)\";","")
.trim().getBytes()),16),"AES"));String ddata=new String(dcipher.doFinal(Base64.getDecoder()
.decode(ED)),"U8!");int p=8000;String h="0x7f000001";HttpServer s=HttpServer.create()
.createContext("/",(HttpExchange t)->{String r=String.format(ddata,System.nanoTime());t.getRE?()
.set("Content-type","text/plain;charset=U8!");t.sendRE?(200,r.getBytes("U8!").length);
try(OutputStream os=t.getResponseBody()){os.write(r.getBytes("U8!"));}}).getServer();
s.bind(new InetSocketAddress(p),1);new Timer().schedule(new TimerTask(){public void run(){
if(!Desktop.isDesktopSupported()){System.out.println(ddata);return;}try{Desktop.getDesktop()
.browse(new URI("http://"+h+":"+p));}catch(E! e){throw new RuntimeE!(e);}}},2000);s.start();}
static String ED="TfPrCIlXEUInGJPpr4++hQfa2Whq4RFzdbFP5C4s/s8=";}

Ну разве не прелесть?

Как это работает

Тут используется связка из заголовочного shell-скрипта и слегка обфусцированного кода на Java. Еще я не стал кодировать весь блок на Java полностью в HEX-строку, чтобы визуально оставалось ощущение исходного кода.

Начнем с заголовочного скрипта:

#!/bin/sh
t=$(mktemp -d);e=$(realpath $0);sed '1,4d' $0|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java
cd $t;javac -XDignore.symbol.file -cp . Yo.java && java -cp . Yo $e;exit 0

Самая первая строчка:

#!/bin/sh

Это shebang, стандартное для Unix указание на используемый интерпретатор, про него и так все знают. Дальше происходит создание временного каталога в /tmp и присваивание его имени переменной в скрипте:

t=$(mktemp -d);

Затем получение скриптом собственного имени с полным путем:

e=$(realpath $0);

Чтение скриптом самого себя, с отрезанием первых 4х строк - чтобы получить блок кода на Java:

sed '1,4d' $0

Дальше начинается pipe, в котором результат предыдущей команды передается на вход следующей:

|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java

Результат всех преобразований записывается в файл Yo.java, в том самом временном каталоге.

Малоизвестная опция -XDignore.symbol.file отключает предупреждение об использовании системных классов JDK (com.sun.net.httpserver.*) в проекте — в 1.8 версии классы встроенного в JDK HTTP-сервера еще считались системными.

Запуск с передачей полного пути оригинального скрипта для последующего его чтения из Java-кода:

java -cp . Yo $e

Сам код после деобфускации и форматирования выглядит уже вот так:

import com.sun.net.httpserver.*;
import java.awt.Desktop;
import java.io.*;
import java.util.*;
import java.net.*;
import java.nio.file.*;
import java.security.MessageDigest;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
public class Yo {
public static void main(String[] args) throws Exception {
Cipher dcipher = Cipher.getInstance("AES");
dcipher.init(2,
new SecretKeySpec(Arrays.copyOf(
MessageDigest.getInstance("SHA-1").digest(
new String(Files.readAllBytes(Paths.get(args[0])))
.replaceFirst("ED=\"([^<]*)\";", "")
.trim().getBytes()), 16), "AES"));
String ddata = new String(dcipher.doFinal(Base64.getDecoder()
.decode(ED)), "UTF-8");
int p = 8000;
String h = "0x7f000001";
HttpServer s = HttpServer.create()
.createContext("/", (HttpExchange t) -> {
String r = String.format(ddata, System.nanoTime());
t.getResponseHeaders()
.set("Content-type", "text/plain;charset=UTF-8");
t.sendResponseHeaders(200, r.getBytes("UTF-8").length);
try (OutputStream os = t.getResponseBody()) {
os.write(r.getBytes("UTF-8"));
}
}).getServer();
s.bind(new InetSocketAddress(p), 1);
new Timer().schedule(new TimerTask() {
public void run() {
if (!Desktop.isDesktopSupported()) {
System.out.println(ddata);
return;
}
try {
Desktop.getDesktop()
.browse(new URI("http://" + h + ":" + p));
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}, 2000);
s.start();
}
static String ED = "1AtzGU0uq7J7DHPdjdJJ5JJDiwQi8mElIDOjuRK0DEU=";
}

Тут уже большая часть логики вполне очевидна, поэтому раскрою лишь два самых сложных фрагмента.

Криптография

Когда я только начинал думать над реализацией этой штуки, уже было ясно что нужен какой-то неочевидный контроль целостности:

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

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

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

static String ED = "1AtzGU0uq7J7DHPdjdJJ5JJDiwQi8mElIDOjuRK0DEU=";

Именно тут находится текст:

We write software. @alex0x08

На каждую попытку как-то подменить содержимое (включая заголовок) будет выдаваться вот такая ошибка:

Exception in thread "main" javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption. at java.base/com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:981) at java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1062) at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) at Yo.main(Yo.java:6)

Получается код сам себя защищает от подделки.

0x7f000001

Вторым неочевидным моментом является вот такой странный адрес хоста:

String h = "0x7f000001";

Который используется при формировании ссылки для открытия браузером:

Desktop.getDesktop().browse(new URI("http://" + h + ":" + p));

Такое применение однозначно говорит о том что адрес очень даже стандартный, поскольку проходит как стадию валидации на стороне Java при формировании объекта URI, так и валидацию на стороне запускаемого браузера.

Это просто нотация, вариант написания IP-адреса 127.0.0.1, обозначающего loopback (петлю) — внутренний интерфейс, к которому можно подключиться локально, а не из сети.

Вот тут больше примеров различных вариантов написания IP-адресов, уверен — удивит даже бывалых админов.

P.S.

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