Java Portal | Программирование
12.1K subscribers
951 photos
69 videos
32 files
756 links
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика

Связь: @devmangx

РКН: https://clck.ru/3H4WUg
Download Telegram
Что такое Fat JAR в Java?

Fat JAR (он же Uber JAR) — это единый исполняемый .jar-файл, который содержит как классы вашего приложения, так и все его зависимости.

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

Просто запускается командой:

java -jar myapp-fat.jar


Зачем использовать Fat JAR?

🔹Портируемость — удобно распространять и развёртывать
🔹Простота — не нужно возиться с classpath и отлавливать ClassNotFoundException
🔹Отлично подходит для микросервисов и Docker — один артефакт, одна команда запуска

Как собрать Fat JAR

👉 С помощью Maven (maven-assembly-plugin)

Добавьте в pom.xml:

<!-- пример конфигурации (на 2 фото) -->


Соберите:

mvn clean package


Готовый JAR будет лежать в:

target/myapp-jar-with-dependencies.jar


👉 С помощью Maven (maven-shade-plugin)

Если нужен контроль над пересборкой пакетов и теневыми зависимостями — используйте Shade:

<!-- пример конфигурации на 3 фото -->


Сборка аналогично — итоговый файл будет в:

target/myapp-shaded.jar


👉 С помощью Gradle

В build.gradle добавьте:

// пример конфигурации на 4 фото


Запуск сборки:

./gradlew fatJar


Пример: Минимальное Java-приложение

// 5 фото

С учётом вышеописанных конфигураций Maven или Gradle, все зависимости будут включены в .jar — достаточно java -jar.

Некоторые команды не используют fat JAR для крупных приложений, чтобы:

> Ускорить сборку
> Снизить использование диска
> Упростить обновление отдельных зависимостей без пересборки всего артефакта

Fat JAR упаковывает всё необходимое для простого и портируемого деплоя Java-приложений

Собирается через Maven (плагины assembly или shade) или Gradle
Альтернативы: thin JAR, WAR/EAR, Spring Boot plugin, контейнеры

Выбирайте fat JAR, если важны простота и переносимость, особенно в микросервисной архитектуре и для деплоя в облаке.

👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥42
Лучший способ использовать методы запросов Spring Data

Читать подробнее

👉 Java Portal | #cтатья
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥2
Зачем использовать `@ConditionalOnProperty`?

- Включение или отключение бинов и конфигураций на основе значений в `application.properties` без изменения кода
- Загрузка разных бинов для разных сред с помощью конфигурационных параметров
- Исключение лишних бинов снижает потребление памяти и упрощает логику

🔸Включить бин, если свойство существует:
Используется аннотация @ConditionalOnProperty(name="my.prop").
Бин будет создан, если свойство my.prop существует и его значение не "false".

🔸Включить бин, если свойство равно определённому значению:
Добавляется параметр havingValue="yes".
Бин будет создан только в том случае, если значение свойства строго равно "yes".

🔸Включить бин, если свойство отсутствует:
Используется параметр matchIfMissing=true.
Бин будет создан даже в случае, если соответствующее свойство вообще не определено в конфигурации.

🔸Переключение реализаций в зависимости от значения свойства:
Определяются несколько бинов с разными значениями havingValue.
Будет создан только тот бин, значение которого соответствует текущему значению свойства.


👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍43
Жара в IT! Теперь популярные языки программирования можно легко выучить по гайдам в картинках

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

👩‍💻 Linux Ninja

🖥 CodHub | Курсы IT

📱 Python | Программирование

😷 Hacking | Кибербезопасность

⚙️ Webdev | Backend & Frontend

🖥 Программирование по мемам
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍2🔥1😁1
Лучшие практики работы с транзакциями Spring

Читать подробнее

👉 Java Portal | #cтатья
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍3
Spring Boot Actuator это мощный набор инструментов в составе Spring Boot, который помогает мониторить и управлять приложением в продакшене. Он предоставляет доступ к различным endpoint'ам, через которые можно получить информацию о внутреннем состоянии приложения - метрики, окружение, дампы потоков и т.д.

Что даёт Actuator:

- статус, метрики, окружение и прочее
- Поддержка мониторинга и управления через HTTP, JMX или кастомные endpoint'ы
- Повышенная наблюдаемость, особенно в связке с Prometheus, Grafana, Micrometer или Spring Boot Admin

Часто используемые endpoint'ы:

🔸/actuator/health
Показывает статус работоспособности приложения
Доступ по умолчанию: Public

🔸/actuator/info
Выводит информацию из application.properties
Доступ по умолчанию: Public

🔸/actuator/metrics
Показывает различные метрики производительности
Доступ по умолчанию: Restricted

🔸/actuator/env
Показывает переменные окружения
Доступ по умолчанию: Restricted

🔸/actuator/beans
Показывает все Spring Beans
Доступ по умолчанию: Restricted

🔸/actuator/threaddump
Дамп потоков приложения
Доступ по умолчанию: Restricted

🔸/actuator/loggers
Просмотр или изменение уровней логирования на лету
Доступ по умолчанию: Restricted

🔸/actuator/heapdump
Скачивание heap dump
Доступ по умолчанию: Restricted

🔸/actuator/prometheus
Метрики в формате Prometheus (если подключён micrometer-registry-prometheus)
Доступ по умолчанию: Public

👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥2
Лучшие практики для микросервисов

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

2. Единый уровень зрелости кода
🔸Старайтесь поддерживать код всех сервисов примерно на одинаковом уровне зрелости (тестируемость, покрытие, качество).

3. Отдельная сборка для каждого микросервиса
🔸У каждого сервиса должна быть своя сборочная цепочка (CI/CD pipeline), чтобы обеспечить независимость деплоя.

4. Принцип единственной ответственности
🔸Один сервис — одна бизнес-задача. Не смешивайте домены и обязанности в рамках одного микросервиса.

5. Развёртывание в контейнерах
🔸Используйте контейнеры (например, Docker) для упаковки и запуска каждого микросервиса независимо.

6. Обрабатывайте серверы как статeless
🔸Сервисы не должны хранить состояние между запросами. Состояние — либо в БД, либо во внешнем хранилище.

7. Domain-Driven Design (DDD)
🔸Стройте архитектуру на основе бизнес-домена: делите систему на логически обоснованные сервисы, а не технические модули.

8. Микрофронтенд
🔸Разделяйте frontend-приложения по тому же принципу, что и backend: независимые фронты взаимодействуют через API Gateway.

9. Оркестрация микросервисов
🔸Используйте системы оркестрации (например, Kubernetes), чтобы управлять масштабированием, деплоем и связью между сервисами.

👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM