Java

Java switch expression убирает старую боль со случайно забытым break. В старом switch легко получить тихий баг: пропустил break, и выполнение провалилось в следующий case. В новом варианте каждый case возвращает значение через ->, а break не нужен:

String label = switch (status) {
    case NEW -> "queued";
    case RUNNING -> "in progress";
    case DONE -> "finished";
};

Плюс компилятор следит за полнотой. Добавили новый enum-статус, но не обработали его в switch? Получите compile error, а не странный баг в рантайме. Мелочь, которая делает код короче и безопаснее.

Spring Boot: optimistic locking через `@Version` В JPA/Hibernate можно ловить конфликт обновлений без блокировки строки в базе. Достаточно добавить поле версии:

@Entity
public class Account {
    @Id
    private Long id;

    private BigDecimal balance;

    @Version
    private Long version;
}

Как это работает: Когда Entity читается из базы, Hibernate забирает текущую версию записи. Например, version = 2. При обновлении он делает update с проверкой этой версии. Если за это время другая транзакция уже изменила запись, версия в базе стала другой. Тогда update не затронет ни одной строки, и Hibernate выбросит OptimisticLockException. Подходит, когда чтений много, записей меньше, а конфликты случаются редко. Плохо подходит, если несколько потоков постоянно меняют одну и ту же запись или нужна строгая сериализация операций. Там уже лучше смотреть в сторону pessimistic locking, очередей или переработки модели записи. @Version особенно полезен для аккаунтов, заказов, настроек, профилей и любых сущностей, где нельзя молча перетереть чужое изменение.

Google снова поделилась внутренней магией. Компания выложила Copybara — инструмент, который годами помогал ей синхронизировать код между разными репозиториями. Допустим у вас есть закрытый корпоративный репозиторий и публичная open-source версия. Copybara помогает держать их в актуальном состоянии без ручного копирования, костылей и бесконечных cherry-pick’ов. По сути, это инструмент для тех, кто живёт между private и public repo и не хочет превращать синхронизацию кода в отдельную боль. https://github.com/google/copybara

🖥 В Java длинные цепочки вроде `user → address → city` легко превращаются в ловушку для `NullPointerException`. Обычный вариант быстро разрастается:

User user = userRepository.findByEmail(email);

if (user != null) {
    Address address = user.getAddress();

    if (address != null) {
        return address.getCity();
    }
}

return "unknown";

Проблема не только в количестве строк. В таких вложенных if легко забыть один уровень проверки и получить NPE в самом неожиданном месте. С Optional это можно записать короче и безопаснее:

return userRepository.findByEmail(email)
    .map(User::getAddress)
    .map(Address::getCity)
    .orElse("unknown");

Каждый map() выполняется только если предыдущее значение существует. Если пользователя нет, адреса нет или город не задан - цепочка спокойно дойдёт до orElse(). Для таких случаев Optional хорошо работает как способ явно показать: значение может отсутствовать, и это нормальная часть логики. Главное не превращать Optional в новую религию. Он особенно полезен на границах методов и в цепочках, где каждый следующий шаг может вернуть null.

🖥 Java Records: меньше boilerplate для data-классов Начиная с Java 14 появились record - короткий способ описывать неизменяемые объекты для хранения данных. Вместо обычного POJO с полями, конструктором, getters, equals(), hashCode() и toString() можно написать одну строку: public record Point(int x, int y) {} И Java сама сгенерирует всё базовое: Point p = new Point(3, 4); int x = p.x(); int y = p.y(); record особенно удобны для DTO, value objects, результатов запросов, событий и простых структур данных. Меньше ручного кода, меньше ошибок, проще читать модель данных.

🔴 Завтра тестовое собеседование с Java-разработчиком 1 июля(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика. Как это будет: 📂 Виктор Анохин, старший разработчик из WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Виктор будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Виктору Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot Реклама. О рекламодателе.

В Java для enum лучше часто брать не HashSet, а EnumSet. EnumSet - это специальная реализация Set, заточенная именно под enum-значения. Фишка в том, что внутри он хранит элементы не как обычные объекты в hash-таблице, а как битовую маску. Каждое значение enum получает свой бит:

enum Permission {
    READ,
    WRITE,
    DELETE
}

Если в наборе есть READ и WRITE, внутри это может быть просто несколько включённых битов. Из-за этого операции вроде contains, add, remove, union, intersection работают очень быстро и занимают меньше памяти. Пример:

EnumSet<Permission> admin = EnumSet.of(
    Permission.READ,
    Permission.WRITE,
    Permission.DELETE
);

boolean canWrite = admin.contains(Permission.WRITE);

Для прав доступа, статусов, флагов, режимов и feature toggles это почти идеальный вариант. HashSet<Enum> тоже будет работать, но чаще это лишняя тяжесть. Если набор состоит только из enum-значений - сначала подумайте про EnumSet.

Идём на AI Hardcore Day в офис Авито на Лесной 11 июля! 🤩 Будем слушать доклады о Spec-Driven Development, разработке и тестировании MCP, атаках на GenAI-агентов. А после — нетворкать на террасе. ⚡ Регистрация и подробности — по ссылке. Кстати, доклады будут не под запись — советуем не пропускать!

Java-совет: начиная с Java 8 лучше использовать java.time, а не старые Date и Calendar. Почему? Calendar легко использовать неправильно:

cal.set(2026, 5, 31);

Выглядит как май, но это июнь, потому что месяцы там считаются с нуля. Ещё проблема: Date и Calendar изменяемые, а SimpleDateFormat не thread-safe. Нормальный вариант:

LocalDate today = LocalDate.of(2026, 5, 31);
LocalDate deadline = today.plusDays(7);

Тут всё читается буквально: 5 — это май, дата immutable, форматирование безопаснее и понятнее. Для времени с часовым поясом:

ZonedDateTime rome =
    meeting.atZone(ZoneId.of("Europe/Rome"));

Главная мысль: java.time убирает кучу старых ловушек Java, которые раньше спокойно доезжали до продакшена.

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

List list = new ArrayList();
list.add("hello");
Integer n = (Integer) list.get(0);

Код компилируется, но потом может прилететь ClassCastException. Правильнее так:

List<String> safe = new ArrayList<>();
safe.add("hello");
String s = safe.get(0);

Включить жёсткий режим:

javac -Xlint:all -Werror *.java

Для Maven:

<compilerArgs>
  <arg>-Xlint:all</arg>
  <arg>-Werror</arg>
</compilerArgs>

Главная мысль: пусть build падает сейчас, а не продакшен потом.

🖥 Когда говорят про развитие ИИ, обычно обсуждают модели Но на практике всё упирается в инфраструктуру. Можно обучить более умную модель, но если дата-центры не справляются с энергопотреблением, охлаждением и выдачей вычислительных ресурсов, масштабирование быстро становится проблемой. Прошла infra.conf’26, где Яндекс рассказал, как перестраивает инфраструктуру под растущие ИИ-нагрузки. Что меняется: • строятся кампусы дата-центров мощностью до 180 МВт; • внедряется жидкостное охлаждение для более эффективного отвода тепла; • развивается внутренний сервис Dev Cluster для ML-разработчиков, который ускоряет эксперименты и сокращает время разработки моделей. Интересно здесь то, что развитие ИИ всё меньше зависит только от алгоритмов. Сегодня производительность и скорость внедрения новых моделей всё чаще определяются тем, насколько быстро инфраструктура может предоставить вычисления, масштабировать нагрузку. Получается, что современный ИИ — это уже не только задача для ML-инженеров, но и для команд, которые строят дата-центры. #java

В Java давно пора забыть про `Date` и `Calendar`. Начиная с Java 8 лучше использовать java.time. Старый подход легко ломается:

Calendar cal = Calendar.getInstance();
cal.set(2026, 5, 31);

Кажется, что это май? Нет. В Calendar месяцы считаются с нуля, поэтому 5 — это июнь. Плюс Date и Calendar изменяемые, неудобные и часто приводят к багам. Даже SimpleDateFormat не thread-safe, поэтому в многопоточном коде может внезапно устроить хаос. Нормальный современный вариант:

LocalDate today = LocalDate.of(2026, 5, 31);
LocalDate deadline = today.plusDays(7);

String text = deadline.format(DateTimeFormatter.ISO_LOCAL_DATE);

Тут всё читаемо: 5 — это май. plusDays(7) — понятно. DateTimeFormatter — безопаснее. Для дат используйте LocalDate. Для даты и времени — LocalDateTime. Для часовых поясов — ZonedDateTime. java.time — один из тех апдейтов Java, который реально убирает целый класс старых багов.

Что выведет код? Версия: Java 8+

import java.util.*;

public class Main {
    static class User {
        int id;

        User(int id) {
            this.id = id;
        }

        @Override
        public boolean equals(Object obj) {
            if (!(obj instanceof User)) return false;
            return id == ((User) obj).id;
        }

        @Override
        public int hashCode() {
            return id;
        }
    }

    public static void main(String[] args) {
        Map<User, String> map = new HashMap<>();

        User user = new User(1);
        map.put(user, "admin");

        System.out.print(map.containsKey(user) + " ");

        user.id = 2;

        System.out.print(map.containsKey(user) + " ");
        System.out.print(map.get(user) + " ");
        System.out.print(map.size());
    }
}

А — true true admin 1 Б — true false null 1 В — true false admin 1 Г — Error Правильный ответ: Б — true false null 1 HashMap кладёт объект в корзину по hashCode. Сначала user.id = 1, значит ключ лежит в корзине для хэша 1. Потом мы меняем id на 2, и hashCode() тоже меняется. Теперь HashMap ищет этот же объект уже в другой корзине и не находит его. Объект всё ещё внутри map, поэтому size() остаётся 1. Вывод: ключи в HashMap должны быть неизменяемыми. Иначе можно «потерять» объект внутри коллекции.

👩‍💻 Алгоритмическая сложность коллекций в Java Приглашаем на открытый урок. 🗓 01 июля в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «Java-разработчик». Программа урока: ✔️Основы алгоритмической сложности и принцип работы о-нотации; ✔️Влияние сложности операций на выбор подходящих коллекций; ✔️Сравнение популярных коллекций Java по эффективности выполнения различных операций; ✔️Практическая демонстрация, в которой будет показано, как эффективно использовать коллекции; ✔️Рекомендации по выбору коллекций для решения задач разного уровня сложности. 🔗 Ссылка на регистрацию: https://otus.pw/G2AT/?erid=2W5zFHNNXPw Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Java: не строй логику на `instanceof`, если её можно отдать объектам Частая ошибка в ООП-коде: проверять тип объекта через цепочку instanceof, а потом вручную выбирать поведение. Плохо:

if (animal instanceof Dog) return "Woof";
if (animal instanceof Cat) return "Meow";
if (animal instanceof Cow) return "Moo";

Такой код быстро разрастается. Добавили новое животное, снова идём менять общий метод. Лучше дать каждому типу самому определить поведение:

interface Animal {
    String sound();
}

class Dog implements Animal {
    public String sound() { return "Woof"; }
}

class Cat implements Animal {
    public String sound() { return "Meow"; }
}

А дальше код становится простым:

String describe(Animal animal) {
    return animal.sound();
}

Смысл полиморфизма как раз в этом: не спрашивать объект “кто ты?”, а просто вызвать нужное действие. Меньше if, меньше кастов, меньше хрупкой логики.

✔️ Java-совет, который спасает от тихих утечек ресурсов. Если работаете с BufferedReader, InputStream, OutputStream, FileReader, соединениями или другими ресурсами, которые нужно закрывать, используйте try-with-resources. Плохо:

BufferedReader reader = new BufferedReader(new FileReader("data.txt"));

String line;
while ((line = reader.readLine()) != null) {
    System.out.println(line);
}

reader.close();

На первый взгляд всё нормально. Но если внутри чтения файла вылетит исключение, reader.close() может не выполниться. В итоге останутся открытые file handles, stream’ы или соединения. Лучше так:

try (BufferedReader reader =
         new BufferedReader(new FileReader("data.txt"))) {

    String line;
    while ((line = reader.readLine()) != null) {
        System.out.println(line);
    }
}

try-with-resources автоматически вызовет close() даже при исключении. Почему это важно: * не нужен ручной finally * меньше boilerplate-кода * ниже риск утечек ресурсов * код проще читать * безопаснее работать с файлами, сетью и БД Правило простое: если объект реализует AutoCloseable или Closeable, почти всегда стоит использовать try-with-resources. Это одна из тех привычек, которые делают Java-код чище и надёжнее.

Вайб‑кодинг: хайп для пет-проектов или мощь для прома? Узнаем на митапе! ✌️ Айтишники Новосибирска, собираемся 25 июня в лофте FoodFactory, чтобы обсудить ИИ в финтехе и создании продуктов. В программе митапа: ✔️ реальные кейсы продуктов разного масштаба; ✔️ риски и выгоды агентной разработки; ✔️ дискуссии с экспертами. Занесите в календарь: 25 июня, 19:00, лофт FoodFactory, быть обязательно!  Регистрация тут

Java: никогда не доверяйте внешнему вводу напрямую Пользовательский ввод нельзя сразу подставлять в SQL, путь к файлу или бизнес-логику. Плохой вариант:

String sql = "SELECT * FROM users WHERE email = '" + email + "'";
Files.readString(Path.of("/data/" + filename));
int age = Integer.parseInt(request.getParameter("age"));

На вид обычный код, но в нём сразу несколько проблем: • SQL-инъекции; • path traversal через ../; • некорректные типы и диапазоны; • мусорные данные, которые ломают логику дальше по системе. Правильный подход - валидировать данные на границе приложения и использовать безопасные API.

if (!EMAIL.matcher(email).matches()) {
    throw new BadRequestException("invalid email");
}

PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM users WHERE email = ?"
);
ps.setString(1, email);

Для файлов - нормализовать путь и проверять, что пользователь не вышел за разрешённую директорию:

Path base = Path.of("/data").toAbsolutePath().normalize();
Path file = base.resolve(filename).normalize();

if (!file.startsWith(base)) {
    throw new SecurityException("path escape blocked");
}

А для DTO лучше сразу описывать правила:

public record SignupRequest(
    @NotBlank @Email String email,
    @Min(18) @Max(120) int age
) {}

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

Как правильно работать с резервным копированием в облаке? 25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками. ⚫️Развеем мифы, разберём лучшие современные подходы и инструменты. ⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов. ⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы. Зарегистрируйтесь, чтобы не пропустить! ⏰ 25 июня в 14:00 (мск) ✅ Зарегистрироваться