
- Главная
- Каталог
- Интернет технологии
- Библиотека Java разработчика
Статистика канала
Service s = new Service()). Вы - главный.
@Component — Самая базовая аннотация. "Эй, Спринг, это бин, управляй им!".
2. @Service - Тот же @Component, но семантически говорит: "Здесь бизнес-логика".
3. @Repository - Тот же @Component, но для работы с БД (ловит специфичные ошибки баз данных).
4. @Controller / @RestController - Для обработки HTTP-запросов.
5. @Configuration + @Bean - Используется, когда нужно создать бин из чужого класса (библиотеки), код которого вы не можете пометить аннотацией @Component.
💉 Dependency Injection (DI)
Главная фишка. Как один бин попадает внутрь другого?
Например, UserService нуждается в UserRepository.
❌ Способ 1: Через поле (Field Injection)
@Service
public class UserService {
@Autowired // ⚠️ Не рекомендуется!
private UserRepository repository;
}
{}
Почему плохо: Невозможно протестировать (как подсунуть мок?), скрытые зависимости, возможен NullPointerException.
✅ Способ 2: Через конструктор (Constructor Injection)
Золотой стандарт современного Spring.
@Service
public class UserService {
private final UserRepository repository;
// @Autowired здесь не обязателен (в новых версиях Spring)
public UserService(UserRepository repository) {
this.repository = repository;
}
}
{}
Плюсы: Поле final (неизменяемое), легко тестировать (можно передать любой репозиторий в конструктор), сразу видно все зависимости класса.
⚡ Лайфхак: Lombok
Чтобы не писать конструктор руками, используйте Lombok:
@Service
@RequiredArgsConstructor // Генерирует конструктор для final полей
public class UserService {
private final UserRepository repository; // Всё внедрится само!
}
{}
🔥 Итог
Spring, это просто "мешок с объектами" (Context), которые он создает сам и связывает друг с другом (DI).
new Service().
@Service, @Repository).
#SpringBoot #Java #IoC #DI #SpringTips
Thread): Простой код, но один поток весит ~2 Мб памяти. Создадите 5,000 потоков - сервер упадет с OutOfMemoryError.
2. Асинхронность (WebFlux/Netty): Сервер держит 100k соединений, но код превращается в лапшу из callbacks и CompletableFuture, которую невозможно отлаживать.
В Java 21 появились Виртуальные потоки. Они объединяют простоту первого подхода и производительность второго.
🪶 В чем магия?
Классический поток Java (Platform Thread) привязан 1-к-1 к потоку операционной системы (OS Thread). Это дорогой ресурс.
Виртуальный поток, это просто объект в куче (heap) JVM. Он не привязан к ОС намертво.
Thread.sleep), JVM снимает виртуальный поток с ядра.
4. Поток ОС освобождается и тут же берет в работу другой виртуальный поток.
Итог: Ядра процессора молотят на 100%, никогда не простаивая в ожидании ввода-вывода.
💻 Код: Найди 1 отличие
API практически не изменился. Вам не нужно учить новые фреймворки.
// Старый способ (Тяжелый поток ОС)
Thread.ofPlatform().start(() -> {
System.out.println("Я ем много памяти!");
});
// Новый способ (Легкий виртуальный поток)
Thread.ofVirtual().start(() -> {
System.out.println("Я ничего не вешу!");
});
// Использование с ExecutorService (для старого кода)
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
IntStream.range(0, 1_000_000).forEach(i -> {
executor.submit(() -> {
Thread.sleep(1000); // Блокировка теперь БЕСПЛАТНАЯ
return i;
});
});
}
// Этот код запустит миллион задач за секунду, не положив сервер.
{}
⚰️ Конец Reactive Programming?
Многие эксперты говорят: Да.
Смысл использования сложных реактивных библиотек (RxJava, Reactor) был в том, чтобы не блокировать потоки. Виртуальные потоки делают блокировку дешевой.
Теперь вы можете писать простой, последовательный код:
var user = db.findUser();
var data = http.sendRequest(user);
...и он будет работать так же эффективно, как сложный асинхронный код.
⚠️ Когда НЕ использовать?
Виртуальные потоки идеальны для I/O задач (ждать сеть, ждать диск).
Они бесполезны для CPU-Intensive задач (майнинг, шифрование, обработка видео). Если поток не ждет, а считает, он занимает поток ОС, и виртуалка тут не поможет.
🔥 Итог
Project Loom вернул нам девиз: "Один запрос - Один поток".
Больше никаких пулов потоков с ограниченным размером. Просто создавайте новый виртуальный поток для каждой задачи.
#Java #Loom #VirtualThreads #Concurrency #HighLoad
final).
Но что, если я хочу, чтобы мой класс Shape (Фигура) могли наследовать только Circle и Square, и больше никто?
Раньше это решалось костылями (пакетная видимость, скрытые конструкторы). В Java 17 появился официальный механизм: Sealed Classes.
🚧 Как это работает?
Вы помечаете класс (или интерфейс) ключевым словом sealed и после слова permits перечисляете тех, кому "можно".
// Родитель: Разрешает наследование ТОЛЬКО этим двум классам
public sealed interface Payment
permits CreditCard, Cash {
}
{}
Теперь, если Вася из соседнего отдела попытается написать class Crypto extends Payment, компилятор ударит его по рукам. 🚫
🚦 Правило трех дорог
Наследники запечатанного класса обязаны выбрать свою судьбу. Они должны иметь один из трех модификаторов:
1. final - Цепочка наследования обрывается. Дальше наследовать нельзя.
public final class Cash implements Payment { ... }
{}
2. sealed - Иерархия продолжается, но снова под контролем.
public sealed class CreditCard implements Payment permits Visa, MasterCard { ... }
{}
3. non-sealed - "Открываем шлюзы". Дальше от этого класса может наследоваться кто угодно (возврат к старому поведению Java).
public non-sealed class DebitCard implements Payment { ... }
{}
🧩 Главная фишка: Комбо со Switch
Зачем это нужно, кроме запретов? Ради безопасности.
Когда вы используете sealed иерархию в новом switch, компилятор знает все возможные варианты.
Вам больше не нужно писать ветку default!
// Метод обработки платежа
String process(Payment p) {
return switch (p) {
case CreditCard c -> "Processing card: " + c.getNumber();
case Cash c -> "Processing cash amount: " + c.getAmount();
// default НЕ НУЖЕН! Компилятор знает, что третьго не дано.
};
}
{}
Если завтра вы добавите в permits новый класс Crypto, код перестанет компилироваться, пока вы не обработаете этот новый кейс в свитче.
Это спасает от багов, когда в бизнес-логику добавили новый тип, а обработчики обновить забыли.
🔥 Итог
Sealed Classes + Records + Switch Pattern Matching = 💎
Это "Святая Троица" современной Java. Используйте запечатанные классы для моделирования доменной области, где количество вариантов конечно и известно заранее (статусы заказа, типы платежей, виды пользователей).
#Java17 #SealedClasses #Architecture #CleanCode
Object, и нужно понять, что внутри?
Раньше мы писали "лестницу" из if-else и instanceof с кучей ручного кастинга (приведения типов).
❌ Было (Боль и слезы):
Object obj = getUnknownObject();
if (obj instanceof String) {
String s = (String) obj; // Ручной каст
System.out.println("Строка: " + s.length());
} else if (obj instanceof Integer) {
Integer i = (Integer) obj; // Опять каст
System.out.println("Число: " + i);
} else if (obj instanceof Long) {
// ... и так до бесконечности
}
{}
✅ Стало (Java 21 LTS):
Теперь switch умеет проверять типы! Больше никаких instanceof и ручных приведений. Переменная создается прямо в кейсе.
switch (obj) {
case String s -> System.out.println("Строка: " + s.length());
case Integer i -> System.out.println("Число: " + i);
case Long l -> System.out.println("Длинное число: " + l);
default -> System.out.println("Непонятно что");
}
{}
🛡 Guarded Patterns (Охрана в кейсах)
Но это еще не всё. Часто бывает, что тип нам подходит, но нужно проверить еще и значение.
Раньше пришлось бы ставить if внутри case. Теперь у нас есть ключевое слово when.
switch (obj) {
// Попадет сюда, ТОЛЬКО если это строка И она длиннее 10 символов
case String s when s.length() > 10 ->
System.out.println("Длинная строка: " + s);
// Любая другая строка
case String s ->
System.out.println("Короткая строка: " + s);
case Integer i ->
System.out.println("Число: " + i);
default -> {}
}
{}
👻 А как же Null?
В старом switch, если передать null, мы мгновенно получали NullPointerException.
В новом switch можно (и нужно!) обрабатывать null легально:
switch (obj) {
case String s -> System.out.println("Это строка");
case null -> System.out.println("Пришел null!"); // Никакого NPE
default -> System.out.println("Что-то другое");
}
{}
⚡Это не просто "сахар". Это изменение подхода к полиморфизму.
Если раньше логика часто размазывалась по методам классов (animal.makeSound()), то теперь можно собирать логику обработки разных типов в одном месте, что часто бывает удобнее при написании бизнес-логики (например, обработка разных типов ивентов или DTO).
🔥 Итог
Switch теперь принимает любые объекты.
case String s).
when.
null.
#PatternMatching #NewJava #CleanCode
break!
Помните это чувство, когда забыл написать break в switch-case, и код пошел выполняться дальше, создав неуловимый баг? 😫
В современных версиях Java (стандарт с Java 14) оператор switch прокачали. Теперь это не просто управляющая конструкция, а выражение, возвращающее результат.
💀 Было (Statement)
Громоздко, опасно (fall-through), переменная вынесена наружу.
DayOfWeek day = DayOfWeek.SATURDAY;
int numLetters;
switch (day) {
case MONDAY:
case FRIDAY:
case SUNDAY:
numLetters = 6;
break; // Забыл break? Получи баг!
case TUESDAY:
numLetters = 7;
break;
default:
throw new IllegalStateException("Wat: " + day);
}
{}
✅ Стало (Expression)
Лаконично, безопасно, функционально.
int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
default -> throw new IllegalStateException("Wat: " + day);
};
{}
🚀 Главные фишки
1. Стрелочный синтаксис (->)
Если используется стрелка, переход к следующему кейсу (fall-through) отключен по умолчанию. Никаких break больше писать не надо!
2. Возврат значения
switch теперь работает как формула. Вы можете сразу присвоить результат переменной или вернуть его из метода (return switch(...)).
3. Несколько условий в одну строку
case MONDAY, FRIDAY, SUNDAY — просто перечисляем через запятую.
🛑 Сложная логика и yield
Что делать, если в одном case нужно не просто вернуть число, а выполнить несколько строк кода (например, залоггировать)?
Для этого появились фигурные скобки и ключевое слово yield.
Важно: return использовать нельзя, так как он прервет выполнение всего метода, а не только свича.
String result = switch (day) {
case SATURDAY, SUNDAY -> "Выходной";
case MONDAY -> {
System.out.println("Тяжелый день...");
yield "Будни"; // yield возвращает значение из switch
}
default -> "Будни";
};
{}
⚡ Exhaustiveness (Полнота)
Если вы делаете switch по Enum, компилятор проверит, все ли варианты вы обработали. Если добавите в Enum новый день, а в свич - нет, код просто не скомпилируется. Это отличная защита от забывчивости!
🔥 Итог
Новый switch это чистый кайф. Он делает код компактнее и убирает целый класс ошибок, связанных с пропущенными break.
->, когда нужно просто сопоставить значение.
yield, если нужна логика внутри блока.
#Java #SwitchExpression #CleanCode #NewJava
equals, hashCode, toString... 🤯
В Java 16+ этому положили конец. Встречайте Records.
📉 Было vs Стало
Допустим, нам нужен простой DTO для пользователя.
❌ Классический POJO (Java 1.0 - 15):
public class User {
private final String name;
private final int age;
public User(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() { return name; }
public int getAge() { return age; }
// + equals()
// + hashCode()
// + toString() ... еще 30 строк кода
}
{}
✅ Record (Java 16+):
public record User(String name, int age) {}
{}
Всё. Это одна строка. 🔥
⚙️ Что происходит под капотом?
Компилятор делает всю грязную работу за вас. Создавая record, вы автоматически получаете:
1. Приватные финальные поля (private final).
2. Конструктор со всеми аргументами.
3. Геттеры (без префикса get! Просто .name(), .age()).
4. equals() и hashCode() (идеально для ключей в Map или Set).
5. toString() (красивый вывод: User[name=Alex, age=25]).
🛠 Кастомизация (Compact Constructor)
"А что, если мне нужна валидация? Нельзя же создать юзера с отрицательным возрастом!"
Для этого есть Компактный конструктор. Вам даже не нужно перечислять аргументы:
public record User(String name, int age) {
// Компактный конструктор
public User {
if (age < 0) {
throw new IllegalArgumentException("Возраст не может быть меньше 0");
}
// Присваивание this.age = age происходит автоматически!
}
}
{}
⚠️ Ограничения (Важно знать)
Records, это не замена обычным классам во всем.
1. Они неизменяемы (Immutable). Сеттеров нет и не будет. Хотите поменять поле? Создавайте новый объект.
2. Нет наследования. Record не может наследовать (extends) другой класс (потому что он уже наследует java.lang.Record). Но имплементировать интерфейсы (implements) можно!
💡 Когда использовать?
equals/hashCode.
record.
#Java #Records #NewJava #CleanCode
null своей "ошибкой на миллиард долларов". NullPointerException (NPE) - самый частый кошмар Java-разработчика.
В Java 8 появился Optional<T> - класс-обертка, который явно говорит: "Здесь значения может и не быть".
📦 Что внутри?
Представьте Optional как коробку.
null из метода, если можно вернуть Optional.empty().
🚫 Как делать НЕ надо
Самая частая ошибка новичка, использовать Optional как старый добрый if (x != null):
Optional<User> userOpt = findUser("Alex");
// ❌ ПЛОХО: Это тот же null-check, только сложнее
if (userOpt.isPresent()) {
System.out.println(userOpt.get().getName());
}
{}
Метод .get() - это зло. Если коробка пуста, он бросит NoSuchElementException, и вы просто поменяли шило (NPE) на мыло.
✅ Как делать НАДО (Functional Style)
Вся мощь Optional раскрывается, когда вы строите цепочки вызовов, как в стримах.
1. Если значение есть, сделай что-то (ifPresent)
findUser("Alex").ifPresent(user -> System.out.println(user.getName()));
{}
2. Если значения нет, верни дефолт (orElse)
// Вернет юзера или создаст нового "Guest", если не нашел
User user = findUser("Alex").orElse(new User("Guest"));
{}
3. Если значения нет — брось ошибку (orElseThrow)
User user = findUser("Alex")
.orElseThrow(() -> new IllegalArgumentException("User not found"));
{}
4. Преобразование внутри коробки (map)
Допустим, нам нужен не сам юзер, а его email. Если юзера нет, то и email нет.
String email = findUser("Alex")
.map(User::getEmail) // Достаем email (если юзер есть)
.map(String::toUpperCase) // В верхний регистр (если email был)
.orElse("UNKNOWN"); // Если хоть на одном этапе было пусто
{}
⚡ Золотые правила использования
1. Только для возвращаемых значений! Не используйте Optional как тип поля в классе или аргумент метода. Это лишний оверхед и мусор в коде.
2. orElse() vs orElseGet():
orElse(new Object()) - объект создается всегда, даже если он не нужен.
orElseGet(() -> new Object()) - объект создается только если в коробке пусто (лениво). Используйте этот вариант для тяжелых объектов.
🔥 Итог
Optional спасает не тем, что убирает null, а тем, что заставляет вас явно обработать случай отсутствия значения.
Забудьте про .get(). Используйте .map(), .filter() и .orElse().
#Java #Optional #CleanCode #NoMoreNPE
Отзывы канала
всего 15 отзывов
- Добавлен: Сначала новые
- Добавлен: Сначала старые
- Оценка: По убыванию
- Оценка: По возрастанию
Каталог Телеграм-каналов для нативных размещений
Библиотека Java разработчика — это Telegam канал в категории «Интернет технологии», который предлагает эффективные форматы для размещения рекламных постов в Телеграмме. Количество подписчиков канала в 10.5K и качественный контент помогают брендам привлекать внимание аудитории и увеличивать охват. Рейтинг канала составляет 8.4, количество отзывов – 15, со средней оценкой 4.9.
Вы можете запустить рекламную кампанию через сервис Telega.in, выбрав удобный формат размещения. Платформа обеспечивает прозрачные условия сотрудничества и предоставляет детальную аналитику. Стоимость размещения составляет 6993.0 ₽, а за 85 выполненных заявок канал зарекомендовал себя как надежный партнер для рекламы в TG. Размещайте интеграции уже сегодня и привлекайте новых клиентов вместе с Telega.in!
Вы снова сможете добавить каналы в корзину из каталога
Комментарий