Похоже, это претендент на TUI года ⭐️

gitlogue — инструмент для «кинематографичного» воспроизведения Git-коммитов прямо в терминале.

Смотри, как коммиты развертываются с анимацией ввода, подсветкой синтаксиса и живым обновлением дерева файлов.

Буквально наблюдай, как твой репозиторий пишет себя сам.

Написан на Rust

GitHub: https://github.com/unhappychoice/gitlogue

👉 Java Portal

Часто мы пишем public static void main и просто предполагаем, что Java сама «делает свою работу».

Но за этим стоит довольно сложная и интересная система , а именно ClassLoader’ы.

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

Без ClassLoader’ов нет JVM, нет Spring, нет плагинов, вообще ничего нет.

Что такое ClassLoader?

Это компонент JVM, который отвечает за:

- Поиск определения класса (файлы .class, JAR’ы, модули).
- Загрузку его в память.
- Проверку байткода на валидность и безопасность.
- Определение класса в изолированном пространстве.

Проще говоря, он превращает байткод в то, что JVM может исполнять.

Иерархия держит хаос под контролем

В Java используется модель делегирования вверх {parent delegation}

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

Основные загрузчики:

- Bootstrap ClassLoader
Написан на C++, загружает базовые классы языка (java.lang.*, java.util.* и так далее).
Живёт прямо внутри JVM.

- Platform / Extension ClassLoader
Загружает библиотеки самого JDK и системные модули.

- Application ClassLoader
Загружает твои классы, зависимости и весь прикладной код.

Типичный поток загрузки выглядит так:

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

Это не даёт тебе случайно переопределить String, List, Object и другие базовые классы.

Как загружается твой код?

Когда ты запускаешь JAR:

java -jar app.jar

Твой код загружает Application ClassLoader. Процесс простой:

- Проходит по classpath
- Открывает JAR’ы
- Находит .class
- Загружает их по мере необходимости

Загрузка классов происходит по требованию.

Если у тебя 200 классов, а реально используются только 10, будут загружены только эти 10.

Почему это реально важно?

Потому что всё, что мы используем поверх Java, строит свою работу на ClassLoader’ах:

Spring Boot создаёт собственный ClassLoader для загрузки fat JAR’ов.
Модульные приложения используют загрузчики для изоляции компонентов.
Веб-контейнеры вроде Tomcat создают отдельный ClassLoader на каждое приложение.
Плагины (IDEA, Jenkins, Minecraft, OSGi) работают через отдельные загрузчики.
Инструменты hot reload (Spring DevTools, JRebel) зависят от динамической перезагрузки классов.

Зачем это понимать на практике?

Рано или поздно ты столкнёшься с ошибками вида ClassNotFoundException. Понимание ClassLoader’ов даёт отличную точку старта для отладки.

Самые частые проблемы:

ClassNotFoundException — класс отсутствует в classpath текущего загрузчика.
NoClassDefFoundError — класс был доступен, но возникла ошибка при загрузке или верификации.
“Невозможный” ClassCastException — объект вроде бы нужного типа, но Java считает иначе. Обычно это означает, что один и тот же класс был загружен разными ClassLoader’ами.
Memory leak в веб-приложениях — Tomcat некорректно выгружает ClassLoader при redeploy.

Последнее происходит значительно чаще, чем кажется.

ClassLoader’ы это как кровеносная система Java ( их не видно, но без них ничего не работает. )

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

И когда в продакшене что-то падает с ClassNotFoundException, ты точно будешь рад, что разобрался в этом заранее.

👉 Java Portal

Учись разрабатывать API с нуля! 🤓

Этот ресурс бесплатный и включает:

✓ Пошаговый курс по REST API и GraphQL
✓ Как добавить безопасность в свои API
✓ Как монетизировать API

→ http://rapidapi.com/learn

👉 Java Portal

Java-совет : вместо HashSet для enum-типов лучше использовать EnumSet. Он работает быстрее и потребляет меньше памяти.

👉 Java Portal

Spring Boot не прощает клевету на Java

👉 Java Portal

Статья на вечер: где автор сделал свой Spring Boot Starter для разработки Telegram-ботов на Java, чтобы больше не копипастить одни и те же настройки и логику.

Он обернул работу с java-telegram-bot-api в удобный фреймворк с маршрутизацией апдейтов, хендлерами, обработкой ошибок и простым подключением к Spring-приложению.

👉 Java Portal

Совет по Java: возвращайте Collections.emptyList(), List.of() или Set.of() вместо null, чтобы не плодить проверки на null в вызывающем коде.

// ❌ Нужен null-check:

public List<String> findUsers() {
    if (!dataAvailable()) {
        return null; // заставляет вызывающий код проверять на null
    }
    return loadUsers();
}

List<String> users = findUsers();
if (users != null) {
    users.forEach(System.out::println);
}


// ✅ Без null-check:

public List<String> findUsers() {
    if (!dataAvailable()) {
        return Collections.emptyList(); // или List.of()
    }
    return loadUsers();
}

// Вызывающая сторона:
List<String> users = findUsers();
users.forEach(System.out::println); // проверка на null не нужна

👉 Java Portal

Вышел релиз IntelliJ IDEA 2025.3!

В этой версии завезли несколько заметных обновлений – все они подробно описаны и показаны в демках на странице “Что нового”.

Зацени

👉 Java Portal

Java-совет: когда нужно наполнять значения в Map, например списки, удобно использовать computeIfAbsent().

Классический способ:

Map<String, List<String>> map = new HashMap<>();
if (!map.containsKey("key")) {
    map.put("key", new ArrayList<>());
}
map.get("key").add("listValue");

С использованием computeIfAbsent:

map.computeIfAbsent("key", k -> new ArrayList<>())
   .add("listValue");

👉 Java Portal

Твой Dockerfile не "простой". Он просто недописан.

Большинство девов за всю жизнь используют всего 5 инструкций Dockerfile:
FROM, COPY, RUN, EXPOSE, CMD, ну и иногда ENV, если уж прям заморочились. 😱

Вот почему твоя команда Ops и пользователи молча тебя ненавидят.

Вот несколько инструкций, про которые ты, скорее всего, не знаешь:

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

Нет, Kubernetes сам не поймет, что приложение внутри уже сдохло.
Скажи ему, как это проверять. Или дай Ops’ам удовольствие дебажить цикл перезапусков контейнеров в проде.

- SHELL:

По умолчанию это /bin/sh -c. Хочешь другое, используй SHELL.
Меньше экранирования, меньше проблем с кроссплатформой.

- STOPSIGNAL: не оставляй приложение подвисшим.

Задает сигнал, который Docker отправляет при остановке контейнера.
Используй тот сигнал, который твое приложение реально обрабатывает.

Больше никаких зомби-контейнеров и сломанной "корректной остановки".

- ONBUILD

Хочешь сделать базовые образы умнее, используй это.
Хочешь развалить чужой пайплайн, используй неправильно.

- ARG vs ENV: перестань путать "во время сборки образа" и “во время запуска контейнера”,

ARG: существует только во время сборки
ENV: остается в финальном образе

Если ты не понимаешь разницу, не удивляйся, когда приложение ведет себя по-разному на dev и в prod.

- LABEL: метаданные не опциональны.

Это не для красоты. Это нужно инструментам, CI и аудиторам. Потом сам себе спасибо скажешь.

Dockerfile это не шелл-скрипт.
Это продовый код.
Он описывает систему, которую ты поставляешь.

Ты же не выкатываешь наполовину сделанное API, так перестань выкатывать наполовину сделанные образы.
Научись писать Dockerfile, который не отстой. 💩

👉 Java Portal