Spring Boot. С помощью @DataJpaTest можно прогонять JPA репозитории изолированно.

@DataJpaTest поднимает только JPA слой без всего приложения, использует in-memory базу H2 и откатывает транзакции после каждого теста.

👉 Java Portal

Поток обработки запроса в Spring Boot

Вопрос на собеседовании: как проходит HTTP-запрос внутри Spring Boot приложения?

Звучит просто, но на практике сложно правильно восстановить порядок и технические детали.

• клиент отправляет HTTP-запрос
• запрос сначала попадает в DispatcherServlet (Front Controller)
• DispatcherServlet через HandlerMapping ищет нужный контроллер
• контроллер занимается маппингом запроса и валидацией
• бизнес-логика выполняется в сервисном слое
• работа с базой идет через репозиторий (JPA)
• ответ идет обратно по тому же пути и сериализуется в JSON через Jackson

👉 Java Portal

Spring Boot: чтобы прогнать SQL-скрипты до или после выполнения тестового метода, можно использовать аннотацию @Sql.

@SpringBootTest
@Sql("/test/products.sql")
class ProductServiceTest {

    @Autowired
    ProductService productService;

    @Test
    void findProductByName() {
        Product product = productService.findByName("product1");
        assertThat(product).isNotNull();
    }
}

👉 Java Portal

Что такое Throwable

Throwable в Java — это базовый класс для всех «бросаемых» аномалий. Он даёт общий функционал для работы с исключениями: стек, причину, вложенные ошибки и т. д.

С точки зрения модели: невосстанавливаемые критические состояния представлены через Error, а ошибки уровня приложения — через Exception.

То есть всё, что можно бросать (throw), наследуется от Throwable.

Коротко:

Error: обычно невосстанавливаемая и не предполагается обработка на уровне приложения
Exception: приложение может предусматривать и обрабатывать

checked: обработка контролируется компилятором
unchecked: обработка не принудительная

Иерархия выглядит примерно так:

java.lang.Object
 └─ java.lang.Throwable        // всё, что можно throw-нуть
      ├─ java.lang.Error       // системные критические сбои
      │    ├─ OutOfMemoryError
      │    ├─ StackOverflowError
      │    ├─ VirtualMachineError
      │    └─ ...
      └─ java.lang.Exception   // исключения уровня приложения
           ├─ RuntimeException // unchecked
           │    ├─ NullPointerException
           │    ├─ IllegalArgumentException
           │    ├─ IndexOutOfBoundsException
           │    └─ ...
           └─ IOException, SQLException (checked)

Разница между Error и Exception

Error — «фатальный и невосстанавливаемый сбой»
Exception — «аномалия, которую приложение может ожидать и обрабатывать»

Мини сравнение:

источник: Error приходит от JVM и рантайма, Exception рождается на уровне приложения
восстановление: у Error почти нулевые шансы, у Exception всё зависит от ситуации
catch: Error обычно не ловят, Exception ловят и обрабатывают
примеры: для Error — OOM, StackOverflow; для Exception — неверный ввод или I/O ошибки

Что такое Error

Это фатальные сбои JVM.
Не то, что будут фиксить в бизнес-логике.

Примеры: OutOfMemoryError, StackOverflowError, VirtualMachineError

Почему их не ловят?

предпосылки работы программы уже нарушены
даже если поймать — непонятно, что делать дальше
нормальная стратегия — дать процессу упасть

Что такое Exception

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

checked: IOException, SQLException
unchecked: NullPointerException, IllegalArgumentException

Почему их обрабатывают?
Потому что они «возможны по контракту» — неверный ввод, I/O, бизнес-валидация и т. д.

Почему в GlobalExceptionHandler не ловят Throwable

Потому что обработка Throwable приводила бы к поглощению Error (фатальных ошибок), и приложение продолжило бы работать в «сломанных» условиях.

Подробности:

➡️Поглощение Error
Если OutOfMemoryError превратить в обычный 500, то это попытка «делать вид, что всё ок», в то время как приложение фактически в предсмертном состоянии.

➡️Ломается контрольный поток фреймворка
Например, в Spring разное поведение завязано на тип исключения. Throwable ломает эти правила.

➡️Падает наблюдаемость
«Ловить всё» засоряет логи шумом и усложняет поиск корня проблемы.

Отсюда правило: в GlobalExceptionHandler ловят не Throwable, а Exception (или RuntimeException) как конечный уровень обработки в приложении.

👉 Java Portal

Spring Boot: можно переопределять конфиги на рантайме без перепаковки приложения.

Spring Boot по умолчанию использует лаунчер JarLauncher, который позволяет переопределить дефолтную конфигурацию через параметр loader.path при запуске приложения.

Предположим, у вас есть Spring Boot приложение со следующими зависимостями:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

С application.properties такого вида:

demo.message=Hello from inside the JAR

И простой контроллер:

@RestController
public class HelloController {

    @Value("${demo.message}")
    private String message;

    @GetMapping("/")
    public String hello() {
        return message;
    }
}

Если собрать jar и запустить:

java -jar springboot-propertieslauncher-demo-0.0.1-SNAPSHOT.jar

Открыв [https://localhost:8080](https://localhost:8080) вы получите:

Hello from inside the JAR

Если теперь создать внешний файл application.properties в той же директории, где лежит jar:

demo.message=Hello from outside the JAR

И запустить приложение с параметром loader.path, указывающим на текущую директорию:

java -jar springboot-propertieslauncher-demo-0.0.1-SNAPSHOT.jar --loader.path=.

Перейдя в [https://localhost:8080](https://localhost:8080) будет:

Hello from outside the JAR

👉 Java Portal

JetBrains вбросили загадку про IntelliJ IDEA. Судя по всему, кто-то пытается незаметно попасть на их день рождения. Команда решила устроить мини-квест: каждый день будет новая задачка, новые подсказки и в итоге надо вычислить тайного гостя вечеринки. 😂

В первом задании предлагают сопоставить сниппеты кода с версиями Java. Там набор вполне узнаваемых фич: var, streams, diamond-оператор, enum и records. Ниже варианты: Java 5, 7, 8, 11, 17 и 21.

Выглядит легко, но подана история забавно, а оформление в стиле карты-загадки.

👉 Java Portal

Новый способ регистрировать бины программно начиная со Spring Framework 7 👇👇👇

@Configuration
@Import(ExampleRegistrar.class)
class ExampleConfiguration {
}

class ExampleRegistrar implements BeanRegistrar {

    @Override
    public void register(BeanRegistry registry, Environment env) {
        if (env.matchesProfiles("dev")) {
            registry.registerBean(ExampleInMemoryRepository.class);
        } else {
            registry.registerBean(ExampleRepository.class);
        }
    }
}

👉 Java Portal

В старые времена на Java самое дорогое выражение, которое я видел в проде, выглядело невинно:

→ repository.findAll()

Компилируется, тесты проходит, на QA тоже всё ок потому что данных мало.

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

показательный случай про цену подобных ошибок:

• ракета Ariane 5
• стоимость проекта — 370 млн
• в коде было преобразование 64-битного значения к 16-битному
• при ускорении значение вышло за пределы
• произошёл overflow, навигация отказала
• запуск провалился, 370 млн просто улетели

Вывод: неограниченные операции в коде — всегда риск.

Из той же категории:

• collect(toList()) на огромных стримах
• @Transactional прямо на контроллерах
• synchronized на нагруженном месте

👉 Java Portal

Java-совет : выносите повторяющуюся логику в небольшие вспомогательные классы, но не скатывайтесь в всезнающие God-классы.

Пример helper-класса:

public class TextUtils {
    public static String capitalize(String str) {
        ...
    }
    ...
}

А вот это уже God-класс:

public class DoThings {
    public void addTask(String task) { ... }
    public void saveToFile(String filename) { ... }
    public void logError(String error) { ... }
    ...
}

Он делает слишком много несвязанных вещей.

👉 Java Portal

Реализация гексагональной архитектуры на Java

В данной статье рассматривается архитектура проекта, позволяющая модульным образом интегрировать инфраструктурные фреймворки, такие как Spring, Quarkus и Micronaut, без необходимости модификации ядра предметной области (domain) или внешних API.

👉 Java Portal

Java: исключения в Java делятся на две основные категории: checked и unchecked.

Checked-исключения нужно либо перехватывать, либо объявлять.

Unchecked-исключения не нужно объявлять в throws у метода, и компилятор не требует их перехватывать, хотя при необходимости их тоже можно ловить.

// Проверяемые (checked)
try {
    FileReader reader = new FileReader("file.txt"); //FileNotFoundException (проверяемое)
} catch (FileNotFoundException e) {
    e.printStackTrace();
}

// Непроверяемые (unchecked)
String nullText = null;
System.out.println(nullText.length()); //NullPointerException (непроверяемое)

👉 Java Portal