🧠JAVA ИСПОЛЬЗУЙ TREESET ПРАВИЛЬНО #java

Если в Java нужно убрать дубликаты из списка и отсортировать элементы - используй TreeSet. Он автоматически удаляет повторяющиеся значения и сортирует их либо по естественному порядку, либо по кастомному правилу через Comparator.

Естественный порядок
List<String> colors = Arrays.asList("red", "green", "red", "orange", "turquoise");
Set<String> colorsSet = new TreeSet<>(colors);
for (String color : colorsSet) {
    System.out.println(color);
}

Сортировка по длине строки
Comparator<String> byLength = Comparator.comparingInt(String::length);
Set<String> sortedSet = new TreeSet<>(byLength);
sortedSet.addAll(colors);
for (String color : sortedSet) {
    System.out.println(color);
}

💡 Java совет: рекурсивная обработка файлов с Files.walk()

Если нужно пройтись по всем файлам в директории и её подкаталогах, не пиши рекурсию вручную — используй Files.walk().

Пример: найти все `.java`-файлы в проекте

Path startPath = Paths.get("src");

try (Stream<Path> paths = Files.walk(startPath)) {
    paths
        .filter(Files::isRegularFile)
        .filter(path -> path.toString().endsWith(".java"))
        .forEach(System.out::println);
} catch (IOException e) {
    e.printStackTrace();
}

Почему это хороший подход:

- Рекурсивный обход «из коробки»
- Работает через Stream API
- Легко фильтровать, маппить и агрегировать
- Автоматически закрывает ресурсы (try-with-resources)

Полезно для:

- анализа исходников
- линтеров и кодогенерации
- поиска файлов по расширению
- утилит и dev-скриптов

#Java #IO

⚡ Spring Boot: как отключить лишнюю авто-конфигурацию

Иногда Spring Boot запускает больше, чем вам нужно.

Если у вас:
- кастомная конфигурация
- конфликт с дефолтными настройками
- ошибки при старте DataSource или JPA
— проблема может быть в auto-configuration.

Решение — отключить ненужные модули через @SpringBootApplication.

Пример:

@SpringBootApplication(
    exclude = {
        DataSourceAutoConfiguration.class,
        HibernateJpaAutoConfiguration.class
    }
)
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

Когда это полезно:

• вы используете свою конфигурацию базы
• приложение не работает с БД, но зависимости есть
• тестовые или lightweight-сервисы
• миграция старого проекта

Spring Boot умный.
Но иногда ему нужно сказать: “не делай это за меня”.

#SpringBoot #Java #Backend

🚀 Spring Boot: не отдавайте JPA Entity напрямую в API - используйте DTO на границах

Если возвращать Entity из контроллера, вы жёстко связываете API с внутренней моделью базы. Любое изменение в persistence-слое может сломать внешний контракт.

DTO решает сразу несколько проблем:

• API становится независимым от слоя данных
• Избегаете ошибок LazyInitializationException
• Не утечёт лишняя информация (например, password, internalNote)
• Улучшается безопасность и контроль над тем, что видит клиент

Идея простая:
Entity - для базы
DTO - для API

Конвертируйте Entity → DTO в сервисе или через mapper (MapStruct / manual mapping).

Чистые границы = стабильный API и меньше багов.

#SpringBoot #Java #Backend #SoftwareEngineer

⚠️ Spring Boot: не включайте publish-request-params в production

В Spring Boot есть настройка:

spring.mvc.publish-request-params=true

Она включает логирование параметров HTTP-запросов.

Это удобно в dev-среде, потому что можно видеть:

• request headers
• query parameters
• form data

Обычно это используют вместе с фильтром:

@Bean
public CommonsRequestLoggingFilter logFilter() {
    CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter();
    filter.setIncludeQueryString(true);
    filter.setIncludeHeaders(true);
    filter.setIncludePayload(true);
    filter.setMaxPayloadLength(1000);
    filter.setAfterMessagePrefix("COMPLETE REQUEST: ");
    return filter;
}

Но есть важная проблема.

В production такие логи могут случайно сохранить чувствительные данные пользователей.

Например:

POST /login
{
  "username": "john",
  "password": "mypassword"
}

Если включено логирование payload, такие данные могут попасть в:

• application logs
• log-агрегаторы
• мониторинг системы

А это уже серьёзная уязвимость безопасности.

Поэтому правило простое:
- включайте publish-request-params только в dev
- никогда не логируйте request body в production
- маскируйте чувствительные поля (`password`, token, `authorization`)

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

#SpringBoot #Java #Backend #Security

⚡️ Полезные ресурсы по Java 🚀 Max

@javatg

☕ Java Tip: рекурсивный обход файловой системы

В Java есть удобный способ рекурсивно обойти все файлы в директории - метод Files.walk().

Он возвращает Stream<Path>, что позволяет легко фильтровать и обрабатывать файлы через Stream API.

Пример - найти все .java файлы в папке src:

import java.io.IOException;
import java.nio.file.*;
import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        Path startPath = Paths.get("src");

        try (Stream<Path> paths = Files.walk(startPath)) {
            paths
                .filter(Files::isRegularFile)
                .filter(path -> path.toString().endsWith(".java"))
                .forEach(System.out::println);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Что происходит:

• Files.walk(startPath) - рекурсивно проходит по всем папкам
• filter(Files::isRegularFile) - оставляет только файлы
• endsWith(".java") - фильтр по расширению
• forEach - обработка найденных файлов

Это намного чище, чем писать собственную рекурсивную функцию обхода директорий.

#Java #JavaDev #Programming

⚡️ Полезные ресурсы по Java 🚀 Max

@javatg

☕ Java совет: сравнение времени без ловушек точности

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

Например:

Instant a = Instant.parse("2025-10-01T10:42:11Z");
Instant b = Instant.parse("2025-10-01T10:42:44Z");

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

Используйте Instant.truncatedTo():

boolean sameMinute =
    a.truncatedTo(ChronoUnit.MINUTES)
     .equals(b.truncatedTo(ChronoUnit.MINUTES));

System.out.println(sameMinute); // true

Метод truncatedTo() обрезает время до нужной точности:

• ChronoUnit.MINUTES
• ChronoUnit.HOURS
• ChronoUnit.DAYS

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

Полезно для:

• логов
• временных окон
• аналитики
• дедупликации событий

Маленький приём —
но часто спасает от неочевидных багов в time-логике.

#Java #JavaDev #Backend #Programming

⚡️ Полезные ресурсы по Java 🚀 Max

@java_library

🚀 Java 26 стала умнее — особенно в pattern matching

Теперь работа с pattern matching выражениями стала заметно стабильнее и предсказуемее

Что улучшили:

🟢 Более надёжный type inference
компилятор лучше понимает типы в сложных условиях

🟢 Меньше edge-case ошибок
меньше неожиданных падений и предупреждений

🟢 Консистентное поведение
одинаковая логика в if и switch

Что это даёт на практике:

раньше при усложнении условий
компилятор мог “теряться”

теперь:
- анализ потока стал умнее
- переменные из pattern matching корректно распознаются
- код становится чище и безопаснее

Java становится всё ближе к современным языкам
с удобным и предсказуемым контролем типов

#Java #JavaDev

⚡️ Полезные ресурсы по Java 🚀 Max

@javatg

🚀 Java - regex без боли

Нашли интересную библиотеку - Sift. Она заменяет весь этот ад с регулярками на нормальный fluent API.

Теперь вместо нечитаемых строк вида:
^[0-9a-fA-F]{6}$

Пишешь код, который реально понимаешь:
.char('#')
.then()
.exactly(6)
.hexDigits()

📌 Что это дает:
- Читаемый и понятный код
- Меньше ошибок в regex
- Быстрее разработка и поддержка

По сути — это как “переводчик” с языка регулярных выражений на человеческий Java-код.

Если когда-нибудь ломал голову над regex -это прям must-have.

#Java #JavaDev

📌 Magic numbers в Java - мелкая привычка, которая потом превращает поддержку кода в археологию.

Когда в коде встречается 86400, 7, 1.21 или 5000, компилятору всё равно. Человеку - нет. Через месяц уже приходится вспоминать, что это было: секунд в дне, дней сессии, НДС или задержка перед повторной попыткой.

Плохой вариант выглядит так:

if (sessionAgeSeconds > 86400 * 7)

Формально код работает. Но смысл спрятан внутри чисел.

Нормальный вариант:

SECONDS_PER_DAY
SESSION_DAYS
VAT_RATE
RETRY_DELAY_MS

Теперь намерение видно прямо в месте вызова. Не нужно угадывать, почему именно 7, что означает 5000 и можно ли безопасно поменять значение.

Это особенно важно в бизнес-логике, где числа редко бывают случайными. Лимиты, комиссии, таймауты, скидки, сроки жизни сессии, количество попыток - всё это правила продукта, а не просто цифры в коде.

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

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

#java #cleancode

💡 Редкий совет Java: используйте `ClassValue` для кэша, привязанного к классу

Обычно метаданные кэшируют так:

Map<Class<?>, Metadata> cache = new ConcurrentHashMap<>();

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

Для подобных случаев в Java есть ClassValue:

private static final ClassValue<Metadata> CACHE =
new ClassValue<>() {
@Override
protected Metadata computeValue(Class<?> type) {
return inspect(type);
}
};

Metadata metadata = CACHE.get(User.class);

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

ClassValue особенно полезен для reflection-кэшей, сериализаторов, ORM, прокси и плагинных архитектур.

Редкий инструмент JVM, который часто безопаснее, чем ConcurrentHashMap<Class<?>, ...>.

#Java #JVM #Backend #Performance

💡 Java cj: unmodifiableList() не делает настоящую копию

Эти два варианта выглядят похоже, но работают по-разному:

List<String> source = new ArrayList<>();
source.add("Java");

List<String> view = Collections.unmodifiableList(source);
List<String> copy = List.copyOf(source);

source.add("Spring");

System.out.println(view); // [Java, Spring]
System.out.println(copy); // [Java]

Collections.unmodifiableList() создаёт только неизменяемое представление исходного списка. Если source изменится, изменения появятся и в view.

List.copyOf() создаёт отдельный неизменяемый снимок данных.

Используйте:

- unmodifiableList() — когда нужен read-only view актуального списка;
- List.copyOf() — когда нужно зафиксировать состояние и безопасно вернуть его наружу.

public List<String> getUsers() {
    return List.copyOf(users);
}

Так внешний код не сможет изменить внутреннюю коллекцию, а последующие изменения users не повлияют на уже возвращённый результат.

List.copyOf() доступен начиная с Java 10.

#Java #JavaTips #Backend

💡 Java совет: два пути могут указывать на один и тот же файл

Path.equals() сравнивает только представление пути:

Path a = Path.of("data.txt");
Path b = Path.of("./data.txt");

System.out.println(a.equals(b)); // false

Хотя оба пути могут вести к одному файлу.

Для проверки используйте:

boolean same = Files.isSameFile(a, b);

Files.isSameFile() обращается к файловой системе и учитывает:

- относительные пути;
- символические ссылки;
- реальное расположение файла.

Path file = Path.of("data.txt");
Path link = Path.of("data-link.txt");

Files.isSameFile(file, link); // true, если link ведёт к data.txt

Полезно при поиске дубликатов, проверке пользовательских путей и защите от повторной обработки одного файла.

Учтите: метод может обращаться к диску и выбрасывать IOException, поэтому это не просто строковое сравнение.

Доступно начиная с Java 7.

#Java #JavaTips #Files

⚡️ Java-приём: не храни метаданные классов в `static Map<Class<?>, ...>` — используй `ClassValue`.

Допустим, библиотека кеширует информацию о каждом классе:

private static final Map<Class<?>, Metadata> CACHE =
        new ConcurrentHashMap<>();

На первый взгляд всё нормально.

Но в приложениях с динамической загрузкой классов — plugins, application servers, hot reload — такой кеш может удерживать Class, а вместе с ним и его ClassLoader.

И получить неприятную утечку памяти.

В Java для этого есть малоизвестный ClassValue<T>:

private static final ClassValue<Metadata> CACHE =
        new ClassValue<>() {
            @Override
            protected Metadata computeValue(Class<?> type) {
                return buildMetadata(type);
            }
        };

Использование:

Metadata metadata = CACHE.get(MyClass.class);

Что даёт ClassValue:

- ленивое вычисление значения для каждого класса;
- thread-safe доступ;
- не нужен собственный ConcurrentHashMap;
- кеш лучше согласован с жизненным циклом загруженных классов.

Особенно полезно для reflection, serializers, ORM, DI-контейнеров и framework-кода, где постоянно кешируются данные по Class<?>.

🔥 Если видишь в библиотеке:

static ConcurrentHashMap<Class<?>, ...>

стоит хотя бы задать вопрос:

а почему здесь не `ClassValue`?

#Java #JVM #Backend #Programming