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 109 subscribers, ranking 10 407 in the Technologies & Applications category and 54 513 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 12 109 subscribers.
According to the latest data from 09 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -147 over the last 30 days and by -12 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 11.15%. Within the first 24 hours after publication, content typically collects 6.42% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 351 views. Within the first day, a publication typically gains 778 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 10 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.
1. Каковы ключевые характеристики микросервисов? Ответ: > Децентрализованное управление данными > Сервисы развёртываются независимо друг от друга > Проектирование на основе предметной области (DDD) > Лёгкое взаимодействие (например, REST, gRPC) > Изоляция сбоев > Удобны для непрерывной доставки 2. Чем микросервисы отличаются от монолитной архитектуры? Ответ: > Монолит: единая кодовая база, жёстко связанные компоненты, сложно масштабировать. > Микросервисы: множество сервисов, слабо связанные, развёртываются и масштабируются независимо. 3. Каковы основные преимущества использования микросервисов? Ответ: > Лучшая масштабируемость > Более быстрое выведение продукта на рынок > Независимые развёртывания > Лучшая устойчивость к сбоям > Возможность использовать разные языки и технологии 4. Какие есть сложности при работе с микросервисами? Ответ: > Сложность управления распределёнными системами > Задержки в сети и накладные расходы на коммуникацию > Согласованность данных > Отладка и мониторинг > Развёртывание и оркестрация 5. Как микросервисы обмениваются данными? Ответ: > Синхронно: через REST, gRPC > Асинхронно: через очереди сообщений (RabbitMQ, Kafka) 6. Что такое service discovery в микросервисах? Ответ: > Это механизм, с помощью которого сервисы находят друг друга в сети. > Применяются инструменты вроде Consul, Eureka, DNS Kubernetes. 7. Что такое API Gateway и зачем он нужен? Ответ: > API Gateway — это единая точка входа в систему. Он отвечает за маршрутизацию, безопасность, ограничение частоты запросов и агрегацию ответов от разных сервисов. > Примеры: Kong, Zuul, NGINX, Spring Cloud Gateway. 8. Как в микросервисах управляют данными? Ответ: > Каждый сервис использует свою отдельную базу данных (подход “одна база на сервис”). > Для согласованности применяются событийная архитектура или паттерн саги. 9. Что такое паттерн Saga? Ответ: > Saga — это последовательность локальных транзакций. > Если одна из них завершается с ошибкой, запускаются компенсирующие действия для отката изменений. 10. Какие инструменты используют для разработки микросервисов? Ответ: > Языки: Java (Spring Boot), Node.js, Go, Python > Сборка: Maven, Gradle > Контейнеризация: Docker > Оркестрация: Kubernetes👉 Java Portal
void main() {
do onlyOnce: {
IO.println("Один раз?");
break onlyOnce;
} while (true);
}
Компилируется без ошибок. При выполнении выводит:
Один раз?
Один раз?
Один раз?
Один раз?
Один раз?
...
Это приводит к бесконечному циклу 🙂
👉 Java Portaljava.text.CompactNumberFormat. Она позволяет компактно отображать большие числа
Пример:
Locale.setDefault(Locale.US);
NumberFormat compact = NumberFormat.getCompactNumberInstance();
System.out.println(compact.format(1));
System.out.println(compact.format(999));
System.out.println(compact.format(2_000));
System.out.println(compact.format(55_555));
System.out.println(compact.format(3_777_999));
System.out.println(compact.format(Integer.MAX_VALUE));
Вывод:
1
999
2K
56K
4M
2B
Также доступен стиль LONG:
NumberFormat compact;
compact = NumberFormat.getCompactNumberInstance(Locale.US, Style.LONG);
Результат:
1
999
2 thousand
56 thousand
4 million
2 billion
Идеально для UI, отчетов и всего, где важна краткость 💖
👉 Java PortalLambdaMetaFactory
Следующий код на Java создаёт объект Function<String, String>
Function<String, String> f = s -> s.toUpperCase();
Во время выполнения объект создаётся с помощью кода, аналогичного следующему:
@SuppressWarnings("unchecked")
void main() throws Throwable {
MethodHandles.Lookup lookup;
lookup = MethodHandles.lookup();
CallSite callSite;
callSite = LambdaMetafactory.metafactory(
lookup,
"apply",
MethodType.methodType(Function.class),
MethodType.methodType(Object.class, Object.class),
lookup.findStatic(
getClass(),
"lambda",
MethodType.methodType(String.class, String.class)
),
MethodType.methodType(String.class, String.class)
);
MethodHandle target;
target = callSite.getTarget();
Function<String, String> f;
f = (Function<String, String>) target.invokeExact();
String msg;
msg = f.apply("Hello, World!");
IO.println(msg);
}
private static String lambda(String s) {
return s.toUpperCase();
}
При выполнении этот код выведет в консоль HELLO, WORLD! ❤️
👉 Java PortalPaymentService, поддерживающий оплату кредитной картой.
Вы пишете:
public void pay(String method) {
if (method.equals("creditcard")) {
// логика оплаты кредиткой
}
}
Потом добавляют PayPal, UPI, крипту, Apple Pay, кошельки, NetBanking и тд.. 😢
Теперь ваш метод выглядит вот так:
if (method.equals("creditcard")) {
// логика кредитки
} else if (method.equals("paypal")) {
// логика PayPal
} else if ...
Вы тонете в аду if-else. Каждый раз при добавлении нового способа оплаты:
> Вы трогаете старый код
> Рискуете сломать существующую логику
> Нельзя нормально протестировать стратегии
> Нарушается принцип OCP (Open/Closed)
В чём настоящая проблема?
1. Ваш код слишком жёстко связан с конкретными реализациями оплат
2. Добавление новых стратегий требует изменения существующего кода
3. Тестировать/переиспользовать отдельные стратегии — сложно
4. PaymentService теперь отвечает за слишком многое
Как Strategy Pattern вас спасает
1. Создаёшь интерфейс PaymentStrategy
2. Для каждой оплаты — свой класс: CreditCardPayment, PayPalPayment, UPIPayment
3. PaymentService просто вызывает .pay() на нужной стратегии
☑ Добавить новый способ? Просто пишешь новый класс
☑ Никаких if-else
☑ Стратегии изолированы и легко тестируются
interface PaymentStrategy {
void pay(int amount);
}
class CreditCardPayment implements PaymentStrategy {
public void pay(int amount) {
System.out.println("Плачу " + amount + " с помощью кредитки");
}
}
class PayPalPayment implements PaymentStrategy {
public void pay(int amount) {
System.out.println("Плачу " + amount + " через PayPal");
}
}
👉 Java PortalHashMap, TreeMap, ConcurrentHashMap — лови таблицу сравнения
> HashMap — быстрая, но не потокобезопасная. Подходит для общего использования
> LinkedHashMap — сохраняет порядок вставки
> TreeMap — сортирует по ключам.
> Hashtable — потокобезопасна, но старая и медленная
> ConcurrentHashMap — оптимальна для многопоточности
> EnumMap — супербыстрая для enum-ключей
> IdentityHashMap — использует == вместо .equals()
> WeakHashMap — ключи могут быть удалены GC. Полезно для кэшей
Не забывай про null-ключи, производительность, порядок —> всё это влияет на выбор структуры данных 💖
👉 Java Portal.antMatchers("/swagger-ui/", "/v3/api-docs/").permitAll()
Так разработчики смогут спокойно тестировать и изучать API без входа в систему
👉 Java PortaltoString и hashCode не были переопределены? Тогда метод Objects::toIdentityString — это то, что вам нужно:
void main() {
IO.println(this);
IO.println(Objects.toIdentityString(this));
}
@Override
public String toString() {
return "Hello, World!";
}
При выполнении на моей машине выводится:
Hello, World!
HelloWorld@275710fc
Метод был введён в JDK 19. Документация Javadoc не говорит много о возможных вариантах использования. В баге JDK-8280184 Стюарт Маркс пишет:
Это может быть полезно в логировании, например, когда нужно отслеживать операции, выполненные над каким-то конкретным объектом, например, перед сбоем. Идентичный хэшкод — полезный способ сделать это👉 Java Portal
• Знания Java, не на базовом уровне. • Опыт работы Figma • Умение писать грамотные тексты с доступным объяснением на разные темы.Если вам интересно и есть достаточно свободного времени, отпишите — @energy_it.
void main() {
var after = new Final(this::before);
IO.println("After value=" + after.value);
}
private void before(Final before){
IO.println("Before value=" + before.value);
}
class Final {
final int value;
Final(Consumer<? super Final> listener) {
listener.accept(this);
value = 123;
}
}
Результат выполнения будет таким:
Before value=0
After value=123
Это пример утечки this.
JEP 401 называет это larval object leakage — ситуация, когда объект, ещё не до конца инициализированный, "просачивается" из конструктора и используется раньше времени.
В JDK 24 в рамках JEP о гибких телах конструкторов (Flexible Constructor Bodies) эта проблема решается следующим образом:
Код в начале конструктора не должен использовать this, кроме как для инициализации полей, у которых нет своих инициализаторов.Иначе говоря, в начальной части конструктора теперь нельзя "утечь" наружу с
this, пока объект не готов
👉 Java Portal this. Например, следующий код выведет Hello, World!:
private Runnable runnable = () -> {
System.out.println(this);
};
@Override
public String toString() {
return "Hello, World!";
}
void main() {
runnable.run();
}
А если заменить лямбду на анонимный класс, результат будет вроде InnerClassThis$1@568bf312:
private Runnable runnable = new Runnable() {
@Override public void run() {
System.out.println(this);
}
};
@Override
public String toString() {
return "Hello, World!";
}
void main(String[] args) {
runnable.run();
}
То есть у лямбды нет собственного this — она использует this из внешнего контекста. Это чётко описано в спецификации Java:
Значение this в теле лямбды — то же самое, что и this во внешнем контексте.Если хочешь разобраться глубже, смотри официальный гайд 👉 Java Portal
Available now! Telegram Research 2025 — the year's key insights 
