Java Portal | Программирование
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
Show more📈 Analytical overview of Telegram channel Java Portal | Программирование
Channel Java Portal | Программирование (@java_iibrary) in the Russian language segment is an active participant. Currently, the community unites 12 132 subscribers, ranking 10 377 in the Technologies & Applications category and 54 419 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 12 132 subscribers.
According to the latest data from 05 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -142 over the last 30 days and by -1 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 11.75%. Within the first 24 hours after publication, content typically collects 6.20% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 426 views. Within the first day, a publication typically gains 753 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 4.
- Thematic interests: Content is focused on key topics such as boot, string, void, архитектура, resttemplate.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика
Связь: @devmangx
РКН: https://clck.ru/3H4WUg”
Thanks to the high frequency of updates (latest data received on 07 June, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
application.properties поставь:
spring.main.lazy-initialization=true
Но в проде важно оставить дефолтное поведение, потому что:
1. Ошибки старта ловятся раньше
2. Все компоненты сразу готовы принимать запросы
👉 Java Portal@JsonInclude(Include.NON_NULL)
@JsonInclude(JsonInclude.Include.NON_NULL)
public class UserDTO {
private Long id;
private String name;
private String email;
private String phone;
...
}
Все пустые поля исключаются автоматически.
👉 Java Portal@Component
public class StartupRunner implements CommandLineRunner {
@Override
public void run(String... args) {
System.out.println("Приложение запущено! Дальнейшая настройка");
}
}
👉 Java Portalpackage shop;
public class YakinikuShop {
public int counter = 30; // Стойка/места: видно всем
int staffRoom = 10; // Комната персонала: только для своего пакета
protected int kitchen = 20; // Кухня: свой пакет или наследники
private int safeMoney = 100; // Сейф: даже управляющему напрямую нельзя
public void askManagerToOpenSafe(Object person) {
if (!(person instanceof Manager)) {
System.out.println("❌ Только управляющий может открыть сейф");
return;
}
openSafe();
}
private void openSafe() {
System.out.println("open safe: " + safeMoney);
}
}
Почему askManagerToOpenSafe "особенный"
askManagerToOpenSafe - public.
То есть вызвать его может кто угодно.
Но откроется сейф или нет - решает проверка instanceof внутри.
public != "можно всё"
public = "вход виден и доступен"
Суть public вот такая:
* ✅может вызвать клиент
* ✅может вызвать персонал
* ✅может вызвать кто-то из другого магазина
"Встать у входа и попросить" можно, но:
* ❌ если ты не управляющий - тебя сразу разворачивают
* ❌ private-сейф напрямую трогать нельзя
Таблица доступа:
Клиент:
public: ✅
default: ❌
protected: ❌
private: ❌
Персонал этого же ресторана (тот же пакет):
public: ✅
default: ✅
protected: ✅
private: ❌
Персонал филиала (другой пакет, но наследник):
public: ✅
default: ❌
protected: ✅
private: ❌
Управляющий (дочерний класс):
public: ✅
default: ✅
protected: ✅
private: ❌
Сам класс YakinikuShop:
public: ✅
default: ✅
protected: ✅
private: ✅
👉 Java Portalserver:
shutdown: graceful
spring:
lifecycle:
timeout-per-shutdown-phase: 20s
# Сервер будет завершаться корректно (graceful).
# Даёт до 20 секунд на завершение запросов и работы бинов.
👉 Java Portalистория Java JDK / JRE / JVM (как это вообще устроено) Collections управление памятью многопоточность обработка исключений типы классов типы данных и ключевые словаМожно прям как чеклист прогнать перед интервью. 👉 Java Portal
@Configuration
public class RestTemplateConfig {
@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder) {
return builder
.setConnectTimeout(Duration.ofSeconds(3))
.setReadTimeout(Duration.ofSeconds(5))
.build();
}
}
Также можно завести больше одной конфигурации таймаутов через аннотацию @Qualifier:
@Bean
@Qualifier("slowServiceRestTemplate")
public RestTemplate slowServiceRestTemplate(RestTemplateBuilder builder) {
return builder
.setConnectTimeout(Duration.ofSeconds(5))
.setReadTimeout(Duration.ofSeconds(30))
.build();
}
@Autowired
@Qualifier("slowServiceRestTemplate")
private RestTemplate restTemplate;
👉 Java Portal@Component, @Service или @Repository, Spring по дефолту создаёт один инстанс.
Что можно сказать:
"Все Spring-бины по умолчанию singleton, если явно не указать другой scope, например @RequestScope. Это экономит память и держит объектный граф консистентным и разделяемым."
2. Proxy
Spring AOP (аспектно-ориентированное программирование) работает через прокси.
3. Observer
Система событий Spring это Observer в чистом виде.
4. Factory
Spring везде использует фабрики.
BeanFactory, ApplicationContext, FactoryBean.
Ты объявляешь бин, а Spring решает, когда и как его создать.
5. Builder
Используется в клиентах вроде RestTemplateBuilder, WebClient.Builder.
6. Template Method
Очень активно используется в JdbcTemplate, RestTemplate и т.д.
Что можно сказать:
"Мне не нужно париться про управление соединением и обработку исключений. Это делает шаблон, а я просто подставляю свою конкретную логику."
👉 Java Portal// Проверяемые (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 Portalpublic 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@Transactional прямо на контроллерах
• synchronized на нагруженном месте
👉 Java Portal@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<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
Открыв [http://localhost:8080](http://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=.
Перейдя в [http://localhost:8080](http://localhost:8080) будет:
Hello from outside the JAR👉 Java Portal
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
Available now! Telegram Research 2025 — the year's key insights 
